Ruby AMQP persistent message is deleted after restarting RabbitMQ?

Funny I was just Googling for the same problem. RabbitMQ 2.2.0, default options. In my case, Ruby clients using rubygem-amqp-0.6.7-3.

El5 from EPEL. Durable queues bound to Durable fanout exchange, publishing messages with :persistent => true. Messages lost on server restart.

-Alan.

Think I have my answer... was running "rabbitmq-server start" rather than using rabbitmqctl or the RedHat init script to stop server. Apparently the first version runs in foreground, and a control-C stops the server without initiating a flush of cached messages. Seems like using the control scripts does.

– Alan Mar 17 at 21:56 1 Thanks, this solves my problem. Oddly enough, after stopping the server via sudo rabbitmqctl stop once, a subsequent start of the rabbitmq-server and abort via control-C persists the messages. – ph0rque Mar 18 at 0:15.

As already mentioned, if you just mark messages as persistent they will not necessarily get persisted straight away, so if the server shuts down unexpectedly they may never end up on disk. So what do you do if you really need the message to be on disk, even if the server crashes? There are two things you can do.

One is to wrap your publish in a transaction. When you have committed the transaction, the message will be on disk (if it's not already delivered to a consumer of course). However, this adds a synchronous call to the server, so it can slow you down.

If you know you're going to publish a lot of messages, you can wrap a bunch of publishes in a transaction, then when you commit you know they're all on disk. The other (higher performance) alternative is to use publish confirms. But these are new in the 2.3.1 server and I don't think any Ruby clients support them yet.

Finally, RabbitMQ will anyway periodically flush persistent messages to disk even in the absence of confirms, transactions and controlled shutdowns. However there's a bug in 2.2.0 which means that this sometimes doesn't happen for a long time, so upgrading to 2.3.1 might be worthwhile.

Yes, Simon is right. About publisher confirms (described at rabbitmq.com/blog/2011/02/10/introducing...), I plan to support them in AMQP 0.8 which shall be released soon. BTW, in the original example, the first argument for publish is supposed to be the actual data, everything else is specified via options, so it's publish(message, opts) rather than publish(message_id, opts).

Yup, my script just publishes an id at this point. – ph0rque Mar 18 at 13:04.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.