[
https://issues.apache.org/jira/browse/AMQ-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15455803#comment-15455803
]
ASF subversion and git services commented on AMQ-6414:
------------------------------------------------------
Commit ed0e786b6002633411037923fb28a075489e442b in activemq's branch
refs/heads/master from [~cshannon]
[ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=ed0e786 ]
https://issues.apache.org/jira/browse/AMQ-6414
Changing the nio+ssl transports to trigger a serviceRead after start up
to prevent blocking. The prevents the channels from not reading in
certain cases, most notably with the auto+nio+ssl transport when used
for a network bridge. Also added a couple tests and changed a network
bridge test to test out auto+nio+ssl.
> 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)
