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.pea...@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.pea...@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 <jbert...@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. >
