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
The current implementation of AutoRecoveringProducer is based on retries. When a connection to broker is lost, and the underlying Producer is closed, it will throw ProducerClosedException on each SendAsync or Send call. The exception is caught and after a certain, hard-coded amount of time, the operation is issued again. If the underlying producer was recovered in the meantime, the message should be sent. If however, it is still down, the exception is thrown, and the cycle starts again. This should be replaced with a solution based on signaling (hopefully asynchronous). All pending send operations should wait until the underlying producer is recovered.
Havret
changed the title
Use asynchronous signaling to invoke pending send actions when Producer recovered
Use asynchronous signaling to invoke pending send operations when Producer recovered
Jan 11, 2020
The current implementation of
AutoRecoveringProducer
is based on retries. When a connection to broker is lost, and the underlyingProducer
is closed, it will throwProducerClosedException
on eachSendAsync
orSend
call. The exception is caught and after a certain, hard-coded amount of time, the operation is issued again. If the underlying producer was recovered in the meantime, the message should be sent. If however, it is still down, the exception is thrown, and the cycle starts again. This should be replaced with a solution based on signaling (hopefully asynchronous). All pending send operations should wait until the underlying producer is recovered.Initially I was thinking about using AsyncManualResetEvent but it seems it has a nasty bug that may cause deadlocks.
The text was updated successfully, but these errors were encountered: