You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
carantunes
changed the title
Race condition between ack/nack (mode client/client-individual) and disconnects
Race condition between ack/nack (mode client/client-individual) and disconnects (+ Fix provided)
Jul 22, 2022
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 aACK
orNACK
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 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
wait
parameter to thedisconnect
method, which allows instantly stop receiving and enables wait for current threads to finish already startedacks/nacks
before stoping executing and closing the socket.The text was updated successfully, but these errors were encountered: