“stomp.py” is a Python client library for accessing messaging servers (such as ActiveMQ or RabbitMQ) using the STOMP protocol (versions 1.0, 1.1 and 1.2). It can also be run as a standalone, command-line client for testing.
Apache License 2.0
491
stars
167
forks
source link
Race condition between ack/nack (mode client/client-individual) and disconnects (+ Fix provided) #393
I identified a race condition when there's some load of processing messages and a disconnect occurs.
This issue only occurs with ack mode client/client-individual which means a ACK or NACK frame will be sent to the server.
In such cases, between the milliseconds a disconnect begins and concludes, some other threads might start processing a new message and when trying to send the frame ACK/NACK will result in either a native BrokenPipeError (unhandled by stompy) or a org.apache.activemq.transport.stomp.ProtocolException: Not connected (properly handled).
I'm providing a MR associated with the issue, showcasing the issue in a new test case and a solution.
For the test case I rely on repetition given that the issue is a race condition.
For the solution I suggest the addition of a wait parameter to the disconnect method, which allows instantly stop receiving and enables wait for current threads to finish already started acks/nacks before stoping executing and closing the socket.
I identified a race condition when there's some load of processing messages and a disconnect occurs. This issue only occurs with ack mode
client/client-individualwhich means aACKorNACKframe will be sent to the server.In such cases, between the milliseconds a disconnect begins and concludes, some other threads might start processing a new message and when trying to send the frame
ACK/NACKwill result in either a nativeBrokenPipeError(unhandled by stompy) or aorg.apache.activemq.transport.stomp.ProtocolException: Not connected(properly handled).I'm providing a MR associated with the issue, showcasing the issue in a new test case and a solution. For the test case I rely on repetition given that the issue is a race condition.
For the solution I suggest the addition of a
waitparameter to thedisconnectmethod, which allows instantly stop receiving and enables wait for current threads to finish already startedacks/nacksbefore stoping executing and closing the socket.