[jira] [Commented] (AMQ-6414) The nio+ssl transports can block and hang on connection in certain situations

["Bruce Dodson (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQ-6414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15549415#comment-15549415 ] 

Bruce Dodson commented on AMQ-6414:
-----------------------------------

Reviewing the changes in e.g. NIOSSLTransport.java, considering your description of why it occurs, and comparing to the 5.13.4 source code, it appears this bug could affect earlier versions as well - or did it surface only in 5.14.0 due to other changes elsewhere? (In other words, more to the point, if we're using 5.13.4 and nio+ssl, is it advisable to upgrade to 5.14.1?) Thanks!

> 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)