mattrpav commented on PR #1921: URL: https://github.com/apache/activemq/pull/1921#issuecomment-4244583114
@jbonofre this _adds_ a race condition for the configuration update and then the plugin remains active, even if the broker goes back to being a failover/slave broker which leads to inconsistent behavior. The Broker interface used for lifecycle has a gap, where there is no hook/method called when a broker goes _back_ to being a slave/failover node. Described: 1. BrokerA starts up as primary 2. BrokerB starts up as failover 3. User applies config change 4. BrokerA applies configuration (new policy entries and authz entries) 5. BrokerB does not apply change (plugin not active) 6. BrokerA goes offline 7. BrokerB becomes active with the old configuration 8. RuntimConfig polling period completes.. new configuration applied <-- config race condition 9. BrokerB goes offline 10. BrokerA comes online 11. BrokerB RuntimeConfig continues to run <-- inconsistent behavior Questions: Q-1: What problem exists with having a failover/slave broker process config changes? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] For further information, visit: https://activemq.apache.org/contact
