[jira] [Updated] (ZOOKEEPER-3611) addWatch api supports all watch event type, strengthen the corresponding CLI and add a documentation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling updated ZOOKEEPER-3611: --- Summary: addWatch api supports all watch event type, strengthen the corresponding CLI and add a documentation (was: strengthen CLI:addWatch to support all watch event type and add a documentation) > addWatch api supports all watch event type, strengthen the corresponding CLI > and add a documentation > > > Key: ZOOKEEPER-3611 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3611 > Project: ZooKeeper > Issue Type: Improvement >Reporter: maoling >Assignee: maoling >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-2238) Support limiting the maximum number of connections/clients to a zookeeper server.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973929#comment-16973929 ] Hudson commented on ZOOKEEPER-2238: --- FAILURE: Integrated in Jenkins build ZooKeeper-trunk #774 (See [https://builds.apache.org/job/ZooKeeper-trunk/774/]) ZOOKEEPER-2238: Support limiting the maximum number of (arshad: rev df267929322c5e83bb8d57bbed65978b0159ec8b) * (edit) zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/LocalPeerBean.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/LocalPeerMXBean.java * (add) zookeeper-server/src/test/java/org/apache/zookeeper/server/ZooKeeperServerMaxCnxnsTest.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/NIOServerCnxnFactory.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxnFactory.java * (add) zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxnHelper.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServerMXBean.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServerBean.java > Support limiting the maximum number of connections/clients to a zookeeper > server. > - > > Key: ZOOKEEPER-2238 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2238 > Project: ZooKeeper > Issue Type: Improvement >Reporter: nijel >Assignee: Sujith Simon >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-2238-05.patch, ZOOKEEPER-2238-06.patch, > ZOOKEEPER-2238-07.patch, ZOOKEEPER-2238.2.patch, ZOOKEEPER-2238.3.patch, > ZOOKEEPER-2238.4.patch, ZOOKEEPER-2238.diff > > Time Spent: 4h > Remaining Estimate: 0h > > Currently zookeeper have the feature of limiting the maximum number of > connection/client per IP or Host (maxClientCnxns). > But to safe guard zookeeper server from DoS attack due to many clients from > different IPs, it is better to have a limit of total number of > connections/clients to a a single member of the ZooKeeper ensemble as well. > So the idea is to introduce a new configuration to limit the maximum number > of total connections/clients. > Please share your thoughts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-2238) Support limiting the maximum number of connections/clients to a zookeeper server.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973926#comment-16973926 ] Hudson commented on ZOOKEEPER-2238: --- FAILURE: Integrated in Jenkins build Zookeeper-trunk-single-thread #612 (See [https://builds.apache.org/job/Zookeeper-trunk-single-thread/612/]) ZOOKEEPER-2238: Support limiting the maximum number of (arshad: rev df267929322c5e83bb8d57bbed65978b0159ec8b) * (edit) zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/LocalPeerBean.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxnFactory.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/NIOServerCnxnFactory.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServerMXBean.java * (add) zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxnHelper.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/LocalPeerMXBean.java * (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServerBean.java * (add) zookeeper-server/src/test/java/org/apache/zookeeper/server/ZooKeeperServerMaxCnxnsTest.java > Support limiting the maximum number of connections/clients to a zookeeper > server. > - > > Key: ZOOKEEPER-2238 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2238 > Project: ZooKeeper > Issue Type: Improvement >Reporter: nijel >Assignee: Sujith Simon >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-2238-05.patch, ZOOKEEPER-2238-06.patch, > ZOOKEEPER-2238-07.patch, ZOOKEEPER-2238.2.patch, ZOOKEEPER-2238.3.patch, > ZOOKEEPER-2238.4.patch, ZOOKEEPER-2238.diff > > Time Spent: 4h > Remaining Estimate: 0h > > Currently zookeeper have the feature of limiting the maximum number of > connection/client per IP or Host (maxClientCnxns). > But to safe guard zookeeper server from DoS attack due to many clients from > different IPs, it is better to have a limit of total number of > connections/clients to a a single member of the ZooKeeper ensemble as well. > So the idea is to introduce a new configuration to limit the maximum number > of total connections/clients. > Please share your thoughts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3615) write a TLA+ specification to verify Zab protocol
maoling created ZOOKEEPER-3615: -- Summary: write a TLA+ specification to verify Zab protocol Key: ZOOKEEPER-3615 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3615 Project: ZooKeeper Issue Type: Wish Components: documentation, server Reporter: maoling Assignee: maoling -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3614) Limiting the number of ephemeral nodes per session
Eric Lee created ZOOKEEPER-3614: --- Summary: Limiting the number of ephemeral nodes per session Key: ZOOKEEPER-3614 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3614 Project: ZooKeeper Issue Type: New Feature Reporter: Eric Lee ZooKeeper suffers when a session has too many ephemeral associated with it. In the case where the session expires, the session expiration message passed amongst the quorum is too large from all of the ephemeral paths within it. This Jira introduces a change that allows a limit to be provided as a JVM flag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3340) Introduce CircularBlockingQueue in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973726#comment-16973726
]
Hudson commented on ZOOKEEPER-3340:
---
FAILURE: Integrated in Jenkins build Zookeeper-trunk-single-thread #611 (See
[https://builds.apache.org/job/Zookeeper-trunk-single-thread/611/])
ZOOKEEPER-3340: Introduce CircularBlockingQueue in QuorumCnxManager.java
(andor: rev cd465947949f64d4258184d7b493a7e8747c6262)
* (add)
zookeeper-server/src/main/java/org/apache/zookeeper/util/CircularBlockingQueue.java
* (edit)
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
* (add)
zookeeper-server/src/test/java/org/apache/zookeeper/util/TestCircularBlockingQueue.java
> Introduce CircularBlockingQueue in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
> This proposed JIRA should not be viewed simply as 'ArrayBlockingQueue' v.s.
> 'CircularBlockingQueue'.
> One of the things that this PR does is remove the need for double-locking.
> For example in addToRecvQueue the following condition exists:
> {code}
> public void addToRecvQueue(Message msg) {
> synchronized(recvQLock) {
> if (recvQueue.remainingCapacity() == 0) {
> try {
> {code}
> From here it can be observed that there are two locks obtained: {{recvQLock}}
> and the one internal to {{recvQueue}}. This is required because there are
> multiple interactions that this Manager wants to do on the queue in a
> serialized way. The {{CircularBlockingQueue}} performs all of those actions
> on behalf of the caller, but it does it internal to the queue, under a single
> lock,... the one internal to {{CircularBlockingQueue}}.
> The current code also has some race-conditions that are simply ignored when
> they happen. The race conditions are detailed nicely in the code comments
> here. However, the changes in this PR directly deal with, and eliminate,
> these race conditions altogether since all actions that work against the
> {{CircularBlockingQueue}} all occur within its internal locks. This greatly
> simplifies the code and removes the need for new folks to learn this nuance
> of "why is the code doing this."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3340) Introduce CircularBlockingQueue in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973677#comment-16973677
]
Hudson commented on ZOOKEEPER-3340:
---
FAILURE: Integrated in Jenkins build ZooKeeper-trunk #772 (See
[https://builds.apache.org/job/ZooKeeper-trunk/772/])
ZOOKEEPER-3340: Introduce CircularBlockingQueue in QuorumCnxManager.java
(andor: rev cd465947949f64d4258184d7b493a7e8747c6262)
* (edit)
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java
* (add)
zookeeper-server/src/main/java/org/apache/zookeeper/util/CircularBlockingQueue.java
* (add)
zookeeper-server/src/test/java/org/apache/zookeeper/util/TestCircularBlockingQueue.java
> Introduce CircularBlockingQueue in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 3h 50m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
> This proposed JIRA should not be viewed simply as 'ArrayBlockingQueue' v.s.
> 'CircularBlockingQueue'.
> One of the things that this PR does is remove the need for double-locking.
> For example in addToRecvQueue the following condition exists:
> {code}
> public void addToRecvQueue(Message msg) {
> synchronized(recvQLock) {
> if (recvQueue.remainingCapacity() == 0) {
> try {
> {code}
> From here it can be observed that there are two locks obtained: {{recvQLock}}
> and the one internal to {{recvQueue}}. This is required because there are
> multiple interactions that this Manager wants to do on the queue in a
> serialized way. The {{CircularBlockingQueue}} performs all of those actions
> on behalf of the caller, but it does it internal to the queue, under a single
> lock,... the one internal to {{CircularBlockingQueue}}.
> The current code also has some race-conditions that are simply ignored when
> they happen. The race conditions are detailed nicely in the code comments
> here. However, the changes in this PR directly deal with, and eliminate,
> these race conditions altogether since all actions that work against the
> {{CircularBlockingQueue}} all occur within its internal locks. This greatly
> simplifies the code and removes the need for new folks to learn this nuance
> of "why is the code doing this."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (ZOOKEEPER-3340) Introduce CircularBlockingQueue in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andor Molnar resolved ZOOKEEPER-3340.
-
Resolution: Fixed
Issue resolved by pull request 880
[https://github.com/apache/zookeeper/pull/880]
> Introduce CircularBlockingQueue in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
> This proposed JIRA should not be viewed simply as 'ArrayBlockingQueue' v.s.
> 'CircularBlockingQueue'.
> One of the things that this PR does is remove the need for double-locking.
> For example in addToRecvQueue the following condition exists:
> {code}
> public void addToRecvQueue(Message msg) {
> synchronized(recvQLock) {
> if (recvQueue.remainingCapacity() == 0) {
> try {
> {code}
> From here it can be observed that there are two locks obtained: {{recvQLock}}
> and the one internal to {{recvQueue}}. This is required because there are
> multiple interactions that this Manager wants to do on the queue in a
> serialized way. The {{CircularBlockingQueue}} performs all of those actions
> on behalf of the caller, but it does it internal to the queue, under a single
> lock,... the one internal to {{CircularBlockingQueue}}.
> The current code also has some race-conditions that are simply ignored when
> they happen. The race conditions are detailed nicely in the code comments
> here. However, the changes in this PR directly deal with, and eliminate,
> these race conditions altogether since all actions that work against the
> {{CircularBlockingQueue}} all occur within its internal locks. This greatly
> simplifies the code and removes the need for new folks to learn this nuance
> of "why is the code doing this."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3582) refactor the async api call to lambda style
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated ZOOKEEPER-3582:
--
Labels: pull-request-available (was: )
> refactor the async api call to lambda style
> ---
>
> Key: ZOOKEEPER-3582
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3582
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: maoling
>Priority: Minor
> Labels: pull-request-available
>
> For example:
> {code:java}
> if (recursive) {
> ZKUtil.visitSubTreeDFS(zk, path, watch, new StringCallback() {
> @Override
> public void processResult(int rc, String path, Object ctx, String
> name) {
> out.println(path);
> }
> });
> }
> {code}
> refactor to
> {code:java}
> ZKUtil.visitSubTreeDFS(zk, path, watch, (rc, path1, ctx, name) ->
> out.println(path1));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3056) Fails to load database with missing snapshot file but valid transaction log file
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973273#comment-16973273
]
Vineet Gupta commented on ZOOKEEPER-3056:
-
Hi Sorry but I don't see the workaround is working for me. I have zookeeper
running in Statefulset in Kubernetes. I followed the steps and downloaded the
snapshot.0 file and copied it under my dataDir under
/var/lib/zookeeper/data/version-2 and I restarted the container via `kill 1`
command. and then I upgraded the zookeeper image but still I see the below logs
but container is still in crash loop state. please help.
{code:java}
2019-11-13 11:38:45,320 [myid:3] - INFO [main:QuorumPeer@2183] -
quorum.cnxn.threads.size set to 20
2019-11-13 11:38:45,399 [myid:3] - ERROR [main:QuorumPeer@955] - Unable to load
database on disk
java.io.IOException: No snapshot found, but there are log entries. Something is
broken!
at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:211)
at
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:240)
at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:919)
at
org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:905)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:205)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:123)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:82)
2019-11-13 11:38:45,404 [myid:3] - ERROR [main:QuorumPeerMain@101] - Unexpected
exception, exiting abnormally
java.lang.RuntimeException: Unable to run quorum server
at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:956)
at
org.apache.zookeeper.server.quorum.QuorumPeer.start(QuorumPeer.java:905)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.runFromConfig(QuorumPeerMain.java:205)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:123)
at
org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:82)
Caused by: java.io.IOException: No snapshot found, but there are log entries.
Something is broken!
at
org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:211)
at
org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:240)
at
org.apache.zookeeper.server.quorum.QuorumPeer.loadDataBase(QuorumPeer.java:919)
... 4 more
{code}
> Fails to load database with missing snapshot file but valid transaction log
> file
>
>
> Key: ZOOKEEPER-3056
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3056
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.3, 3.5.4
>Reporter: Michael Han
>Assignee: Michael Han
>Priority: Critical
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.6
>
> Attachments: snapshot.0
>
> Time Spent: 5h 10m
> Remaining Estimate: 0h
>
> [An
> issue|https://lists.apache.org/thread.html/cc17af6ef05d42318f74148f1a704f16934d1253f14721a93b4b@%3Cdev.zookeeper.apache.org%3E]
> was reported when a user failed to upgrade from 3.4.10 to 3.5.4 with missing
> snapshot file.
> The code complains about missing snapshot file is
> [here|https://github.com/apache/zookeeper/blob/release-3.5.4/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java#L206]
> which is introduced as part of ZOOKEEPER-2325.
> With this check, ZK will not load the db without a snapshot file, even the
> transaction log files are present and valid. This could be a problem for
> restoring a ZK instance which does not have a snapshot file but have a sound
> state (e.g. it crashes before being able to take the first snap shot with a
> large snapCount parameter configured).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3595) Fsync parameter for serialize method is ingnored
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973200#comment-16973200 ] Jingguo Yao commented on ZOOKEEPER-3595: I will have a try. > Fsync parameter for serialize method is ingnored > > > Key: ZOOKEEPER-3595 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3595 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Jingguo Yao >Assignee: Jingguo Yao >Priority: Minor > > [ZOOKEEPER-2872: Interrupted snapshot sync causes data > loss|https://github.com/apache/zookeeper/commit/0706b40afad079f19fe9f76c99bbb7ec69780dbd] > introduced fsync parameter for serialize method. But this parameter is > ignored in > [FileSnap.java|https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/persistence/FileSnap.java#L232]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3606) add JMXHOSTNAME to zkServer.sh to enable user to change the exposed hostname of jmx service
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-3606: -- Labels: pull-request-available (was: ) > add JMXHOSTNAME to zkServer.sh to enable user to change the exposed hostname > of jmx service > --- > > Key: ZOOKEEPER-3606 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3606 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Chia-Ping Tsai >Priority: Minor > Labels: pull-request-available > Attachments: ZOOKEEPER-3606.patch > > > the variable "JMXHOSTNAME" introduce a jmx argument > "java.rmi.server.hostname" to zkServer.sh. the argument can change the > address exposed by jmx service, and it is useful to the zk which is deployed > in the container. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3606) add JMXHOSTNAME to zkServer.sh to enable user to change the exposed hostname of jmx service
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973135#comment-16973135 ] Chia-Ping Tsai commented on ZOOKEEPER-3606: --- [~maoling] Thanks for the information :) > add JMXHOSTNAME to zkServer.sh to enable user to change the exposed hostname > of jmx service > --- > > Key: ZOOKEEPER-3606 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3606 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Chia-Ping Tsai >Priority: Minor > Attachments: ZOOKEEPER-3606.patch > > > the variable "JMXHOSTNAME" introduce a jmx argument > "java.rmi.server.hostname" to zkServer.sh. the argument can change the > address exposed by jmx service, and it is useful to the zk which is deployed > in the container. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3606) add JMXHOSTNAME to zkServer.sh to enable user to change the exposed hostname of jmx service
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973114#comment-16973114 ] maoling commented on ZOOKEEPER-3606: [~chia7712] Sir, Zookeeper uses the github workflow. the contributor guideline is [here] (https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute]) > add JMXHOSTNAME to zkServer.sh to enable user to change the exposed hostname > of jmx service > --- > > Key: ZOOKEEPER-3606 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3606 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Chia-Ping Tsai >Priority: Minor > Attachments: ZOOKEEPER-3606.patch > > > the variable "JMXHOSTNAME" introduce a jmx argument > "java.rmi.server.hostname" to zkServer.sh. the argument can change the > address exposed by jmx service, and it is useful to the zk which is deployed > in the container. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3612) CLONE - Update lib prototype.js: 1.4.0_pre4 due to security vulnerability
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973112#comment-16973112 ] maoling commented on ZOOKEEPER-3612: [~Kevin38] Could you plz help us fix this issue? the contributor guideline is [here] ([https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute]]) > CLONE - Update lib prototype.js: 1.4.0_pre4 due to security vulnerability > - > > Key: ZOOKEEPER-3612 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3612 > Project: ZooKeeper > Issue Type: Bug > Components: documentation >Affects Versions: 3.4.14 >Reporter: Kevin Moultry >Priority: Major > Attachments: pkvgames.apk > > > The zookeeper package package in zookeeper-docs\skin the lib prototype.js in > version 1.4.0_pre4. There is a known security vulnerability CVE-2008-7220. > Can you please upgrade to 1.6.0.2 or higher. Thanks. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3613) ZKConfig fails to return proper value on getBoolean() when user accidentally includes spaces at the end of the value
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16973111#comment-16973111
]
maoling commented on ZOOKEEPER-3613:
[~scott.gum...@syncsort.com]
Could you plz help us fix this issue?
the contributor guideline is [here]
(https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute])
> ZKConfig fails to return proper value on getBoolean() when user accidentally
> includes spaces at the end of the value
>
>
> Key: ZOOKEEPER-3613
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3613
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.5
>Reporter: Scott Guminy
>Priority: Minor
>
> I was using ZooKeeper client in WebSphere Liberty and attempting to configure
> SSL/TLS for client connections.
> To do so, I must add the system property {{zookeeper.client.secure=true}}.
> In WebSphere Liberty, java system properties are placed in a file called
> bootstrap.properties - each property on a separate line. I accidentally
> added a space at the end of the line. When {{ZKConfig.getBoolean()}}
> attempted to convert this string to a {{boolean}}, it returned {{false}} due
> to the space at the end.
> {{ZKConfig.getBoolean()}} should trim the string before attempting to convert
> to a boolean.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
