qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Godfrey (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:39:00 GMT

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