qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: [C++ Broker] dynamically federated links
Date Thu, 07 Jan 2016 15:32:24 GMT
On 01/06/2016 04:34 PM, Matt Broadstone wrote:
> On Wed, Jan 6, 2016 at 11:14 AM, Matt Broadstone <mbroadst@gmail.com> wrote:
>> Just one more question that doesn't seem to be covered in the
>> documentation: is it possible with just `qpid-route` to configure
>> replication of queues across federated brokers?  It seems that the
>> `qpid-route queue` related commands all bind a given queue to a remote
>> exchange, where ideally it would be possible to federate two brokers and
>> maintain a shared queue between them.
>> Matt
> It might be better to clarify my particular use case here. I know that it
> seems that using qpid-ha is probably the way to go in my case, however, it
> seems that qpid-ha is designed in such a way that clients are all meant to
> connect to the primary broker.  In our case, the desired behavior would be
> for all clients on a local machine connect to that machine, which is in
> turn federated to a cluster (thus alleviating the need in our case to track
> and dynamically connect to the IP of the primary broker).  So this leads me
> to a number of questions:
> a) it seems I can accomplish this mostly (with exchange types) through
> plain old federation, and as such have great flexibility over my design
> b) (copied from above) is it possible to easily replicate queues using
> plain federation?

No, the 'federation' feature only transfers messages. It cannot 
propagate any dequeue operations. As such it can't be used on its own to 
create a replica of a queue (which tracks the original queues state).

(The ha feature uses federation, but adds extra capabilities on top of it).

> c) If, instead, qpid-ha is used to satisfy these needs, is it possible to
> configure qpid-ha such that clients can directly connect to backup cluster
> members and interact with the cluster in some sort of "proxy" mode
> (proxying everything up to the primary broker, while maintaining the back
> channel that backs up the primary broker)

The replication uses queue sequence for identifying messages so if you 
alter a replica queue it will almost certainly break replication.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message