Description
There is a regression caused by AMQ-7106 that can lead to an infinite loop and high cpu usage when using the nio+ssl transport if maxFrameSize is configured. The issue shows up when several messages come into the broker that exceed the max frame size. The broker properly detects the error and kills the connection in another thread but the transport thread can get stuck in an infinite loop inside serviceRead() method of NIOSSLTransport.
It's a bit hard to tell what is going on but the issue appears to be due to the fact that the transport has already been stopped but there's no condition being hit to break the loop. The transport logic appears to get into a weird state trying to process a partial frame in a local buffer in the serviceRead() method but the logic just keeps spinning and never tries to re-read from the socket because the currentBuffer in the transport is wasn't allocated due to the async shutdown.
The fix here is pretty simple and that is to check if the transport has been stopped and exit the loop. I have only seen this with OpenWire and nio+ssl but the fix I'm adding will work for all nio+ssl and nio transports.
Attachments
Issue Links
- is caused by
-
AMQ-7106 TransportConnection pendingStop support during start is broken
-
- Resolved
-