+3  A: 

You're basically considering writing an ad-hoc extension to your messaging server, the job of which it is to provide whatever reliability guarantees you've asked of it.

Instead, perhaps you should take the hardware where you were planning to run this new proxy and run another MQ node on it. The new node should take care of persisting and relaying messages that you deliver to it while the other nodes are overloaded or offline.

Jean-Paul Calderone
Agreed, OP should take a look at using RabbitMQ's clustering features.
Tom
Thanks, I've realized that this would indeed be better approach. I'm gonna take some time to rethink this over.
gasper_k
A: 

A neat solution to this problem would be to use the Key Value store Redis. Its a high speed persistent data store, with plenty of clients - it has a php and a python client (if you want to use a timed/batch process to process messages - it saves you creating a database, and also deals with your persistence stories. It runs fine on Cywin/Windows + posix environments.

PHP Redis client is here.

Python client is here.

Both have a very clean and simple API. Redis also offers a publish/subscribe mechanism, should you need it, although it sounds like it would be of limited value if you're publishing to an inconsistent queue.

Ben Hughes
It's a possible solution, and we're already considering Redis for something else, so it wouldn't be new. But, as I said above, I'm rethinking the whole thing, because it doesn't feel right. Thanks for your reply.
gasper_k
A: 

Maybe it's not the best bang for your buck to use a separate thread in Twisted to get around a blocking call, but sometimes the least evil solution is the best. Here's a link that shows you how to integrate threading into Twisted:

http://twistedmatrix.com/documents/10.1.0/core/howto/threading.html

Sometimes in a pinch easy-to-implement is faster than hours/days of research which may all turn out to be for nought.

Joel M Ward