Looks interesting... how do you ensure transactional atomicity with this approach (e.g. on the primary broker in a transaction I receive from one queue, do work and then publish to a second queue... if the queues are replicating independently is it possible to guarantee that in the backup broker you do not have the condition that the dequeue was replicated but the enqueue was not?)
Cheers, Rob On 25 January 2012 23:32, Alan Conway <[email protected]> wrote: > For anyone who's interested: This work is coming along on branch > qpid-3603-2 (note qpid-3603 is obsolete) > At this point we have > - replication of configuration (queues, exchanges bindings) > - replication of messages > - clients directed to primary broker, excluded from backups. > - client failover (tested for c++ and python clients at this point) > > There is still work to do to support broker failover and integration with > a cluster resource manager (e.g. rgmanager.) > > I have updated the design doc to better reflect the current state of > affairs: http://svn.apache.org/viewvc/**qpid/branches/qpid-3603-2/** > qpid/cpp/design_docs/new-ha-**design.txt?view=markup<http://svn.apache.org/viewvc/qpid/branches/qpid-3603-2/qpid/cpp/design_docs/new-ha-design.txt?view=markup> > > > ------------------------------**------------------------------**--------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: > mailto:dev-subscribe@qpid.**apache.org<[email protected]> > >
