activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Langford <danlangf...@gmail.com>
Subject Re: [Artemis 2.1-2.3] Configuration Reload on slave broker.xml causes slave to start/enable acceptors which disables backups
Date Thu, 21 Sep 2017 20:51:16 GMT
a quick note and then i will work on providing a more reproducible use set
of artifacts.

> How did you test that?

Three things i notice. 1)  in the JMX console (viewed via Hawtio/jolokia
api in 2.1, and the skinned version of such in the new 2.3 console [very
nice BTW]) the slave will typically NOT show the addresses if the slave is
only set up to be a backup of the master. it will also not show the
acceptors. 2) "netstat -tunlp" on my box on the slave will show that the
slave is not listening for connections on the ports. When i change the file
and save it i see 3) the slave broker starts logging that it is starting
acceptors and it logs the addresses/queues that are coming online and it
mentions something about SSL in regards to the amqps port. i go back and
check 1) the JMX console and sure enough it now is showing addresses and
acceptors. but only the addresses mentioned in the broker.xml none of the
ones added since then. and then over to 2) the command line "netstat
-tunlp" and the slave is now listening on 5671. a nother side effect that i
see that 4) authentication may not work if the role was added
programatically.

a restart of the Slave resolves all of this and it comes online as simply
just a backup to the Master

>  If reloading broker.xml causes queues added via the management API to
disappear I think that's likely a bug.

that is what i observed but i would clarify that is only on that Slave
node. the Master node is still working just fine with all the queues added
from the management api. and when the slave restarts it goes back to
working as expected and failover/failback with all those additional queues
work. so its not a permanent delete in the cluster its just not accessible
on that slave node after the configuration reload.

i have not modified the delete policy.

i will whip up the simplest set of broker.xml files to show this as soon as
i can here at work




On Thu, Sep 21, 2017 at 1:46 PM Michael André Pearce <
michael.andre.pearce@me.com> wrote:

> The only scenario I can think here on the loss of address/queues , noting
> that somehow your slave is thinking it can active as master (aka acceptors
> start up) is that auto-delete-queues/auto-delete-address is kicking in
> (which default is true I believe) as it deletes queue on no subscription
> and then address will delete on no queues. Which would occur if the slave
> is activating somehow as you’d have no subscriptions.
>
> Seems that getting to bottom of why the slave is activating is prob the
> main priority here.
>
> Sent from my iPhone
>
> > On 21 Sep 2017, at 20:36, Michael André Pearce <
> michael.andre.pearce@me.com> wrote:
> >
> > I’ve just tested manually (in a HA setup) that if you set delete policy
> to OFF which by default it is set to OFF, then queues and address do not
> get undeployed on reload. Eg queues and addresses if created in GUI or CLI
> remain.
> >
> > Only if you change/override that to FORCE would it remove an address or
> queue not defined in broker.xml. I assume here you have not set deletion
> policy to FORCE, and just on default OFF
> >
> > It would be good/great help if you are able to make any form or
> reproducer integration test if you still see this issue.
> >
> >
> > Cheers
> > Mike
> >
> >
> >
> > Sent from my iPhone
> >
> >> On 21 Sep 2017, at 20:16, Justin Bertram <jbertram@redhat.com> wrote:
> >>
> >> Many of the changes made via the management API are volatile.  However,
> >> adding queues should be persistent.  If reloading broker.xml causes
> queues
> >> added via the management API to disappear I think that's likely a bug.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message