[Qpid Java Broker] What happens if 2 brokers have the same JDBC url

[Adel Boutros <Ad...@live.com>]

Hello,


Following the discussion regarding the JDBCMessageStore, I would like to ask what would happen in the below scenario:


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?

Can messages received on the first be visible on the 2nd without any restart?

Are there any locks issues which will make the above scenario fail?


Regards,

Adel

Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

[Rob Godfrey <ro...@gmail.com>]

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 <Ad...@live.com> 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 <ro...@gmail.com>
> Sent: Wednesday, November 30, 2016 4:48:17 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same
> JDBC url
>
> On 30 November 2016 at 15:32, Adel Boutros <Ad...@live.com> 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 <ro...@gmail.com>
> > Sent: Wednesday, November 30, 2016 4:25:31 PM
> > To: users@qpid.apache.org
> > Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same
> > JDBC url
> >
> > On 30 November 2016 at 15:19, Adel Boutros <Ad...@live.com> 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
> > >
> >
>

Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

[Adel Boutros <Ad...@live.com>]

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 <ro...@gmail.com>
Sent: Wednesday, November 30, 2016 4:48:17 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

On 30 November 2016 at 15:32, Adel Boutros <Ad...@live.com> 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 <ro...@gmail.com>
> Sent: Wednesday, November 30, 2016 4:25:31 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same
> JDBC url
>
> On 30 November 2016 at 15:19, Adel Boutros <Ad...@live.com> 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
> >
>

Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

[Rob Godfrey <ro...@gmail.com>]

On 30 November 2016 at 15:32, Adel Boutros <Ad...@live.com> 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 <ro...@gmail.com>
> Sent: Wednesday, November 30, 2016 4:25:31 PM
> To: users@qpid.apache.org
> Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same
> JDBC url
>
> On 30 November 2016 at 15:19, Adel Boutros <Ad...@live.com> 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
> >
>

Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

[Adel Boutros <Ad...@live.com>]

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 <ro...@gmail.com>
Sent: Wednesday, November 30, 2016 4:25:31 PM
To: users@qpid.apache.org
Subject: Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

On 30 November 2016 at 15:19, Adel Boutros <Ad...@live.com> 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
>

Re: [Qpid Java Broker] What happens if 2 brokers have the same JDBC url

[Rob Godfrey <ro...@gmail.com>]

On 30 November 2016 at 15:19, Adel Boutros <Ad...@live.com> 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
>