[
https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16200018#comment-16200018
]
Rob Godfrey commented on QPID-7967:
-----------------------------------
Given that opening a connection will normally involve at least one synchronous
exchange at the AMQP level, I really don't see a lot of benefit in trying to
optimise the TLS handshake with context re-use. I stand by my view that for
AMQP connections we should minimize the cache size and timeout. I agree that
for HTTP (Jetty) the use case is different and there we might want to have the
standard (or at least a non-minimal) default.
> [Java Broker] Internal Oracle TLS classes leaked per connection when
> connecting the Qpid JMS Client
> ---------------------------------------------------------------------------------------------------
>
> Key: QPID-7967
> URL: https://issues.apache.org/jira/browse/QPID-7967
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Environment: Java version "1.8.0_144"
> Mac OS X 10.12.6
> Reporter: Keith Wall
>
> Performing leak analysis shows that the following internal TLS classes are
> leaked, once per TLS connection, when connecting using the Qpid JMS Client
> 0.26.0 over AMQP 1.0 with TLS. The same leak was not apparent when connecting
> the older Qpid JMS AMQP 0-x client.
> The classes are:
> # sun.security.ssl.SessionId
> # sun.security.ssl.SSLSessionImpl
> The test is run with the following command:
> {code}
> mvn exec:java -pl tools -Dstresstest=qpid-jms-client
> -Dexec.args="jndiProperties=stress-test-client-qpid-jms-client.properties
> jndiConnectionFactory=qpidConnectionFactoryTls connections=100"
> -Djavax.net.ssl.trustStore=/Users/keith/Downloads/myks.jks
> -Dqpid-jms-client-version=0.26.0
> {code}
> It seems there is session caching going on within the JDK. The cache size
> and timeout looks to be tuneable with
> {{javax.net.ssl.SSLContext#getServerSessionContext}}. The default timeout is
> 86400s (1day) and a session cache size of 0 (unbounded). I suspect if Broker
> had a sufficiently large number of TLS connections over a short time period,
> memory may be exhausted.
> -I don't currently understand why the behaviour is different between the
> old/new JMS client-. Edit - see comment below.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
