[
https://issues.apache.org/jira/browse/ARTEMIS-1429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Langford updated ARTEMIS-1429:
----------------------------------
Description:
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.
was:
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.
> 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)
