Le 03/06/2011 04:33, Robert Collins a écrit : Hi Robert, thanks for sharing the ideas. I have one slightly unrelated discussion point:
> Rabbit has an awkward high availability story; specifically its not > trivial to get the reliability we have out of HTTP services, This is > partly because rabbit clusters don't distribute the queues and because > its a more stateful and complex system than HTTP. I've been think about that, and I wonder how much we could cheat for some specific workloads: if you have "short-lived" queues, I was thinking that the application (or a smart proxy) could publish messages to all the different RabbitMQ instances available. Consumers would then consume from *one* of those RabbitMQ instance, and the others would expire after some time. You'd probably have to manage duplicate messages on the consumer side, but that's generally the case anyway. It may be a lot of work to workaround the shortcomings of RabbitMQ you mention, though. -- Thomas _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
