Yes, I forgot to mention that but I've been running with -Djavax.net.debug=ssl:handshake:verbose and sometimes -Djavax.net.debug=all.
I think I have a strong theory of what the culprit might be. I found this post: http://qpid.2158936.n2.nabble.com/One-SSL-SASL-EXTERNAL-queue-creation-works-with-qpidd-1-36-0-but-not-1-35-0-td7657344.html. In the post above the user mentions the SSL_STREAM_MAX_WAIT_ms definition. The critical log statements I mentioned in the first post also come from SslSocket.cpp. In SslMuxSocket::accept() it calls isSslStream(fd) which effectively determines whether the stream is SSL or Plaintext. My theory is that in versions of Java prior to 1.8u272 the SASL/SSL/TLS functionality must simply be faster, or results in less network traffic or something that results in a successful negotiation with the secure broker much more consistently than the newer versions. As I mentioned in my first post, there were significant updates made to this functionality in 272+. It is possible that this layer is more complex/robust but also resulted in a performance decrease from the older versions which results in inconsistent connections in our computing environment. Passing "-Djdk.tls.client.cipherSuites=<single ciper suite>" seems to at least marginally increase performance to the point where I see more consistent connections with the broker. I've done other things like set the initial heap size (i.e. -Xms) to the same as the max heap size (in order to prevent subsequent allocations) which I read online could help start up speed. Is there a good reason the SSL_STREAM_MAX_WAIT_ms and SSL_STREAM_MAX_RETRIES are not configurable? I fully admit to not knowing much at a deep level about these protocols and interactions--I'm just an application developer who happened upon this issue in the course of his work. I'm also a bit hamstrung testing some of these theories as my company utilizes heavily restricted development environments. -- Sent from: http://qpid.2158936.n2.nabble.com/Apache-Qpid-users-f2158936.html --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
