You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2017/10/10 21:58:00 UTC
[jira] [Updated] (QPID-7967) [Java Broker] Internal Oracle TLS
classes leaked per connection when connecting the AMQP 1.0 Qpid JMS Client
[ https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Keith Wall updated QPID-7967:
-----------------------------
Description:
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.
was:
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 86400(seconds?) 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.
> [Java Broker] Internal Oracle TLS classes leaked per connection when connecting the AMQP 1.0 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-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org