[rabbitmq-discuss] blocked producers
thierry.thelliez.tech at gmail.com
Mon Jul 22 21:50:07 BST 2013
Yes, I agree that a local queue might not be the answer (and we could go in
a recursive argument;-).
But I guess that the client/producer should have a way to store events in
case the message broker goes down. Using a local database might be an
option (although that's just another moving part and that could be
considered like a local queue system as well).
I am just curious about what people do in production.
I need to send user generated files to a conversion worker pool. If the
message broker goes down for any reason, the clients/producers need to
continue dealing with the incoming traffic and locally store the files
until the broker goes back up. In other words, it seems like the client
needs to keep a record of the ongoing transactions/conversions. Is that
On Mon, Jul 22, 2013 at 1:14 PM, Matthias Radestock
<matthias at rabbitmq.com>wrote:
> On 20/07/13 00:12, Thierry Thelliez wrote:
>> Interesting discussion. I am new to RabbitMQ and I am trying to
>> understand the coding and architecture requirements on the Producer side.
>> What happens if the Producer cannot push to a queue? Does that mean
>> that the Producer system should plan for its own local queue until the
>> broker is back? What do you do in production when you do not want to
>> loose these messages?
> That depends on the app and what failure scenarios you are most concerned
> Local queues add another moving part that itself can fail.
> Note that the thread discussed blocked producers. No messages are lost in
> that situation; message loss would only occur if client or server are
> terminated/crash or there is a prolonged network disruption.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rabbitmq-discuss