You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Raffi <ra...@gmail.com> on 2016/05/08 14:54:50 UTC
How to update activemq.xml config in distributed topology?
Looking for advice on how to update activemq.xml in a distributed topology
that uses M/S pairs and NoB.
Some ideas we're considering...
Option A: *Custom Startup Bean*
On startup (before activemq.xml is read), a custom class queries GIT/SVN for
latest version of broker config files, comparing version to those deployed
locally, pulls files from GIT overwriting local ones. After which broker
reads config and starts up normally.
Broker reloading would be triggered over JMX.
Option B: *Jenkins Pipeline*
A workflow that pushes config files to brokers sequentially, using JMX to
trigger broker reload to pick up config changes.
Option A is cleaner and simpler; Jenkins pipeline could get messy
identifying and/or recovering from startup failures.
--
View this message in context: http://activemq.2283324.n4.nabble.com/How-to-update-activemq-xml-config-in-distributed-topology-tp4711732.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: How to update activemq.xml config in distributed topology?
Posted by Christopher Wood <ch...@pobox.com>.
On Sun, May 08, 2016 at 07:54:50AM -0700, Raffi wrote:
> Looking for advice on how to update activemq.xml in a distributed topology
> that uses M/S pairs and NoB.
>
> Some ideas we're considering...
>
> Option A: *Custom Startup Bean*
> On startup (before activemq.xml is read), a custom class queries GIT/SVN for
> latest version of broker config files, comparing version to those deployed
> locally, pulls files from GIT overwriting local ones. After which broker
> reads config and starts up normally.
> Broker reloading would be triggered over JMX.
>
> Option B: *Jenkins Pipeline*
> A workflow that pushes config files to brokers sequentially, using JMX to
> trigger broker reload to pick up config changes.
Call it jenkins or whatever you like, this sounds like the precise case for configuration management (broker or jvm reload on file change).
> Option A is cleaner and simpler; Jenkins pipeline could get messy
> identifying and/or recovering from startup failures.
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nabble.com/How-to-update-activemq-xml-config-in-distributed-topology-tp4711732.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: How to update activemq.xml config in distributed topology?
Posted by Raffi <ra...@gmail.com>.
Hi Tim,
Should have mentioned earlier, we're on RedHat AMQ, and the custom bean for
loading new config files would be OSGI. The problem is configuring a
dependency on the broker bundle ensuring our custom stuff loads first. I
know how to do it with OSGI features, but only if I control packaging the
bundle to manipulate features.xml; the broker bundle is prepackaged.
The problem with the script approach, assuming you meant the broker startup
script, is that it only works on startup, not on reload when triggered from
JMX.
--
View this message in context: http://activemq.2283324.n4.nabble.com/How-to-update-activemq-xml-config-in-distributed-topology-tp4711732p4711734.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: How to update activemq.xml config in distributed topology?
Posted by Tim Bain <tb...@alumni.duke.edu>.
I'd do A, but implement it in a shell script that wraps the standard
ActiveMQ one, so you don't have to figure out how to get your class loaded
before activemq.xml.
Or isn't this the type of thing Puppet is meant for?
Tim
On May 8, 2016 9:29 AM, "Raffi" <ra...@gmail.com> wrote:
> Looking for advice on how to update activemq.xml in a distributed topology
> that uses M/S pairs and NoB.
>
> Some ideas we're considering...
>
> Option A: *Custom Startup Bean*
> On startup (before activemq.xml is read), a custom class queries GIT/SVN
> for
> latest version of broker config files, comparing version to those deployed
> locally, pulls files from GIT overwriting local ones. After which broker
> reads config and starts up normally.
> Broker reloading would be triggered over JMX.
>
> Option B: *Jenkins Pipeline*
> A workflow that pushes config files to brokers sequentially, using JMX to
> trigger broker reload to pick up config changes.
>
> Option A is cleaner and simpler; Jenkins pipeline could get messy
> identifying and/or recovering from startup failures.
>
>
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/How-to-update-activemq-xml-config-in-distributed-topology-tp4711732.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>