[
https://issues.apache.org/jira/browse/QPID-7967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16199431#comment-16199431
]
Keith Wall commented on QPID-7967:
----------------------------------
The classes I highlight above are those relating to the server side's support
for SSL session resumption.
* When connecting the Qpid JMS Client AMQP 0-x, the objects don't accumulate
because the client fails to close the TLS connection cleanly [1]. The abnormal
close disallows the SSL session resumption so the server won't preserve them
needlessly [2].
* When connecting the Qpid JMS Client, it does close the TLS connection
cleanly, so the server side preserves caches the objects. However, as the Qpid
JMS Client doesn't (by default) reuse its {{SSLContext}}, the client does not
take advantage of this. This is why I see the number of cached sessions on the
server grows. Side note: I notice I can workaround by passing an SSLContext
into the client (is there a better way??):
{code}
ConnectionFactory factory = (ConnectionFactory)
context.lookup("myFactoryLookup");
((JmsConnectionFactory)
factory).setSslContext(TransportSupport.createSslContext(new
TransportSslOptions()));
{code}
With this I see the shortened SSL handshake evident from the client with
{{-Djavax.net.debug=ssl}} enabled:
{noformat}
..%% Client cached [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256]
%% Try resuming [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] from port -1
*** ClientHello, TLSv1.2
...
{noformat}
[1]https://issues.apache.org/jira/browse/QPID-6981
[2] RFC 2246 section 7.2 "Alert protocol" https://www.ietf.org/rfc/rfc2246.txt
> [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: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
