vikaskr22 opened a new pull request, #8816:
URL: https://github.com/apache/hadoop/pull/8816
…utStream to reuse the Connection
<!--
Thanks for sending a pull request!
1. If this is your first time, please read our contributor guidelines:
https://cwiki.apache.org/confluence/display/HADOOP/How+To+Contribute
2. Make sure your PR title starts with JIRA issue id, e.g.,
'HADOOP-17799. Your PR title ...'.
-->
### Description of PR
One performance issue was observed when migrated from JDK 8 to JDK 17.
Considerable throughput fall was observed with Ranger-KMS service. On analysis,
like by observing the sockets being created, It was found that KeepAlive cache
was not working. TLS debug log (shared in JIRA) suggested that it is not trying
to cache the connection while closing the stream.
When response size increases beyond the configured threshold ( In Tomcat,
it's 8 KB ), Content-Type is set to "chunked" and ChunkedInputStream is used to
read the response. No issues here.
Issue is occurring when complete JSON payload comes in one TLS record and
chunk terminator bytes are coming in a separate TLS record. Jackson , that is
being used to read the response, calls inputStream.close() as soon as it reads
the entire payload, that is closing braces (}) and doesn't wait for the
terminator chunk to arrive.
At this point, last chunk containing the terminator bytes has not yet
arrived or has not yet been unwrapped, and ChunkedInputStream.close()--->
hurry() tries to clean the unread bytes one last time without getting blocked.
This operation is non-blocking by default. As a result, JVM was not able to
clean the underlying inputStream and it can not be reused, hence connection is
being destroyed. As a result, each call to ranger-KMS is doing a fresh new TLS
handshaking.
**FIX**: As a fix, chunk terminator bytes or any unread bytes from response
inputStream is being drained explicitly before calling close() on the
underlying stream. To prevent Jackson from calling close() automatically just
after reading the json payload, JsonParser.Feature.AUTO_CLOSE_SOURCE is being
disabled. But please note that close() on underlying stream is being called
from the finally block in both cases.
Further, logic to explicitly drain and close is being kept behind a flag
which is set to "false" by default. It can be enabled by adding following
property in the core-site.xml file :
```
Key : hadoop.security.kms.client.drain.response.unread.bytes
value: true
Default value: false
```
Cluster patched with this fix improved the throughput around three times and
average latency also went down significantly.
### How was this patch tested?
- local mvn build passed.
- Tested the change by patching the internal cluster with new hadoop-common
jar.
**Note**: I had to skip few unrelated UTs for my local build as it was stuck
for very long time, like org.apache.hadoop.security.TestDoAsEffectiveUser
### For code changes:
- [ ] Does the title of this PR start with the corresponding JIRA issue id
(e.g. 'HADOOP-17799. Your PR title ...')? ==>YES
- [ ] Object storage: Have the integration tests been executed and the
endpoint
declared according to the connector-specific documentation? *Note:
Automated CI
testing doesn't cover all cases so manual testing with cloud storage
is still
required.* ==> N/A
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)? ==> N/A
- [ ] If applicable, have you updated the `LICENSE`, `LICENSE-binary`,
`NOTICE-binary` files? ==? N/A
### AI Tooling
If an AI tool was used:
- [ ] The PR includes the phrase "Contains content generated by <tool>"
where <tool> is the name of the AI tool used. ==> N/A
- [ ] My use of AI contributions follows the ASF legal policy
https://www.apache.org/legal/generative-tooling.html ==> N/A
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
