Added resiliency to RabbitMQ transport#52
Conversation
There was a problem hiding this comment.
Not in my tests. It just limits the amount of time for the respawn to occur to a sensible level.
Maximum time for a respawn = 2187 seconds.
There was a problem hiding this comment.
What about maximum retries?
There was a problem hiding this comment.
Haven't thought of adding that. It's an option. Logstash agent doesn't fail when it can't connect, so I just coded the same behavior.
|
Can you move the retry logic into somewhere else? I meant the binary to be an argparser and a Worker runner, and nothing else. This is overstepping the boundaries of what I think it should be. |
|
I'm not sure how to respawn the worker from itself, though. The binary spins up the worker. If you had a dispatch class, we could do it there. |
|
Make a dispatch class then. |
|
Eventually, sure. For now, this suits my needs. Just thought I'd share. :) |
Added resiliency to RabbitMQ transport
As per comments in #51, this PR includes some code to better handle connection dropouts as well as buffer warnings from the Pika library. It also includes exponential backoff for respawning the worker.
I've implemented a TransportException class to help with trapping specific transport errors. This can be extended for use in other transports as well, and the respawn code should pick it up correctly.