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. 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. 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. 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 >
