Hi Rob, Thanks for writing. Please see inline.
On Fri, Jan 20, 2012 at 1:35 AM, Rob Godfrey <[email protected]>wrote: > Hi Praveen, > > On 14 January 2012 02:47, Praveen M <[email protected]> wrote: > > > Hi, > > > > Are there any java broker high availability/clustering solutions that > > are currently present? I tried googling around and didn't find anything > to > > my luck. > > > > Can you please suggest a HA strategy that you've used working with the > Qpid > > Java Broker? > > > > > So where I work we have two separate strategies for "HA" and disaster > recovery. > > For HA we use synchronous replication of the BDB store, with external > software monitoring the availability of the primary broker machine. If the > primary broker machine goes down, the external software starts up the > secondary broker machine, which points to the synchronously replicated > instance of the store... it can also handle reassignment of the IP address > / DNS name. > *Is there a reason that you use an external software to monitor the availability of the primary broker machine.?* *Shouldn't the connection failover model be sufficient enough for this? Or does the failover model have any limitations? * * * *Also, you mention synchronous replication of BDB. Can you please write a bit about how you go about doing this? I think with syncCommit false, sync replication could be something that could work for us too without really jeopardizing the enqueue latencies.* > For DR we take regular snapshots of the BDB store files and ship these > using an FTP-like mechanism to a DR site. Clearly with this solution you > run the risk of loss as you only have a snapshot from a known point in > time, not from the very moment the system went down. > > *Ah yes, this runs the risk of losing messages. Did you not consider a synchronous replication in this case too?* *Or is it because of the distance of the DR site that could contribute to high latency round trips. Just curious.* In our model our transaction store which contains a copy of the message will be DR'ed. > > I found a Message Federation design proposal document, but I'm guessing > > it's not implemented yet (Please correct me if I'm wrong). > > > > > There is an alpha/beta implementation of Message Federation in the Java > Broker, which follows the same design as that in the C++ broker and uses > the same toolset to create routes. This code is broken in the most recent > releases of the Java Broker, but should work "better" from trunk... however > I'm not going to give any guarantees on it's suitability for a production > system right now (I hope to be doing some serious testing/fixing over the > next couple of months). > > > > I plan to spin off two brokers on two different machines and use a > failover > > connection model to route messages to one if the other goes down. This > > works well for message enqueues. > > But still, I'd run the risk of not being able to process the messages in > > the broker that just went down (until it's back up). It will be nice to > > know if someone had solved a similar problem by other > > strategies/solutions available with the broker. > > > > Also, has someone tried replicating the database used for > > the persistent store to solve this problem (BDB/Derby ?) > > > > > As above, we use replication, but managed by hardware/external software. > I've not yet tried using BDB's own HA solutions to provide replication. > > *well. Is the replication too driven by an external software. I'm curious on how you go about doing a synchronous* *replication with BDB (as this is the route that we might want to take). Any tips here will be useful. * * * *If you are allowed to talk about the hardware/external software piece I'd love to hear more about your HA* *architecture. (I do understand sometimes NDAs might stop you. If so, it's okie).* > > Please do share your experience in this area. > > > > > Hope this helps, > *It sure does. Thanks a lot for taking your time to write. * > Cheers, > Rob > -- -Praveen
