activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Schöchlin (JIRA) <>
Subject [jira] [Commented] (ACTIVEMQ6-82) start script limitations
Date Mon, 23 Feb 2015 17:03:12 GMT


Marc Schöchlin commented on ACTIVEMQ6-82:

Uhh, i missed that ActiveMQ 6 is managed in a separate repository!  
The current script looks a bit outdated. It looks like the version before i implemented the
current script in 2010.
You should have a look for the current script an adapt it for ACTIVEMQ-6.

> start script limitations
> ------------------------
>                 Key: ACTIVEMQ6-82
>                 URL:
>             Project: Apache ActiveMQ 6
>          Issue Type: Bug
>         Environment: UNIX
>            Reporter: Daniel Pocock
>            Assignee: Martyn Taylor
> This issue concerns the start script:
> ./distribution/activemq/src/main/resources/bin/activemq
> There are various issues with JAVA_ARGS at the bottom:
> a) memory parameters are hard-coded in the script and can't be overridden without modifying
the script
> b) data.dir is hardcoded in the script and can't be overridden without modifying the
> Problem (a) was also present in HornetQ while problem (b) was not there.
> With HornetQ 2.3, it was possible to override the data.dir and also add other properties
or JMXetric to the JVM command line by setting the CLUSTER_PROPS variable in a local wrapper
script.  However, setting heap parameters in CLUSTER_PROPS was ineffective because the HornetQ would then set them to other values later on the command line.
> JBoss / Wildfly seems to do a better job of splitting the logic and configuration, they
have a script called bin/ that contains the logic and a separate file, bin/standalone.conf
that can be customized with environment variables.  I think this would be a good model for
ActiveMQ 6 to follow.  Is there already any discussion about refactoring the script?
> This is important for various reasons:
> - people deploying the broker in production environments don't like to modify the scripts
supplied by a vendor, they usually prefer to have a configuration file of their own
> - when upgrading, it is an extra hassle to merge changes into the scripts if they have
been modified locally
> - some people may want to run multiple instances using the same installation directory,
same scripts and just using different data and log directories

This message was sent by Atlassian JIRA

View raw message