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 Tue, 10 Oct 2017 22:07:00 GMT

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