[
https://issues.apache.org/jira/browse/ARTEMIS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16175126#comment-16175126
]
Timothy Bish commented on ARTEMIS-1429:
---------------------------------------
This is really a question that should be posted to the users mailing list for
discussion, only if it is deemed to be a bug should a JIRA be created.
> 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)
