-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[chore](dep)upgrade netty and hadoop #57226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
Thank you for your contribution to Apache Doris. Please clearly describe your PR:
|
|
run buildall |
TPC-H: Total hot run time: 16495 ms |
TPC-DS: Total hot run time: 106778 ms |
|
run buildall |
ClickBench: Total hot run time: 28.01 s |
FE UT Coverage ReportIncrement line coverage `` 🎉 |
|
run buildall |
|
PR approved by at least one committer and no changes requested. |
|
PR approved by anyone and no changes requested. |
|
run buildall |
TPC-DS: Total hot run time: 189690 ms |
ClickBench: Total hot run time: 27.85 s |
|
run buildall |
TPC-DS: Total hot run time: 190007 ms |
ClickBench: Total hot run time: 27.84 s |
FE UT Coverage ReportIncrement line coverage `` 🎉 |
ClickBench: Total hot run time: 27.73 s |
|
run buildall |
1 similar comment
|
run buildall |
ClickBench: Total hot run time: 27.94 s |
FE UT Coverage ReportIncrement line coverage `` 🎉 |
|
PR approved by at least one committer and no changes requested. |
upgrade netty and hadoop
upgrade netty and hadoop
…mpatible services. (#58566) … This PR addresses an issue related to AWS SDK for Java v2 S3 client behavior described in: aws/aws-sdk-java-v2#5805 Starting from newer versions of the SDK, the S3 client introduces unexpected behavior that causes our application to fail during normal S3 operations. Due to this problem, we were forced to downgrade aws-s3 from the latest version to 2.29.x, which restored correct functionality. The regression affects stability in our production environment and prevents us from upgrading the SDK. #57226
…mpatible services. (#58566) … This PR addresses an issue related to AWS SDK for Java v2 S3 client behavior described in: aws/aws-sdk-java-v2#5805 Starting from newer versions of the SDK, the S3 client introduces unexpected behavior that causes our application to fail during normal S3 operations. Due to this problem, we were forced to downgrade aws-s3 from the latest version to 2.29.x, which restored correct functionality. The regression affects stability in our production environment and prevents us from upgrading the SDK. #57226
…mpatible services. (#58566) … This PR addresses an issue related to AWS SDK for Java v2 S3 client behavior described in: aws/aws-sdk-java-v2#5805 Starting from newer versions of the SDK, the S3 client introduces unexpected behavior that causes our application to fail during normal S3 operations. Due to this problem, we were forced to downgrade aws-s3 from the latest version to 2.29.x, which restored correct functionality. The regression affects stability in our production environment and prevents us from upgrading the SDK. #57226
…mpatible services. (apache#58566) … This PR addresses an issue related to AWS SDK for Java v2 S3 client behavior described in: aws/aws-sdk-java-v2#5805 Starting from newer versions of the SDK, the S3 client introduces unexpected behavior that causes our application to fail during normal S3 operations. Due to this problem, we were forced to downgrade aws-s3 from the latest version to 2.29.x, which restored correct functionality. The regression affects stability in our production environment and prevents us from upgrading the SDK. apache#57226
…9512) ### What problem does this PR solve? When creating an AWS SDK V2 async client (e.g. S3AsyncClient), the SDK requires a thread pool to manage asynchronous task scheduling, timeouts, and retries (e.g. ScheduledExecutorService or async executor). If no executor is explicitly provided, the AWS SDK creates its own internal thread pool, which is expected to be shut down when client.close() is invoked. ### Issue In Doris, when using Paimon Catalog, some catalog implementations provide an empty close() method. As a result, when a user executes DROP CATALOG: starting with Hadoop 3.4, the AWS SDK was upgraded to v2. Since #57226 upgraded HDFS to 3.4.2, the catalog runs into this issue. Some Catalog instance is discarded,AWS SDK client.close() is never called,The internally created thread pool cannot be shut down. This leads to a thread leak FYI aws/aws-sdk-java-v2#3746 ### Problem Analysis The lifecycle of Catalog creation and destruction is complex and managed internally by Paimon Doris cannot reliably intervene in the call chain to enforce AWS SDK client.close() If each Catalog creates its own AWS SDK client with an internally managed thread pool, threads will continue to leak as Catalogs are repeatedly created and dropped ### Solution This PR resolves the issue by introducing a shared executor strategy: A Doris-managed shared thread pool is explicitly passed when creating AWS SDK V2 clients This prevents the AWS SDK from implicitly creating per-client internal thread pools The lifecycle of the executor is fully controlled by Doris and no longer depends on Paimon Catalog’s close() implementation With this approach, even if a Paimon Catalog’s close() method is a no-op, the system will no longer leak threads. None
…ache#59512) ### What problem does this PR solve? When creating an AWS SDK V2 async client (e.g. S3AsyncClient), the SDK requires a thread pool to manage asynchronous task scheduling, timeouts, and retries (e.g. ScheduledExecutorService or async executor). If no executor is explicitly provided, the AWS SDK creates its own internal thread pool, which is expected to be shut down when client.close() is invoked. ### Issue In Doris, when using Paimon Catalog, some catalog implementations provide an empty close() method. As a result, when a user executes DROP CATALOG: starting with Hadoop 3.4, the AWS SDK was upgraded to v2. Since apache#57226 upgraded HDFS to 3.4.2, the catalog runs into this issue. Some Catalog instance is discarded,AWS SDK client.close() is never called,The internally created thread pool cannot be shut down. This leads to a thread leak FYI aws/aws-sdk-java-v2#3746 ### Problem Analysis The lifecycle of Catalog creation and destruction is complex and managed internally by Paimon Doris cannot reliably intervene in the call chain to enforce AWS SDK client.close() If each Catalog creates its own AWS SDK client with an internally managed thread pool, threads will continue to leak as Catalogs are repeatedly created and dropped ### Solution This PR resolves the issue by introducing a shared executor strategy: A Doris-managed shared thread pool is explicitly passed when creating AWS SDK V2 clients This prevents the AWS SDK from implicitly creating per-client internal thread pools The lifecycle of the executor is fully controlled by Doris and no longer depends on Paimon Catalog’s close() implementation With this approach, even if a Paimon Catalog’s close() method is a no-op, the system will no longer leak threads. None
No description provided.