[QPID-6975] NonBlockingConnectionTLSDelegate won't read to stream end if SSLEngine is closed

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: qpid-java-6.0
• Fix Version/s: qpid-java-6.0.1, qpid-java-6.1
• Component/s: Broker-J
• Assignee: Unassigned
• Reporter: Keith Wall
• Created: 07/Jan/16 17:08
• Updated: 02/Oct/19 19:20
• Resolved: 14/Jan/16 13:20

Description

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.

Issue Links

• is related to: QPID-6944 High CPU use sending message using SSL