qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-7967) [Java Broker] Internal Oracle TLS classes leaked per connection when connecting the Qpid JMS Client
Date Wed, 11 Oct 2017 09:30:00 GMT

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

Robbie Gemmell commented on QPID-7967:

It was 'deliberate' in so far as the SSL handling is all done on a per-transport basis based
on configuration and to reuse the contexts would require specific and potentially significant
hoop jumping to do so, which we dont have. As you noted, there is a way to supply a context
that gets used instead, so that could be used to achieve reuse. I wouldn't personally pursue
other options without a compelling use case.

> [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
> {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

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message