<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

<div>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
What I mean when I say "reliable" is: All subscribers at the time of<br>
publish will eventually get the message.<br>
<br>
That should be possible, assuming that all live inconsistent nodes will<br>
eventually rejoin (without dumping messages). I know this is not the<br>
case in rabbitmq, but it is definitely theoretically possible. I guess<br>
this is what is usually referred to as eventual consistency.<br>
</blockquote>
</div>
So why did you originally say:<div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
It must be a cluster because we want clients to be able to connect to<br>
each node transparently. Federation is not an option.<br>
</blockquote>
</div>
...because it really sounds like federation is what you want :-)<br></blockquote><div> </div><div>Services in our setup must be ignorant to which of the two data centers they are connected to. Since queues are not mirrored, this is not possible with a federation.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div>
Do you know what the consequence of doubling it might be?<br>
</div></blockquote>
<br>
It will take twice as long to conclude that a remote node that is no longer connected has actually gone away. Until then, things can block.</blockquote><div> </div><div>Thanks. Perfect.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

<div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">


About the CAP theorem in relation to rabbit.<br>
Reliable messaging (zero message loss), is often preferred in<br>
SOA-settings. I wonder why vmware/pivotal/... chose not to prioritize<br>
this guarantee. It is aimed by the federation setup, but it is a little<br>
to weak in its synchronization. It would be preferred if it had a<br>
possibility of communicating consumption of messages. Then one could<br>
mirror queues between up/down-stream exchanges, and have even more<br>
"availability".<br>
</blockquote></div>
<br>
I'm not sure what you're talking about here. </blockquote><div> </div><div>Sorry for being unclear.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

Federation certainly should be able to ensure zero message loss! (Assuming you leave it in "on-confirm" ack-mode).</blockquote><div> </div><div>Yes, assuming that there actually is a queue (with a binding) on the right node.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">

So when you say "if it had a possibility of communicating consumption of messages" you're talking about a sort of eventually consistent federated mirrored queue? I have wondered about producing such a thing. But as usual the list of things we could do is large, and the resources small. And I suspect the cost of producing it would be quite large, mostly due to the need to somehow reunify the queues after a partition.</blockquote>

<div> </div><div>This is really exactly what is needed IMO. It sounds very much like this is the setup TIBCO uses, when guaranteeing zero-message-loss.</div><div>I definitely appreciate that the reunification procedure is not simple. However, mirrored queues are usually somewhat static (in that they are created once and lives forever). Maybe a simple queue union, with some sort of message consumption union as well, so node 1 can delete messages consumed on node 2. I suppose it could be implemented efficiently by adding a sequence number to the messages in each queue, and then having a list of intervals of consumed message sequence numbers, or similar.</div>

<div> </div><div>It would be a great (!) addition to rabbitmq, and I am very interested in hearing of any progress.</div><div> </div><div>Thank you big time,</div><div>-- S :-)</div></div></div></div>