qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Keith Wall (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPID-6975) NonBlockingConnectionTLSDelegate won't read to stream end if SSLEngine is closed
Date Sat, 09 Jan 2016 23:37:39 GMT

    [ https://issues.apache.org/jira/browse/QPID-6975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15090825#comment-15090825

Keith Wall commented on QPID-6975:

I also noticed that the protocol implementations interact with NBC in an inconsistent way:

# AMQP 0-8..0-10: the receipt of the AMQP close from the client causes the {{NBC#_closed}}
 to be marked true(NonBlockingConnection#close is called from the protocol layer) and the
NonBlockingConnectionDelegate/SocketChannel shutdown immediately (as that invocation of #doWork
# For AMQP 1.0, the receipt of the AMQP close merely installs the ConnectionCloseTicker. 
The connection is not closed until either the client side closes the socket channel or the
ticker times out.

There doesn't seem to be a justification for the difference.

> NonBlockingConnectionTLSDelegate won't read to stream end if SSLEngine is closed
> --------------------------------------------------------------------------------
>                 Key: QPID-6975
>                 URL: https://issues.apache.org/jira/browse/QPID-6975
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Broker
>    Affects Versions: qpid-java-6.0
>            Reporter: Keith Wall
>             Fix For: qpid-java-6.0.1, qpid-java-6.1
>         Attachments: 0001-QPID-6975-Prevent-an-open-connection-spinning-on-the.patch
> If an AMQP peer using TLS closes the connection gracefully, a "SSL close notify" is sent
as part if the SSL goodnight from peer to Broker. 
> The {{SSLEngine}} within {{NonBlockingConnectionTLSDelegate}} on receipt of the "close
notify" will put itself into a {{SSLEngineResult.Status.CLOSED}} state.
> However, {{NonBlockingConnectionDelegate#readyForRead}} considers SSLEngineResult.Status.CLOSED
as meaning the channel is not ready for reading.  This prevents NonBlockingConnection from
ever reading the channel again, so -1 is never encountered, and the connection does not immediately
get marked as closed.  The action of the {{ConnectionClosingTicker}} masks the problem, as
it intervenes after ten seconds, and closes the connection anyway.
> The effect of this defect is to cause a tight loop involving the selector thread.  The
selector thread believes the channel is ready, the connection gets scheduled, the channel
is *not* read, and the channel gets reregistered back on the selector, and so forth.  The
tight loop continues for a 10 second burst until the CCT intervenes.  If you have may connections
being opened and closed all the time, it may appear to be a continual tight infinite loop.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message