qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (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 Thu, 12 Oct 2017 14:55:00 GMT

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

ASF subversion and git services commented on QPID-7967:

Commit 39a6419b0686b83106ce98c00ea0945c50e433df in qpid-broker-j's branch refs/heads/master
from [~alex.rufous]
[ https://git-wip-us.apache.org/repos/asf?p=qpid-broker-j.git;h=39a6419 ]

QPID-7967: [Java Broker] Fix context variables description

> [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
>            Assignee: Alex Rudyy
>             Fix For: qpid-java-broker-7.0.0
> 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