[ https://issues.apache.org/jira/browse/AMQ-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887825#comment-15887825 ]
Gary Tully commented on AMQ-6414: --------------------------------- [~cshannon] I think it is ok as it is now, so long as we don't get a concurrent read which your initialized latch sorts. If I get a chance to explore the auto scenario we can revisit. > 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.15#6346)