> > Subject: RE: Queue mirroring with message grouping and clustering on
> > Windows
> >
> > > > I'm considering a Qpid.22 implementation under MS Windows for
> > > > message queueing.  In the future we might go to a mixed
> > > > environment with both Windows and Linux computers.
> > > > For fault tolerance, I want the queues to be mirrored across 2 to
> > > > 3 computers which are connected by high speed LAN. Each queue will
> > > > have multiple consumers on different computers (including some NOT
> > > > hosting the queue), so I also need to use the message grouping
> > > > feature to ensure that messages from a single source are not
> > > > processed
> > out of order.

What are the differences between choosing to use clustering to implement the 
solution vs. using ha-replication of individual queues in a non-clustered setup?

>From what I've read so far it seems that with clustering my work would be a 
>lot easier as the broker/resource manager combination would take care of 
>failover while with non-clustered I'd have to take care of a bunch of things 
>in my code -- designating master, detecting failure (which might take longer), 
>failover (including finding and connecting to the new master).

On the other hand it seems that without clustering, I could pick different 
masters for different queues (instead of having cluster resource manager 
designate a specific host as master for all of its queues) which would be one 
way of spreading the load of handling client connections. I could also have 
different operating systems hosting replicas of the same queue (I haven't found 
a cluster resource manager that runs on both Windows and Linux).

I'm also wondering about geographic site mirroring and failover. We have 2 
sites connected by a WAN. The same services are available at both locations. 
Normally a request received at one location would be processed there (and 
sending it to the other site for processing would be more "expensive" as would 
queue mirroring to the other site). But there might be situations where one 
entire site goes down -- if that were to happen it might be good to have the 
other site detect and finish processing any in-flight messages from the down 
site.

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

Reply via email to