The Thrift max message size is designed to protect against malicious messages that consume a lot of memory on the receiver. This is an important security measure for externally facing services, but it can interfere with internal communication within the cluster. Currently, the max message size is controlled by a single startup flag for both. This puts tensions between having a low value to protect against malicious messages versus having a high value to avoid issues with internal communication (e.g. large statestore updates). This introduces a new flag thrift_external_rpc_max_message_size to specify the limit for externally-facing services. The current thrift_rpc_max_message_size now applies only for internal services. Splitting them apart allows setting a much higher value for internal services (64GB) while leaving the externally facing services using the current 2GB limit. This modifies various code locations that wrap a Thrift transport to pass in the original transport's TConfiguration. This also adds DCHECKs to make sure that the new transport inherits the max message size. This limits the locations where we actually need to set max message size. ThriftServer/ThriftServerBuilder have a setting "is_external_facing" which can be specified on each ThriftServer. This modifies statestore and catalog to set is_external_facing to false. All other servers stay with the default of true. Testing: - This adds a test case to verify that is_external_facing uses the higher limit. - Ran through the steps in testdata/scale_test_metadata/README.md and updated the value in that doc. - Created many tables to push the catalog-update topic to be >2GB and verified that statestore successfully sends it when an impalad restarts. Change-Id: Ib9a649ef49a8a99c7bd9a1b73c37c4c621661311 Reviewed-on: http://gerrit.cloudera.org:8080/21420 Tested-by: Impala Public Jenkins <impala-public-jenkins@cloudera.com> Reviewed-by: Riza Suminto <riza.suminto@cloudera.com> Reviewed-by: Michael Smith <michael.smith@cloudera.com>
Scale Test Metadata
This README.md explain how to setup 1k_col_tbl table, a wide table with 1000+ columns, long partition key, and huge partiton count. This table is intended to scale test metadata operation limit against such table. This experiment/test is only documented here because the time to load data and execute such metadata operation query can be prohibitively long if written as a custom_cluster test run on single machine. This doc will use IMPALA-11669 as a case study.
IMPALA-11669: Make Thrift max message size configuration
With the upgrade to Thrift 0.16, Thrift now has a protection against malicious message in the form of a maximum size for messages. This is currently set to 100MB by default. Impala should add the ability to override this default value. In particular, it seems like communication between coordinators and the catalogd may need a larger value.
To test this, we will setup 1k_col_tbl with 150k partitons and run a metadata query to test that coordinator-to-catalogd RPC works well. The steps are follow:
-
Run create-wide-table.sql with impala-shell to create 1k_col_tbl table.
impala-shell.sh -f create-wide-table.sql -
Populate 1k_col_tbl with 150k partitons by running load-1k_col_tbl.sh. HDFS must be running.
./load-1k_col_tbl.sh -
With impala-shell, recover partition of table 1k_col_tbl.
ALTER TABLE 1k_col_tbl RECOVER PARTITIONS;Run it multiple times if impalad/catalogd hits OOM until all partitions registered with HMS.
-
Restart impala cluster with
--thrift_rpc_max_message_size=0(will set it to 100MB, the default max message size from Thrift).# kill cluster ./bin/start-impala-cluster.py --kill # start cluster ./bin/start-impala-cluster.py -s 1 \ --state_store_args="--thrift_rpc_max_message_size=0" \ --impalad_args="--thrift_rpc_max_message_size=0 --use_local_catalog=true" \ --catalogd_args="--catalog_topic_mode=minimal" # Restart catalogd with additional args and jvm args ./bin/start-impala-cluster.py -s 1 --restart_catalogd_only --jvm_args=-Xmx12g \ --catalogd_args=" --catalog_topic_mode=minimal --thrift_rpc_max_message_size=0 --warn_catalog_response_size_mb=1" -
Run the following EXPLAIN query with impala-shell.
impala-shell.sh -q 'EXPLAIN SELECT id FROM 1k_col_tbl'This will fail with "MaxMessageSize reached".
Starting Impala Shell with no authentication using Python 2.7.16 Warning: live_progress only applies to interactive shell sessions, and is being skipped for now. Opened TCP connection to localhost:21050 Connected to localhost:21050 Server version: impalad version 4.2.0-SNAPSHOT DEBUG (build e081348e02848f3e7dd904f44e43b9da63a93594) Query: EXPLAIN SELECT id FROM 1k_col_tbl ERROR: LocalCatalogException: Could not load partition names for table default.1k_col_tbl CAUSED BY: TException: TGetPartialCatalogObjectResponse(status:TStatus(status_code:GENERAL, error_msgs:[couldn't deserialize thrift msg: MaxMessageSize reached]), lookup_status:OK, object_version_number:1649) -
Restart impala-shell again, but without passing
--thrift_rpc_max_message_sizeargument.# kill cluster ./bin/start-impala-cluster.py --kill # start cluster ./bin/start-impala-cluster.py -s 1 \ --impalad_args="--use_local_catalog=true" \ --catalogd_args="--catalog_topic_mode=minimal" # Restart catalogd with additional args and jvm args ./bin/start-impala-cluster.py -s 1 --restart_catalogd_only --jvm_args=-Xmx12g \ --catalogd_args="--catalog_topic_mode=minimal --warn_catalog_response_size_mb=1" -
Run the same EXPLAIN query again. This should run successfully, because the default
thrift_rpc_max_message_sizeis 64GB (see IMPALA-13020).impala-shell.sh -q 'EXPLAIN SELECT id FROM 1k_col_tbl'
To exercise Impala with SSL, add the following args in each daemon start up args.
--ssl_client_ca_certificate=$IMPALA_HOME/be/src/testutil/server-cert.pem --ssl_server_certificate=$IMPALA_HOME/be/src/testutil/server-cert.pem --ssl_private_key=$IMPALA_HOME/be/src/testutil/server-key.pem --hostname=localhost
And use the following impala-shell command.
impala-shell.sh --ssl --ca_cert=$IMPALA_HOME/be/src/testutil/server-cert.pem -q 'EXPLAIN SELECT id FROM 1k_col_tbl'