[
https://issues.apache.org/jira/browse/AMQ-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549428#comment-15549428
]
Christopher L. Shannon commented on AMQ-6414:
---------------------------------------------
It could happen for earlier versions also so upgrading is probably a good idea.
However, in my testing it seemed to happen pretty rarely and certain things
(like using the auto transport) made it more likely so if you haven't seen it
happen yet then it may not happen in your environment.
> 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
> Fix For: 5.14.1, 5.15.0
>
>
> 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)
