Keith Wall created QPID-7967:
--------------------------------
Summary: [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
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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
