Dan Langford created ARTEMIS-1429:
-------------------------------------
Summary: 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.3.0, 2.2.0, 2.1.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)
