[
https://issues.apache.org/jira/browse/HADOOP-19996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126883#comment-18126883
]
ASF GitHub Bot commented on HADOOP-19996:
-----------------------------------------
hadoop-yetus commented on PR #8816:
URL: https://github.com/apache/hadoop/pull/8816#issuecomment-6158071651
:confetti_ball: **+1 overall**
| Vote | Subsystem | Runtime | Logfile | Comment |
|:----:|----------:|--------:|:--------:|:-------:|
| +0 :ok: | reexec | 7m 31s | | Docker mode activated. |
|||| _ Prechecks _ |
| +1 :green_heart: | dupname | 0m 0s | | No case conflicting files
found. |
| +0 :ok: | codespell | 0m 0s | | codespell was not available. |
| +0 :ok: | detsecrets | 0m 0s | | detect-secrets was not available.
|
| +0 :ok: | xmllint | 0m 0s | | xmllint was not available. |
| +1 :green_heart: | @author | 0m 0s | | The patch does not contain
any @author tags. |
| +1 :green_heart: | test4tests | 0m 0s | | The patch appears to
include 2 new or modified test files. |
|||| _ trunk Compile Tests _ |
| +1 :green_heart: | mvninstall | 28m 51s | | trunk passed |
| +1 :green_heart: | compile | 9m 1s | | trunk passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | compile | 9m 10s | | trunk passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | checkstyle | 0m 57s | | trunk passed |
| +1 :green_heart: | mvnsite | 1m 7s | | trunk passed |
| +1 :green_heart: | javadoc | 0m 59s | | trunk passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | javadoc | 0m 54s | | trunk passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | spotbugs | 1m 46s | | trunk passed |
| +1 :green_heart: | shadedclient | 17m 20s | | branch has no errors
when building and testing our client artifacts. |
|||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 0m 45s | | the patch passed |
| +1 :green_heart: | compile | 8m 32s | | the patch passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | javac | 8m 32s | | the patch passed |
| +1 :green_heart: | compile | 9m 8s | | the patch passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | javac | 9m 8s | | the patch passed |
| +1 :green_heart: | blanks | 0m 0s | | The patch has no blanks
issues. |
| -0 :warning: | checkstyle | 0m 54s |
[/results-checkstyle-hadoop-common-project_hadoop-common.txt](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8816/4/artifact/out/results-checkstyle-hadoop-common-project_hadoop-common.txt)
| hadoop-common-project/hadoop-common: The patch generated 1 new + 137
unchanged - 0 fixed = 138 total (was 137) |
| +1 :green_heart: | mvnsite | 1m 16s | | the patch passed |
| +1 :green_heart: | javadoc | 0m 54s | | the patch passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | javadoc | 0m 53s | | the patch passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | spotbugs | 1m 57s | | the patch passed |
| +1 :green_heart: | shadedclient | 16m 56s | | patch has no errors
when building and testing our client artifacts. |
|||| _ Other Tests _ |
| +1 :green_heart: | unit | 18m 22s | | hadoop-common in the patch
passed. |
| +1 :green_heart: | asflicense | 0m 48s | | The patch does not
generate ASF License warnings. |
| | | 139m 17s | | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.56 ServerAPI=1.56 base:
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8816/4/artifact/out/Dockerfile
|
| GITHUB PR | https://github.com/apache/hadoop/pull/8816 |
| Optional Tests | dupname asflicense compile javac javadoc mvninstall
mvnsite unit shadedclient spotbugs checkstyle codespell detsecrets xmllint |
| uname | Linux e8f2a3223d80 5.15.0-190-generic #200-Ubuntu SMP Fri Aug 7
15:06:04 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux |
| Build tool | maven |
| Personality | dev-support/bin/hadoop.sh |
| git revision | trunk / 6aab885716032f5ec346a87ea75b2424449dcbb2 |
| Default Java | Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| Multi-JDK versions |
/usr/lib/jvm/java-21-openjdk-amd64:Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu
/usr/lib/jvm/java-17-openjdk-amd64:Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| Test Results |
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8816/4/testReport/ |
| Max. process+thread count | 1272 (vs. ulimit of 10000) |
| modules | C: hadoop-common-project/hadoop-common U:
hadoop-common-project/hadoop-common |
| Console output |
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8816/4/console |
| versions | git=2.43.0 maven=3.9.15 spotbugs=4.9.7 |
| Powered by | Apache Yetus 0.14.1 https://yetus.apache.org |
This message was automatically generated.
> With Java 17 KeepAlive caching not working when KMSClientProvider makes
> requests to KMS
> ---------------------------------------------------------------------------------------
>
> Key: HADOOP-19996
> URL: https://issues.apache.org/jira/browse/HADOOP-19996
> Project: Hadoop Common
> Issue Type: Bug
> Components: hadoop-common
> Reporter: Vikas Kumar
> Assignee: Vikas Kumar
> Priority: Major
> Labels: pull-request-available
>
> Recently after upgrading from Java 8 to Java 17 on one existing cluster, we
> observed more than 70% drop in the throughput between client app using
> KMSClientProvider to make requests to Ranger-KMS.
> Apart from throughput, average latency also increased. As soon as we rollback
> to Java 8, it was back to normal.
> Further we found, Ranger-KMS with Java 17 and client using hadoop-common's
> KMSClientProvider with Java 8 is working fine. If we switch to Java 17 on
> the client side, issue starts occuring.
> *My observation and debugging:*
> I suspected the new features of Java 17 like GC and default TLSv1.3 might be
> impacting the throughput. I tried with parallel GC as well, it didn't help.
> Ranger-KMS and client app were explicitly configured to use TLSv1.2 only.
> Still issue persists.
> Enabled tls debug log and can see very frequent *Connection reset* warning
> stack trace. I know that it may happen when server closes the connection due
> to idleTimeout. But frequency was high in Java 17 env in comparison to very
> few occurrences or zero occurrences in env with Java 8.
> Apart from Connection reset, many "Broken pipe" traces were there.
> *Thread dump analysis on the Ranger-KMS side:*
> At the time when client app was getting Connection reset/broken pipe, many
> of the KMS worker threads were occupied in I/O op with underlying socket's
> stream. Load on KMS was not increasing, many of the threads were idle waiting
> for the new task.
> I observed one difference in Java 17 & Java 8 Socket close stack trace on
> client app side:
> *Following is with Java 8:*
>
> {code:java}
> at sun.net.www.http.HttpClient.closeServer(HttpClient.java:1075)
> at sun.net.www.protocol.https.HttpsClient.closeServer(HttpsClient.java:428)
> at sun.net.www.http.KeepAliveCache.put(KeepAliveCache.java:196)
> at
> sun.net.www.protocol.https.HttpsClient.putInKeepAliveCache(HttpsClient.java:667)
> at sun.net.www.http.HttpClient.finished(HttpClient.java:397)
> at
> sun.net.www.http.ChunkedInputStream.closeUnderlying(ChunkedInputStream.java:219)
> at sun.net.www.http.ChunkedInputStream.processRaw(ChunkedInputStream.java:455)
> at
> sun.net.www.http.ChunkedInputStream.readAheadNonBlocking(ChunkedInputStream.java:520)
> at sun.net.www.http.ChunkedInputStream.readAhead(ChunkedInputStream.java:611)
> at sun.net.www.http.ChunkedInputStream.hurry(ChunkedInputStream.java:768)
> at
> sun.net.www.http.ChunkedInputStream.closeUnderlying(ChunkedInputStream.java:221)
> {code}
> *And following is with Java 17:*
>
>
> {code:java}
> at java.base/sun.net.www.http.HttpClient.closeServer(HttpClient.java:1155)
> at
> java.base/sun.net.www.protocol.https.HttpsClient.closeServer(HttpsClient.java:445)
> at
> java.base/sun.net.www.http.ChunkedInputStream.closeUnderlying(ChunkedInputStream.java:222)
> at
> java.base/sun.net.www.http.ChunkedInputStream.close(ChunkedInputStream.java:769)
> at java.base/java.io.FilterInputStream.close(FilterInputStream.java:179)
> {code}
> Note the difference,
>
> In Java 8 when client calls close() on underlying stream, it tries to drain
> any unread bytes left on the inputStream. And there it succeeds , stream is
> clean and retuned to the KeepAlive cache. You can observe
> *HttpsClient.putInKeepAliveCache*
> Same is not happening in Java 17 cluster. Here also it tries to drain the
> unread bytes but fails. hence connection destroyed and connection caching is
> not happening.
> This behaviour indicated towards possibility of connection leaks.
> Check the code
> [here|https://github.com/apache/hadoop/blob/997fa7c12a407c441855f1a409767f198db68cd3/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/crypto/key/kms/KMSClientProvider.java#L585]
> , In KMSClientProvider.java, when it gets 401 it goes to KMS again with
> required tokens. And for this it creates a new Connection , assign it to
> existing "con" reference variable. It missed to close the older connection.
> In the same method, in finally block it calls
> IOUtils.closeStream(is) for new connection.
>
> *To prove this finding,* If I simply drain the unread bytes (if exists)
> explicitly before calling close(), I start getting similar throughput that I
> was getting with Java 8, now I can't see any Connection reset or errors in
> the log.
>
> For example: Average latency without patch was around 225 ms and after patch
> it reduced to around 60-65 ms.
>
> PS: I read that in higher versions of Java, {{SLSocketImpl}} was completely
> rewritten around {{SSLEngine}} record boundaries. I suspect some behaviour
> difference.
>
> *Proposed Fix:* Irrespective of any behaviour difference, it would be better
> to drain the stream before closing.
>
> Request community members to review this and suggest. If this finding is
> correct, I can raise the PR.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
