vikaskr22 commented on PR #8816: URL: https://github.com/apache/hadoop/pull/8816#issuecomment-6146759495
> BTW I'm also curious if the problem is dependent on the fact that Ranger KMS is Tomcat based not Jetty based (Hadoop KMS). Just a hunch I want to bring up. @jojochuang , thanks for the review. let me add more details: Hadoop-KMS and Ranger-KMS has same response [write path](https://github.com/apache/hadoop/blob/90a3271609155685a1d37a2efbfbf605d3a9af2e/hadoop-common-project/hadoop-kms/src/main/java/org/apache/hadoop/crypto/key/kms/server/KMSJSONWriter.java#L67): where it uses StreamEncoder as part of OutputStreamWriter to take care of encoding. This StreamEncoder has behaviour change in Java 8 & Java 17. On server side, Jackson calls the close. StreamEncoder.implClose() in Java 8 does write(bytes); & close(); In Java 17 it does write(bytes); then flush(); and then close(); That flush() propagates through Jersey's CommittingOutputStream and Tomcat's CoyoteOutputStream to OutputBuffer.doFlush(), which commits the response before its length is known → Transfer-Encoding: chunked, body in TLS record 1; the subsequent close() → ChunkedOutputFilter.end() writes 0\r\n\r\n as a separate socket write = separate TLS record 2. On a Java 8 server nothing flushes early, OutputBuffer.close() sets Content-Length and the whole response is one record; the client uses KeepAliveStream, not ChunkedInputStream. As per my analysis, same issue may happen with Hadoop-KMS as well but I have not yet verified this for Hadoop-KMS. -- 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]
