[ 
https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199446#comment-16199446
 ] 

Rob Godfrey commented on QPID-7967:
-----------------------------------

Given the typical use case for AMQP is long lived connections (rather than a 
more HTTP(S) style of many short-lived connections between the same two 
parties); I'm not sure it really makes sense to make much of an effort to 
support SSL session resumption.  While I've no objection to making the cache 
size and timeout configurable, I'd be tempted to set them to the minimum values 
by 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

Reply via email to