[jira] [Resolved] (ARTEMIS-1429) Configuration Reload on slave broker.xml causes slave to start/enable acceptors which disables backups

["Justin Bertram (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/ARTEMIS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Justin Bertram resolved ARTEMIS-1429.
-------------------------------------
    Resolution: Cannot Reproduce

I'm resolving this until we have a way to reproduce it.

> Configuration Reload on slave broker.xml causes slave to start/enable acceptors which disables backups
> ------------------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1429
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1429
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 2.1.0, 2.2.0, 2.3.0
>         Environment: Mac OSX, Java 1.8
>            Reporter: Dan Langford
>
> NODE CONFIG
> I am running in a simple Master / Slave cluster. Each node is configured such that the cluster is defined with a static connector to the other. Start up looks fine and the Slave stops accepting connections and backup is announced. 
> QUEUE CONFIG
> Lets set up a scenario here. lets say that in the broker xml an address names FOO (anycast to a queue called FOO) is defined. Security settings also allow role MAVERICK to send and consume. Lets also say that after the system started via management operations we created another address named BAR (anycast to queue called BAR). We also at runtime added security settings to allow role GOOSE to send/ and consume both FOO and BAR
> *broker.xml*
> address FOO
> role MAVERICK send to FOO
> *runtime management*
> address BAR
> role GOOSE send to BAR
> role GOOSE send to FOO
> FAILOVER & FAILBACK WORKING
> so Master is "serving", if you will, FOO and BAR. GOOSE can send to both FOO and BAR. If we turn off Master then Slave starts listening on the acceptors and continues to serve FOO and BAR. The security settings also replicated so GOOSE can still send to FOO and BAR. replication seems to be working fine. Start Master back up and Master takes over and the Slave turns off its acceptors. This is just as expected and it works great behind our F5/VIP which sees active pool members based off of who is accepting requests to 5672. 
> PROBLEMS WITH CONFIGURATION RELOAD & BACKUPS
> If I make any change at all to the slave broker.xml file the "configuration reload" feature take effect and starts/enables the acceptors on the Slave. The Slave is only "serving" any queues that are defined in the broker.xml so in this case its only serving FOO. since our VIP now sees that another pool member is active it starts routing traffic to the slave. the slave can only take FOO traffic because we have auto-create of queues turned off. so BAR traffic that happens to go to the slave is denied. also Replication now seem problematic as the Slave is no longer backing up the Master and the messages now being sent to FOO on the Slave are not being backed up by anybody. 
> In fact anything configured via management is no longer considered. GOOSE can no longer send to FOO. MAVERICK still can. 
> QUESTIONS
> Is this by design? is there a way to completely disable configuration reload all together? Can configuration reload be configured to also take into account address and security configuration that has happened via the management api? is there a way to configure the configuration reload to consider the fact that it is supposed to be part of a cluster? 
> i am completely open to this being a problem with my set up. i wanted to quickly throw this out there if i need to come back and supply broker XML files i can in a bit. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)