[
https://issues.apache.org/jira/browse/ZOOKEEPER-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854765#comment-15854765
]
Abraham Fine commented on ZOOKEEPER-1689:
-----------------------------------------
[~jlord] Looks like, since ZOOKEEPER-1012, we currently prioritize the server
JVM_FLAGS.
{code}
"$JAVA" "-Dzookeeper.log.dir=${ZOO_LOG_DIR}"
"-Dzookeeper.root.logger=${ZOO_LOG4J_PROP}"
"-Dzookeeper.log.file=${ZOO_LOG_FILE}" \
-cp "$CLASSPATH" $CLIENT_JVMFLAGS $JVMFLAGS \
org.apache.zookeeper.ZooKeeperMain "$@"
{code}
Note: My testing seems to indicate that HotSpot prioritizes the leftmost
params. Let me know if you can find hard documented evidence that we can always
expect this behavior.
While I think completely removing JVMFLAGS from the client may be inconvenient
for some, the current order seems backwards to me.
What do you think [~jlord] [~hanm]?
> Remove JVMFLAGS completely from clients, if CLIENT_JVMFLAGS are also set
> ------------------------------------------------------------------------
>
> Key: ZOOKEEPER-1689
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1689
> Project: ZooKeeper
> Issue Type: Bug
> Components: scripts
> Affects Versions: 3.4.5
> Reporter: Jeff Lord
> Priority: Minor
>
> In zkCli.sh, the CLIENT_JVMFLAGS are being passed along with regular
> JVMFLAGS, so the latter ends up overriding it anyhow if set. Can we please
> remove JVMFLAGS completely from clients, if CLIENT_JVMFLAGS are also set
> (i.e. use just one).
> One example of how this can be detrimental is if you attempt to start a
> zookeeper-client session on the same host that is already running zookeeper
> and use the default config directory. If the zookeeper server has jmx enabled
> than the client will also pick up that port and attempt to bind resulting in
> a failure
> # /usr/bin/zookeeper-client
> Error: Exception thrown by the agent : java.rmi.server.ExportException: Port
> already in use: 9010; nested exception is:
> java.net.BindException: Address already in use
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
