[
https://issues.apache.org/jira/browse/HADOOP-19996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18126884#comment-18126884
]
ASF GitHub Bot commented on HADOOP-19996:
-----------------------------------------
hadoop-yetus commented on PR #8816:
URL: https://github.com/apache/hadoop/pull/8816#issuecomment-6158155435
:broken_heart: **-1 overall**
| Vote | Subsystem | Runtime | Logfile | Comment |
|:----:|----------:|--------:|:--------:|:-------:|
| +0 :ok: | reexec | 0m 35s | | 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 :x: | test4tests | 0m 0s | | The patch doesn't appear to include
any new or modified tests. Please justify why no new tests are needed for this
patch. Also please list what manual steps were performed to verify this patch.
|
|||| _ trunk Compile Tests _ |
| +1 :green_heart: | mvninstall | 34m 47s | | trunk passed |
| +1 :green_heart: | compile | 11m 11s | | trunk passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | compile | 11m 4s | | trunk passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | checkstyle | 0m 48s | | trunk passed |
| +1 :green_heart: | mvnsite | 1m 8s | | trunk passed |
| +1 :green_heart: | javadoc | 0m 50s | | trunk passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | javadoc | 0m 50s | | trunk passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | spotbugs | 1m 54s | | trunk passed |
| +1 :green_heart: | shadedclient | 20m 20s | | branch has no errors
when building and testing our client artifacts. |
|||| _ Patch Compile Tests _ |
| +1 :green_heart: | mvninstall | 0m 46s | | the patch passed |
| +1 :green_heart: | compile | 10m 27s | | the patch passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | javac | 10m 27s | | the patch passed |
| +1 :green_heart: | compile | 11m 16s | | the patch passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | javac | 11m 16s | | the patch passed |
| +1 :green_heart: | blanks | 0m 0s | | The patch has no blanks
issues. |
| -0 :warning: | checkstyle | 0m 50s |
[/results-checkstyle-hadoop-common-project_hadoop-common.txt](https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8816/3/artifact/out/results-checkstyle-hadoop-common-project_hadoop-common.txt)
| hadoop-common-project/hadoop-common: The patch generated 1 new + 131
unchanged - 0 fixed = 132 total (was 131) |
| +1 :green_heart: | mvnsite | 1m 12s | | the patch passed |
| +1 :green_heart: | javadoc | 0m 57s | | the patch passed with JDK
Ubuntu-21.0.12.1+1-1-24.04.4-Ubuntu |
| +1 :green_heart: | javadoc | 0m 49s | | the patch passed with JDK
Ubuntu-17.0.20.1+1-1-24.04-Ubuntu |
| +1 :green_heart: | spotbugs | 2m 3s | | the patch passed |
| +1 :green_heart: | shadedclient | 21m 41s | | patch has no errors
when building and testing our client artifacts. |
|||| _ Other Tests _ |
| +1 :green_heart: | unit | 18m 37s | | hadoop-common in the patch
passed. |
| +1 :green_heart: | asflicense | 0m 38s | | The patch does not
generate ASF License warnings. |
| | | 153m 50s | | |
| Subsystem | Report/Notes |
|----------:|:-------------|
| Docker | ClientAPI=1.56 ServerAPI=1.56 base:
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-8816/3/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 1a34e8c958f7 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 / 72358d4be45a0084a3306a0d90f4ca87e20e2b8c |
| 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/3/testReport/ |
| Max. process+thread count | 1286 (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/3/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]
