activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy Taylor (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACTIVEMQ6-82) start script limitations
Date Fri, 20 Feb 2015 09:13:11 GMT

    [ https://issues.apache.org/jira/browse/ACTIVEMQ6-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14328715#comment-14328715
] 

Andy Taylor commented on ACTIVEMQ6-82:
--------------------------------------

we'll get this fixed

> start script limitations
> ------------------------
>
>                 Key: ACTIVEMQ6-82
>                 URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-82
>             Project: Apache ActiveMQ 6
>          Issue Type: Bug
>         Environment: UNIX
>            Reporter: Daniel Pocock
>
> 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
script
> 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
run.sh 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/standalone.sh 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
(v6.3.4#6332)

Mime
View raw message