activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher L. Shannon (JIRA)" <j...@apache.org>
Subject [jira] [Created] (AMQ-6414) The nio+ssl transports can block and hang on connection in certain situations
Date Thu, 01 Sep 2016 15:38:20 GMT
Christopher L. Shannon created AMQ-6414:
-------------------------------------------

             Summary: The nio+ssl transports can block and hang on connection in certain situations
                 Key: AMQ-6414
                 URL: https://issues.apache.org/jira/browse/AMQ-6414
             Project: ActiveMQ
          Issue Type: Bug
          Components: Broker, Transport
    Affects Versions: 5.14.0
            Reporter: Christopher L. Shannon
            Assignee: Christopher L. Shannon


The nio+ssl transports can hang on initial connection and never read from the socket after
the SSL handshake for certain conditions.  This behavior is most evident when using the auto+nio+ssl
transport for a network bridge between 2 brokers, however I also saw the issue for the normal
nio+ssl transport when running the NetworkAsyncStartTest and even the amqp+nio+ssl transport.

After debugging I found that the issue is that the onSelect method of the registered callback,
which calls the serviceRead() method, is not always getting triggered.  I believe that the
root of the problem is that even though a selector is registered with a SelectionKey.OP_READ,
there is no guarantee that the selected set is correct which is what the SelectorWorker uses
to detect if the operation is ready. The SelectionKey documentation specifically states that
the ready set is a hint but not a guarantee that the channel is ready.  This seems to only
effect the SSL transport (not normal NIO), probably because a read selection was already done
once to unwrap the SSL transport

More info: https://docs.oracle.com/javase/8/docs/api/java/nio/channels/SelectionKey.html

The fix for this is to trigger the selectRead() after the transport finishes starting up.
 (needs to be in a new thread specifically for OpenWire to allow the wireformat negotiation
to not block on startup).  This will work for the SSL transport specifically since we know
the transport is read to read from the the channel after starting up.  We know this because
the SSL handshake already took place which means we've already read from the channel.





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message