You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2022/10/31 04:47:00 UTC
[jira] [Commented] (IMPALA-11514) Workaround s3 timeout waiting for connection from pool (HADOOP-18410)
[ https://issues.apache.org/jira/browse/IMPALA-11514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17626374#comment-17626374 ]
ASF subversion and git services commented on IMPALA-11514:
----------------------------------------------------------
Commit bd88b71edd305dd448e9ec33a0cfd10f97177c4e in impala's branch refs/heads/master from Joe McDonnell
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=bd88b71ed ]
IMPALA-11524: Bump up the CDP GBN to 33375775 and remove workarounds
This patch bumps up the GBN to 33375775, which contains the
fix for HADOOP-18410 as well as HADOOP-18456, which should help
with the stability of S3 tests. This removes the workaround
for HADOOP-18410 introduced in IMPALA-11514.
This also picks up newer versions of Ozone, Iceberg, Hive, etc.
After HIVE-26071, hive-standalone-metastore starts relying on
jetty-servlet, which in turn requires jetty-security. Since Impala bans
all jetty-related dependencies unless otherwise specified, this patch
adds jetty-servlet, jetty-security, and jetty-util-ajax as allowed
dependencies in order to compile Impala with Hive.
Hive Metastore introduced several new APIs in their interface, so
this adds implementations for these (e.g. HIVE-25303, HIVE-22782).
For example, HIVE-26149 introduced a new HMS API drop_database_req,
so we need to implement this API in CatalogServerHandler as well.
This patch also fixes a bug that the third parameter in drop_database
was treated as "ignoreUnknownDb", however it should be "cascade".
The number of files produced on systems with 32GB of memory changed.
Until we track down the specific cause, this tunes the YARN memory
slightly higher to avoid changes in the number of files produced
for systems with 32GB of memory.
The content in this patch comes from several developers: Yu-Wen Lai,
Kishen Das, and Fang-Yu Rao.
Testing:
- Ran core jobs
- Ran CatalogHmsSyncToLatestEventIdTest tests
- Hand tested on a machine with 32GB of memory
Change-Id: Iea7e1785f5c93f61179cc336968c3a86c53e9ed1
Reviewed-on: http://gerrit.cloudera.org:8080/19149
Tested-by: Impala Public Jenkins <im...@cloudera.com>
Reviewed-by: Csaba Ringhofer <cs...@cloudera.com>
Reviewed-by: Wenzhe Zhou <wz...@cloudera.com>
> Workaround s3 timeout waiting for connection from pool (HADOOP-18410)
> ---------------------------------------------------------------------
>
> Key: IMPALA-11514
> URL: https://issues.apache.org/jira/browse/IMPALA-11514
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: Impala 4.2.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Blocker
> Labels: broken-build
> Fix For: Impala 4.2.0
>
>
> When testing on s3, we see dataload fail when trying to load testcases:
> {noformat}
> 12:00:17 Creating tpcds testcase data (logging to /data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/logs/data_loading/create-tpcds-testcase-data.log)...
> 12:00:17 FAILED (Took: 0 min 13 sec)
> 12:00:30 '/data/jenkins/workspace/impala-asf-master-core-s3/repos/Impala/testdata/bin/create-tpcds-testcase-files.sh' failed. Tail of log:
> 12:00:30 order by t_s_secyear.customer_id
> 12:00:30 ,t_s_secyear.customer_first_name
> 12:00:30 ,t_s_secyear.customer_last_name
> 12:00:30 ,t_s_secyear.customer_email_address
> 12:00:30 limit 100
> 12:00:30 Query submitted at: 2022-08-18 12:00:25 (Coordinator: http://hostname:25000)
> 12:00:30 ERROR: AnalysisException: getFileStatus on s3a://bucketname/test-warehouse/tpcds-testcase-data: com.amazonaws.SdkClientException: Unable to execute HTTP request: Timeout waiting for connection from pool
> 12:00:30 CAUSED BY: InterruptedIOException: getFileStatus on s3a://bucketname/test-warehouse/tpcds-testcase-data: com.amazonaws.SdkClientException: Unable to execute HTTP request: Timeout waiting for connection from pool
> 12:00:30 CAUSED BY: SdkClientException: Unable to execute HTTP request: Timeout waiting for connection from pool
> 12:00:30 CAUSED BY: ConnectionPoolTimeoutException: Timeout waiting for connection from pool{noformat}
> This has been tracked down to https://issues.apache.org/jira/browse/HADOOP-18410
> A temporary workaround is to specify fs.s3a.input.async.drain.threshold=512G in core-site.xml.
> We should work around this issue until the fix arrives.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org