| commit | 9dcd136df13df632d90636abb97e9e168f1d8a89 | [log] [tgz] |
|---|---|---|
| author | stiga-huang <huangquanlong@gmail.com> | Wed Mar 13 18:50:29 2024 +0800 |
| committer | Impala Public Jenkins <impala-public-jenkins@cloudera.com> | Tue Mar 26 05:54:52 2024 +0000 |
| tree | bdb5b3283c7147af31e625a7404f1b8fc6b40408 | |
| parent | 88dcdfd4662d0ec4a6e0d81d643d207f6e5ed900 [diff] |
IMPALA-12699: Set timeout for catalog RPCs We have seen trivial GetPartialCatalogObject RPCs hanging in coordinator side, e.g. IMPALA-11409. Due to the piggyback mechanism of fetching metadata in local-catalog mode (see comments in CatalogdMetaProvider#loadWithCaching()), a hanging RPC on shared metadata (e.g. db/table list) could block other queries on the same coordinator. Such lightweight requests don't need to acquire table lock or trigger table loading in catalogd. The causes of the hanging are usually network issues, e.g. TCP connection become half open due to TCP retransmissions timed out. A retry on the RPC helps to recover from such failures. Currently, the timeout for catalog RPC is set to 0 by default. This prevent the retry and let the client to wait infinitely. This patch distinguishes the lightweight catalog RPCs and uses a dedicated catalogd client cache for them. They use a timeout of 30 mins which is longer enough to tolerate TCP retransmission timeouts. Also sets a timeout of 10 hours for other catalog RPCs. Operations take longer than that are usually abnormal and hanging. Tests - Add e2e test to verify the lightweight RPC client cache is used. - Adjust TestRestart.test_catalog_connection_retries to use local catalog mode since in the legacy catalog mode, coordinator only sends PrioritizeLoad requests which are lightweight RPCs. This is a continuation of patch by Wenzhe Zhou <wzhou@cloudera.com> Change-Id: Iad39a79d0c89f2b04380f610a7e60558429e9c6e Reviewed-on: http://gerrit.cloudera.org:8080/21146 Reviewed-by: Wenzhe Zhou <wzhou@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com>
Lightning-fast, distributed SQL queries for petabytes of data stored in open data and table formats.
Impala is a modern, massively-distributed, massively-parallel, C++ query engine that lets you analyze, transform and combine data from a variety of data sources:
The fastest way to try out Impala is a quickstart Docker container. You can try out running queries and processing data sets in Impala on a single machine without installing dependencies. It can automatically load test data sets into Apache Kudu and Apache Parquet formats and you can start playing around with Apache Impala SQL within minutes.
To learn more about Impala as a user or administrator, or to try Impala, please visit the Impala homepage. Detailed documentation for administrators and users is available at Apache Impala documentation.
If you are interested in contributing to Impala as a developer, or learning more about Impala's internals and architecture, visit the Impala wiki.
Impala only supports Linux at the moment. Impala supports x86_64 and has experimental support for arm64 (as of Impala 4.0). Impala Requirements contains more detailed information on the minimum CPU requirements.
Impala runs on Linux systems only. The supported distros are
Other systems, e.g. SLES12, may also be supported but are not tested by the community.
This distribution uses cryptographic software and may be subject to export controls. Please refer to EXPORT_CONTROL.md for more information.
See Impala's developer documentation to get started.
Detailed build notes has some detailed information on the project layout and build.