vineethgn commented on PR #9188: URL: https://github.com/apache/kafka/pull/9188#issuecomment-1178145392
Based on the discussion in https://github.com/apache/kafka/pull/5785/, i tried the fix in this PR, it didnt work for me. I tried to reproduce the issue and i can reproduce the issue consistently in the following conditions. 1. [Conscrypt](https://github.com/google/conscrypt) as ssl provider 2. openjdk-11-jdk I checked by adding additional logs and could find that the packet buffer size and app buffer returned by Conscrypt ssl engine mismatches. Below are the logs that i got SSl engine class org.conscrypt.Java8EngineWrapper (org.apache.kafka.common.network.SslTransportLayer) SSl engine session class org.conscrypt.Java8ExtendedSSLSession (org.apache.kafka.common.network.SslTransportLayer) SSl engine session App Buffer Size 16384 (org.apache.kafka.common.network.SslTransportLayer) SSl engine session Net Buffer Size 16709 (org.apache.kafka.common.network.SslTransportLayer) Since this was a blocker, i modified the Ssltransportlayer to have appreadbuffer atleast the same size as netreadbuffer, before call to unwrap. Is it ok to have appReadBuffer atleast the same size as netReadBuffer ? so far the clusters are running smoothly without buffer overflow or underflow issue. below is the code fix that i made that seemed to be working fine so far without further issues. while (netReadBuffer.position() > 0) { netReadBuffer.flip(); SSLEngineResult unwrapResult; try { appReadBuffer = Utils.ensureCapacity(appReadBuffer, netReadBufferSize()); unwrapResult = sslEngine.unwrap(netReadBuffer, appReadBuffer); -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
