[
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 finishes).
# 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
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
