[ 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)