It was a couple of years ago and I'm not sure I still have the code lying around... and even if I did the codebase has changed sufficiently that it would probably be quicker to start from scratch anyhow. I was basically looking at creating a virtualhost(node) which used zookeeper to to majority election / simple cluster management... and leave how data was replicated as a black box (so you could use a RDBMS or something else). The concept wasn't terribly hard, the implementation was just a bit fiddly because zookeeper really wanted to have its own configuration files, and I really wanted it to be embedded into Qpid and provide its configuration programmatically :-)
-- Rob On 30 November 2016 at 18:47, Adel Boutros <[email protected]> wrote: > Great information! > > > I honestly think it has a value to decouple from the use of Berkley DB > because of its license. We have adopted a way which consists of using the > Qpid dispatch router in front of brokers for some sort of High Availability > but it is not sufficient of course. > > > Do you still have the work you did? Maybe we can find an easy solution for > the agent part. > > > Regards, > > Adel > > ________________________________ > From: Rob Godfrey <[email protected]> > Sent: Wednesday, November 30, 2016 4:48:17 PM > To: [email protected] > Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same > JDBC url > > On 30 November 2016 at 15:32, Adel Boutros <[email protected]> wrote: > > > Thanks Rob! > > > > > > So if I understand correctly, if the second broker is restarted then he > > will see all changes performed on the first broker (added/removed queues, > > stored messages ...) without impacting the first broker. > > > > It will see the state at the point of time that the broker starts - it > won't see any changes made on the first broker beyond that point. Once the > broker starts it assumes its in-memory state is the definitive record of > state, and that the persistent storage is not being modified outside its > control. > > > > > > In case a consumer connects to a queue on the 2nd broker, the > consequences > > are not really defined and he might either consume a message or crash the > > brokers. > > > > > > > Yeah - the first time one broker comes to a point where the store doesn't > reflect its understanding of the state of the world, then the broker will > probably bail out (e.g. a message it is trying to remove from the store has > already been removed). > > > > Are the above assumptions correct? > > > > > > Just to give a bit of context, I was trying to see if we can ensure High > > Availability using 2 brokers connected on the same Database instance but > it > > seems not possible without repercussions. > > > > > For HA you'd need to have something that prevents more than one broker > being connected to the database at any one time. This is somewhat similar > to the approach of the BDB HA model used for high availability... there can > be only one master and the other instances sit there waiting for the > database to become available to them. > > I have previously considered looking to provide some sort of HA-like > solution based on a RDBMs clustering solution - but you still need some > sort of external agent to control which broker (or rather virtual host) > instance should be considered the master. > > Cheers, > Rob > > > > > > Regards, > > > > Adel > > > > ________________________________ > > From: Rob Godfrey <[email protected]> > > Sent: Wednesday, November 30, 2016 4:25:31 PM > > To: [email protected] > > Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same > > JDBC url > > > > On 30 November 2016 at 15:19, Adel Boutros <[email protected]> wrote: > > > > > Hello, > > > > > > > > > Following the discussion regarding the JDBCMessageStore, I would like > to > > > ask what would happen in the below scenario: > > > > > > > > Bad things :-) > > > > > > > > > > Let's say we have 2 brokers running with the same JDBC message store > > > configured (Same JDBC url for both). One of the broker is hidden and is > > > thus not accessible for consumers or producers while the other is > > visible. > > > > > > > > > Can I see queues created on one broker on the other without any > restart? > > > > > > > > No - the broker relies entirely on in memory state while it is running. > It > > only reads from the database on restart (except for reloading messages > > which have "flowed to disk"... but again this is based on an in-memory > > record of the message existence). > > > > > > > Can messages received on the first be visible on the 2nd without any > > > restart? > > > > > > > > No - as above the broker state is the in-memory state. The broker > assumes > > that it is the only thing updating the persistent state... updating the > > persistent state outside of the broker process will cause a failure due > > these expectations not being met (just as if deleting a file from a derby > > or BDB store would). > > > > > > > Are there any locks issues which will make the above scenario fail? > > > > > > > > No - since the JDBC store can't really make any assumptions about what > > locking mechanisms are available on a JDBC store, it relies on the broker > > to be properly configured. > > > > Hope this helps, > > Rob > > > > > > > > > > Regards, > > > > > > Adel > > > > > >
