[
https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199999#comment-16199999
]
Keith Wall commented on QPID-7967:
----------------------------------
>From the Broker's perspective, my concern is that a client, using SSL, caught
>in a reconnect loop caused by a bad password or poison message could exhaust
>memory. I think we should give the settings (sessionTimeout and
>sessionCacheSize) sensible defaults - which would be different for AMQP and
>HTTP, and allow them to be overridden. I'm thinking new derived attributes on
>Ports defaulted from AMQP and HTTP specific context variables.
Turning to the Qpid JMS client. I agree that ideally AMQP should be used with
long lived connections, but in practice I do see many instances of applications
using short lived connections (mostly resulting from misconfigured Spring JMS
applications). SSL Session resumption is enabled by default in the JVM if you
reuse the same SSLContext. The current Qpid JMS Client implementation doesn't
benefit from this default because it re-creates the SSLContext for each
connection. I wonder if this was a deliberate decision. I'll start a
separate discussion with Tim and Robbie. This would be a low priority item
from my perspective.
> [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
> -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: [email protected]
For additional commands, e-mail: [email protected]
