[jira] [Comment Edited] (ZOOKEEPER-4038) when logfile zxid equals to target zxid, should not iterate over the next logfile (FileTxnLog:653)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17254805#comment-17254805 ] huangwenbo edited comment on ZOOKEEPER-4038 at 1/7/21, 7:53 AM: [~maoling] Would you please take a look at it? was (Author: nsnhuang): [~maoling] Could you please take a look at it? > when logfile zxid equals to target zxid, should not iterate over the next > logfile (FileTxnLog:653) > -- > > Key: ZOOKEEPER-4038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4038 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: huangwenbo >Priority: Critical > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3851) Upgrade jUnit in ZooKeeper-Contrib
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-3851: -- Labels: pull-request-available (was: ) > Upgrade jUnit in ZooKeeper-Contrib > -- > > Key: ZOOKEEPER-3851 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3851 > Project: ZooKeeper > Issue Type: Sub-task > Components: contrib >Reporter: Tamas Penzes >Assignee: Tamas Penzes >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > Update test code to use jUnit 5 in contrib projects -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4045) CVE-2020-25649 - Upgrade jackson databind to 2.10.5.1
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259910#comment-17259910 ] Norbert Kalmár commented on ZOOKEEPER-4045: --- just run into this while doing 3.5.9 rc1. This will be needed on 3.5 branch as well. > CVE-2020-25649 - Upgrade jackson databind to 2.10.5.1 > - > > Key: ZOOKEEPER-4045 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4045 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.6.0, 3.6.1, 3.6.2 >Reporter: Edwin Hobor >Priority: Major > Labels: pull-request-available, security > Time Spent: 10m > Remaining Estimate: 0h > > Jackson reported a vulnerability under *CVE-2020-25649*. Upgrading to > *2.10.5.1* will resolve the problem. See > [https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.10#micro-patches] > for more details. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4045) CVE-2020-25649 - Upgrade jackson databind to 2.10.5.1
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár updated ZOOKEEPER-4045: -- Affects Version/s: 3.5.8 > CVE-2020-25649 - Upgrade jackson databind to 2.10.5.1 > - > > Key: ZOOKEEPER-4045 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4045 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.6.0, 3.6.1, 3.5.8, 3.6.2 >Reporter: Edwin Hobor >Priority: Major > Labels: pull-request-available, security > Time Spent: 10m > Remaining Estimate: 0h > > Jackson reported a vulnerability under *CVE-2020-25649*. Upgrading to > *2.10.5.1* will resolve the problem. See > [https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.10#micro-patches] > for more details. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3934) upgrade dependency-check to version 6.0.0
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár updated ZOOKEEPER-3934: -- Fix Version/s: (was: 3.5.9) > upgrade dependency-check to version 6.0.0 > - > > Key: ZOOKEEPER-3934 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3934 > Project: ZooKeeper > Issue Type: Improvement > Components: build, security >Affects Versions: 3.7.0, 3.5.8, 3.6.2 >Reporter: Patrick D. Hunt >Assignee: Patrick D. Hunt >Priority: Major > Fix For: 3.7.0, 3.6.3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > 6.0.0 is now available. I verified it with 3.5, 3.6,3.7 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3933) owasp failing with json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár updated ZOOKEEPER-3933: -- Fix Version/s: (was: 3.5.9) > owasp failing with json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712 > --- > > Key: ZOOKEEPER-3933 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3933 > Project: ZooKeeper > Issue Type: Bug > Components: security >Affects Versions: 3.7.0, 3.5.8, 3.6.2 >Reporter: Patrick D. Hunt >Priority: Blocker > Fix For: 3.7.0, 3.6.3 > > > dependency-check is failing with: > json-simple-1.1.1.jar: CVE-2020-10663, CVE-2020-7712 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-1634) A new feature proposal to ZooKeeper: authentication enforcement
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Norbert Kalmár updated ZOOKEEPER-1634: -- Fix Version/s: 3.5.9 > A new feature proposal to ZooKeeper: authentication enforcement > --- > > Key: ZOOKEEPER-1634 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1634 > Project: ZooKeeper > Issue Type: New Feature > Components: security, server >Affects Versions: 3.4.5 >Reporter: Jaewoong Choi >Assignee: Michael Han >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.9 > > Attachments: > zookeeper_3.4.5_patch_for_authentication_enforcement.patch > > Original Estimate: 72h > Time Spent: 6h 10m > Remaining Estimate: 65h 50m > > Up to the version of 3.4.5, ZooKeeperServer doesn't force the authentication > if the client doesn't give any auth-info through ZooKeeper#addAuthInfo method > invocation. Hence, every znode should have at least one ACL assigned > otherwise any unauthenticated client can do anything on it. > The current authentication/authorization mechanism of ZooKeeper described > above has several points at issue: > 1. At security standpoint, a maleficent client can access a znode which > doesn't have any proper authorization access control set. > 2. At runtime performance standpoint, authorization for every znode to every > operation is unnecessarily but always evaluated against the client who > bypassed the authentication phase. > In other words, the current mechanism doesn't address a certain requirement > at below: > "We want to protect a ZK server by enforcing a simple authentication to every > client no matter which znode it is trying to access. Every connection (or > operation) from the client won't be established but rejected if it doesn't > come with a valid authentication information. As we don't have any other > distinction between znodes in term of authorization, we don't want any ACLs > on any znode." > To address the issues mentioned above, we propose a feature called > "authentication enforcement" to the ZK source. The idea is roughly but > clearly described in a form of patch in the attached file > (zookeeper_3.4.5_patch_for_authentication_enforcement.patch): which makes > ZooKeeperServer enforce the authentication with the given 2 configurations: > authenticationEnforced (boolean) and enforcedAuthenticationScheme (string) > against every operation coming through ZooKeeperServer#processPacket method > except for OpCode.auth operation. The repository base of the patch is > "http://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.5/; -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-4045) CVE-2020-25649 - Upgrade jackson databind to 2.10.5.1
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-4045: -- Labels: pull-request-available security (was: security) > CVE-2020-25649 - Upgrade jackson databind to 2.10.5.1 > - > > Key: ZOOKEEPER-4045 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4045 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.6.0, 3.6.1, 3.6.2 >Reporter: Edwin Hobor >Priority: Major > Labels: pull-request-available, security > Time Spent: 10m > Remaining Estimate: 0h > > Jackson reported a vulnerability under *CVE-2020-25649*. Upgrading to > *2.10.5.1* will resolve the problem. See > [https://github.com/FasterXML/jackson/wiki/Jackson-Release-2.10#micro-patches] > for more details. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3701) Split brain on log disk full
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen updated ZOOKEEPER-3701:
---
Fix Version/s: 3.6.0
3.5.7
3.7.0
> Split brain on log disk full
>
>
> Key: ZOOKEEPER-3701
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3701
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.13, 3.5.6
>Reporter: Ivan Kelly
>Assignee: Andor Molnar
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.7, 3.7.0
>
> Time Spent: 6h 20m
> Remaining Estimate: 0h
>
> We ran into a situation where the cluster ended up with split brain when the
> log disk filled up on a node.
> The ZK cluster(3 node) in question was being used as the metadata store for
> Pulsar. There was an outage in the Pulsar cluster, where two the ZK nodes
> filled up there log disks, causing the cluster to lose quorum. Once we
> rectified the full disk situation and restarted the nodes everything seemed
> to work, but we started getting a lot of log messages about
> UpdateMetadataLoop retrying. UpdateMetadataLoop is used to update bookkeeper
> ledger metadata. If it sees a write conflict it rereads the znode, checks
> whether the update needs to happen, applies it and writes. These retries were
> flooding the log on a subset of the brokers. It turned out that it was
> reading a znode with version 0, but when it tried the setData with version
> set to 0 it was failing because the znode had a version of 2 (there were many
> instances of this). After investigating this, we saw that the znode had a
> different stat and value on ZK-1 to that on ZK-0 & ZK-2.
> We resolved the situation by deleting the log and snapshots from ZK-1 and
> restarting, at which point everything went back to normal. Had ZK-1 managed
> to become leader we would have been in a lot of trouble, but thankfully this
> didn't happen.
> For the sequence of events that led to split brain, I'll refer to the
> following code.
> {code}
> public class FileTxnSnapLog {
> ...
> public boolean truncateLog(long zxid) throws IOException {
> // close the existing txnLog and snapLog
> close();
> // truncate it
> FileTxnLog truncLog = new FileTxnLog(dataDir);
> boolean truncated = truncLog.truncate(zxid);
> truncLog.close();
> // re-open the txnLog and snapLog
> // I'd rather just close/reopen this object itself, however that
> // would have a big impact outside ZKDatabase as there are other
> // objects holding a reference to this object.
> txnLog = new FileTxnLog(dataDir);
> snapLog = new FileSnap(snapDir);
> return truncated;
> }
> public void close() throws IOException {
> txnLog.close();
> snapLog.close();
> }
> }
> public class FileSnap implements SnapShot {
> ...
> public synchronized void serialize(DataTree dt, Map
> sessions, File snapShot)
> throws IOException {
> if (!close) {
> // actual snapshot code
> }
> }
> @Override
> public synchronized void close() throws IOException {
> close = true;
> }
> }
> {code}
> The sequence of events that lead to the failure are:
> | 2020-01-04 01:56:56Z | ZK-2 fails to write to its transaction log due to
> disk full. ZK-2 is still participating in leader election. ZK-2 becomes a
> follower of ZK-1. ZK-1 sends TRUNC to ZK-2. truncLog.truncate on ZK-2 throws
> an exception because of the disk being full, and leaves the process in a
> broken state. |
> |2020-01-04 02:35:23Z | ZK-2 removes 9 transaction logs from disk (bringing
> it from 100% to 19%). It doesn't recover because its in a broken state. |
> |2020-01-09 08:57:33Z| ZK-1 fails to write to its transaction log due to disk
> full. Restarts as follower. Goes into loop of dropping from quorum (because
> it can't update transaction log)|
> |2020-01-09 08:59:33Z |ZK-1 receives snapshot from leader (ZK-0) (at
> 1e). ZK-1 persists snapshot, but fails to add subsequent transations
> to log due to lack of space. ZK-1 drops from quorum.|
> |2020-01-09 09:00:12Z |ZK-1 joins quorum as follower. 1e is close
> enough to leader to receive TRUNC(1d001d). TRUNC fails because txnLog
> can't flush on close() in trunateLog. ZK-1 goes into loop, dropping and
> joining quorum.|
> |2020-01-09 09:39:00Z |ZK-1 runs purgeTxnLog. Process doesn't recover due to
> truncation exception having broken FileTxnSnapLog.|
> |2020-01-09 19:28:37Z |ZK-1 is restarted. ZK-1 joins quorum as follower. ZK-1
> receives TRUNC(1d001d). In this case, txnLog.close() can succeed because
> there's nothing to flush. snapLog is
[jira] [Updated] (ZOOKEEPER-4003) Zookeeper server breakdown Frequently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-4003: --- Priority: Critical (was: Blocker) > Zookeeper server breakdown Frequently > - > > Key: ZOOKEEPER-4003 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4003 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 > Environment: zookeeper verison 3.5.1 > >Reporter: xiaotong.wang >Priority: Critical > Attachments: image-2020-11-13-16-51-11-960.png, > image-2020-11-14-18-08-18-126.png, image-2020-11-14-18-10-14-384.png, > jmap.PNG, screenshot-1.png > > > *error log* > WARN [New I/O worker #16:NettyServerCnxn@400] - Closing connection to > /x.x.x.x:43766 > java.io.IOException: ZK down > at > org.apache.zookeeper.server.NettyServerCnxn.receiveMessage(NettyServerCnxn.java:337) > at > org.apache.zookeeper.server.NettyServerCnxnFactory$CnxnChannelHandler.processMessage(NettyServerCnxnFactory.java:243) > at > org.apache.zookeeper.server.NettyServerCnxnFactory$CnxnChannelHandler.messageReceived(NettyServerCnxnFactory.java:165) > at > org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at > org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > at > org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > > and > > > [myid:2] - WARN [New I/O worker > #15:NettyServerCnxnFactory$CnxnChannelHandler@141] - Exception caught [id: > 0x9ba504cb, /x.x.x.x:39780 :> /x.x.x.x:2181] EXCEPTION: > java.nio.channels.ClosedChannelException > java.nio.channels.ClosedChannelException > at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:270) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:461) > at > org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromTaskLoop(AbstractNioWorker.java:151) > at > org.jboss.netty.channel.socket.nio.AbstractNioChannel$WriteTask.run(AbstractNioChannel.java:292) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:391) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:315) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at > org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > at > org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > > netstat -an|grep 2181|grep CLOSE_WAIT|wc -l > *28441* > > sample： > !image-2020-11-13-16-51-11-960.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-4003) Zookeeper server breakdown Frequently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-4003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259621#comment-17259621 ] Damien Diederen commented on ZOOKEEPER-4003: [~xiaotong.wang]: Is this still relevant? In the meantime, downgrading from blocker as this should not block 3.7.0. > Zookeeper server breakdown Frequently > - > > Key: ZOOKEEPER-4003 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4003 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.1 > Environment: zookeeper verison 3.5.1 > >Reporter: xiaotong.wang >Priority: Blocker > Attachments: image-2020-11-13-16-51-11-960.png, > image-2020-11-14-18-08-18-126.png, image-2020-11-14-18-10-14-384.png, > jmap.PNG, screenshot-1.png > > > *error log* > WARN [New I/O worker #16:NettyServerCnxn@400] - Closing connection to > /x.x.x.x:43766 > java.io.IOException: ZK down > at > org.apache.zookeeper.server.NettyServerCnxn.receiveMessage(NettyServerCnxn.java:337) > at > org.apache.zookeeper.server.NettyServerCnxnFactory$CnxnChannelHandler.processMessage(NettyServerCnxnFactory.java:243) > at > org.apache.zookeeper.server.NettyServerCnxnFactory$CnxnChannelHandler.messageReceived(NettyServerCnxnFactory.java:165) > at > org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) > at > org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at > org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > at > org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > > and > > > [myid:2] - WARN [New I/O worker > #15:NettyServerCnxnFactory$CnxnChannelHandler@141] - Exception caught [id: > 0x9ba504cb, /x.x.x.x:39780 :> /x.x.x.x:2181] EXCEPTION: > java.nio.channels.ClosedChannelException > java.nio.channels.ClosedChannelException > at sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:270) > at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:461) > at > org.jboss.netty.channel.socket.nio.SocketSendBufferPool$UnpooledSendBuffer.transferTo(SocketSendBufferPool.java:203) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.write0(AbstractNioWorker.java:201) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromTaskLoop(AbstractNioWorker.java:151) > at > org.jboss.netty.channel.socket.nio.AbstractNioChannel$WriteTask.run(AbstractNioChannel.java:292) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:391) > at > org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:315) > at > org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) > at > org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) > at > org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:748) > > netstat -an|grep 2181|grep CLOSE_WAIT|wc -l > *28441* > > sample： > !image-2020-11-13-16-51-11-960.png! > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3866) Unable to change permission of zookeper node having read access
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3866: --- Priority: Minor (was: Blocker) > Unable to change permission of zookeper node having read access > --- > > Key: ZOOKEEPER-3866 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3866 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mrinal >Priority: Minor > > Unable to change permission of zookeper node having read access > 1.open zookeeper-shell.sh with corresponding IP > getAcl /zookeeper > 'world,'anyone > : r > while changing the same its saying Authentication is not valid > setAcl /zookeeper world:anyone:cdrwa > Authentication is not valid : /zookeeper > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3866) Unable to change permission of zookeper node having read access
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259620#comment-17259620 ] Damien Diederen commented on ZOOKEEPER-3866: [~mrinal1818]: Is this still relevant? Downgrading from blocker as this should not block 3.7.0. > Unable to change permission of zookeper node having read access > --- > > Key: ZOOKEEPER-3866 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3866 > Project: ZooKeeper > Issue Type: Bug >Reporter: Mrinal >Priority: Blocker > > Unable to change permission of zookeper node having read access > 1.open zookeeper-shell.sh with corresponding IP > getAcl /zookeeper > 'world,'anyone > : r > while changing the same its saying Authentication is not valid > setAcl /zookeeper world:anyone:cdrwa > Authentication is not valid : /zookeeper > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3795) Need to script to test zookeeper canary checks
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259619#comment-17259619 ] Damien Diederen commented on ZOOKEEPER-3795: [~siva0698]: Could you be more specific? In any case, this should not block release 3.7.0. > Need to script to test zookeeper canary checks > -- > > Key: ZOOKEEPER-3795 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3795 > Project: ZooKeeper > Issue Type: Wish > Components: scripts >Affects Versions: 3.4.9 >Reporter: sivakumar >Priority: Minor > > HI Team, > Can you please provide the script to check zookeeper_canary check for normal > apache hadoop cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3795) Need to script to test zookeeper canary checks
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3795: --- Priority: Minor (was: Blocker) > Need to script to test zookeeper canary checks > -- > > Key: ZOOKEEPER-3795 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3795 > Project: ZooKeeper > Issue Type: Wish > Components: scripts >Affects Versions: 3.4.9 >Reporter: sivakumar >Priority: Minor > > HI Team, > Can you please provide the script to check zookeeper_canary check for normal > apache hadoop cluster -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-2419) Zookeeper.log filling up faster due to clients without Auth (KeeperErrorCode = NoAuth)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-2419: --- Priority: Major (was: Blocker) > Zookeeper.log filling up faster due to clients without Auth (KeeperErrorCode > = NoAuth) > -- > > Key: ZOOKEEPER-2419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2419 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.6 >Reporter: Karthik Shivanna >Priority: Major > > I am seeing that the /var/log/zookeeper/zookeeper.out file is getting filled > up faster than usual. It has grown upto 5 GB. When I further saw the out > file, lot of them are [INFO] as follows: > 2016-03-22 02:03:42,621 - INFO [ProcessThread(sid:4 > cport:-1)::PrepRequestProcessor@645] - Got user-level KeeperException when > processing sessionid:0x4534413d1f70001 type:create cxid:0x71e0aa99 > zxid:0x5f00e3de69 txntype:-1 reqpath:n/a Error Path:null > Error:KeeperErrorCode = NoAuth > The log4j properties file was modified to change the parameter for logging > from INFO, CONSOLE to INFO, ROLLINGFILE. But I would like to understand where > the above INFO is coming from. > Any help is greatly appreciated. Thanks > Zookeeper version: 3.4.6-249--1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (ZOOKEEPER-2419) Zookeeper.log filling up faster due to clients without Auth (KeeperErrorCode = NoAuth)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259584#comment-17259584 ] Damien Diederen edited comment on ZOOKEEPER-2419 at 1/6/21, 11:16 AM: -- Is this still relevant? In the meantime, downgrading from blocker as this should not block 3.7.0. was (Author: ztzg): Is this still relevant? If so, it should at least be downgraded from blocker. > Zookeeper.log filling up faster due to clients without Auth (KeeperErrorCode > = NoAuth) > -- > > Key: ZOOKEEPER-2419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2419 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.6 >Reporter: Karthik Shivanna >Priority: Blocker > > I am seeing that the /var/log/zookeeper/zookeeper.out file is getting filled > up faster than usual. It has grown upto 5 GB. When I further saw the out > file, lot of them are [INFO] as follows: > 2016-03-22 02:03:42,621 - INFO [ProcessThread(sid:4 > cport:-1)::PrepRequestProcessor@645] - Got user-level KeeperException when > processing sessionid:0x4534413d1f70001 type:create cxid:0x71e0aa99 > zxid:0x5f00e3de69 txntype:-1 reqpath:n/a Error Path:null > Error:KeeperErrorCode = NoAuth > The log4j properties file was modified to change the parameter for logging > from INFO, CONSOLE to INFO, ROLLINGFILE. But I would like to understand where > the above INFO is coming from. > Any help is greatly appreciated. Thanks > Zookeeper version: 3.4.6-249--1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3634) why zookeeper huge snapshot cause waitEpockAck timeout?
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3634: --- Priority: Critical (was: Blocker) > why zookeeper huge snapshot cause waitEpockAck timeout? > --- > > Key: ZOOKEEPER-3634 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3634 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.5 >Reporter: zechao zheng >Priority: Critical > > h4. Question > After a large number of znodes are created, ZooKeeper servers in the > ZooKeeper cluster become faulty and cannot be automatically recovered or > restarted. > Logs of the followe: > 2016-06-23 08:00:18,763 | WARN | > QuorumPeer[myid=26](plain=/10.16.9.138:24002)(secure=disabled) | Exception > when following the leader | > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:93) > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at java.io.DataInputStream.readInt(DataInputStream.java:387) > at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) > at > org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:99) > at org.apache.zookeeper.server.quorum.Learner.readPacket(Learner.java:156) > at > org.apache.zookeeper.server.quorum.Learner.registerWithLeader(Learner.java:276) > at > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:75) > at > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1094)2016-06-23 > 08:00:18,763 | WARN | > QuorumPeer[myid=26](plain=/10.16.9.138:24002)(secure=disabled) | Exception > when following the leader | > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:93) > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at java.io.DataInputStream.readInt(DataInputStream.java:387) > at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) > at > org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:99) > at org.apache.zookeeper.server.quorum.Learner.readPacket(Learner.java:156) > at > org.apache.zookeeper.server.quorum.Learner.registerWithLeader(Learner.java:276) > at > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:75) > at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1094) > Logs of the leader: > 016-06-23 07:30:57,481 | WARN | > QuorumPeer[myid=25](plain=/10.16.9.136:24002)(secure=disabled) | Unexpected > exception | > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1108) > java.lang.InterruptedException: Timeout while waiting for epoch to be acked > by quorum > at > org.apache.zookeeper.server.quorum.Leader.waitForEpochAck(Leader.java:1221) > at org.apache.zookeeper.server.quorum.Leader.lead(Leader.java:487) > at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1105) > 2016-06-23 07:30:57,482 | INFO | > QuorumPeer[myid=25](plain=/10.16.9.136:24002)(secure=disabled) | Shutdown > called | org.apache.zookeeper.server.quorum.Leader.shutdown(Leader.java:623) > java.lang.Exception: shutdown Leader! reason: Forcing shutdown > at org.apache.zookeeper.server.quorum.Leader.shutdown(Leader.java:623) > at > org.apache.zookeeper.server.quorum.QuorumPeer.stopLeader(QuorumPeer.java:1149) > at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1110) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3634) why zookeeper huge snapshot cause waitEpockAck timeout?
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259614#comment-17259614 ] Damien Diederen commented on ZOOKEEPER-3634: [~ghostssd]: Is this still relevant? Can you reproduce with non-EOL versions? In the meantime, downgrading from blocker as this should not block 3.7.0. > why zookeeper huge snapshot cause waitEpockAck timeout? > --- > > Key: ZOOKEEPER-3634 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3634 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.5 >Reporter: zechao zheng >Priority: Blocker > > h4. Question > After a large number of znodes are created, ZooKeeper servers in the > ZooKeeper cluster become faulty and cannot be automatically recovered or > restarted. > Logs of the followe: > 2016-06-23 08:00:18,763 | WARN | > QuorumPeer[myid=26](plain=/10.16.9.138:24002)(secure=disabled) | Exception > when following the leader | > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:93) > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at java.io.DataInputStream.readInt(DataInputStream.java:387) > at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) > at > org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:99) > at org.apache.zookeeper.server.quorum.Learner.readPacket(Learner.java:156) > at > org.apache.zookeeper.server.quorum.Learner.registerWithLeader(Learner.java:276) > at > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:75) > at > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1094)2016-06-23 > 08:00:18,763 | WARN | > QuorumPeer[myid=26](plain=/10.16.9.138:24002)(secure=disabled) | Exception > when following the leader | > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:93) > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:170) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at java.io.DataInputStream.readInt(DataInputStream.java:387) > at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) > at > org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:99) > at org.apache.zookeeper.server.quorum.Learner.readPacket(Learner.java:156) > at > org.apache.zookeeper.server.quorum.Learner.registerWithLeader(Learner.java:276) > at > org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:75) > at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1094) > Logs of the leader: > 016-06-23 07:30:57,481 | WARN | > QuorumPeer[myid=25](plain=/10.16.9.136:24002)(secure=disabled) | Unexpected > exception | > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1108) > java.lang.InterruptedException: Timeout while waiting for epoch to be acked > by quorum > at > org.apache.zookeeper.server.quorum.Leader.waitForEpochAck(Leader.java:1221) > at org.apache.zookeeper.server.quorum.Leader.lead(Leader.java:487) > at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1105) > 2016-06-23 07:30:57,482 | INFO | > QuorumPeer[myid=25](plain=/10.16.9.136:24002)(secure=disabled) | Shutdown > called | org.apache.zookeeper.server.quorum.Leader.shutdown(Leader.java:623) > java.lang.Exception: shutdown Leader! reason: Forcing shutdown > at org.apache.zookeeper.server.quorum.Leader.shutdown(Leader.java:623) > at > org.apache.zookeeper.server.quorum.QuorumPeer.stopLeader(QuorumPeer.java:1149) > at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1110) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3303) ZooKeeper Perl client zkperl doesn't compile on newer RHEL systems ie. Fedora
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259612#comment-17259612
]
Damien Diederen commented on ZOOKEEPER-3303:
[~harisekhon]: Could you check if these build issues still happen on {{master}}?
In the meantime, downgrading from blocker as this should not block 3.7.0.
> ZooKeeper Perl client zkperl doesn't compile on newer RHEL systems ie. Fedora
> -
>
> Key: ZOOKEEPER-3303
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3303
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client, contrib
>Affects Versions: 3.4.8, 3.4.12, 3.4.13
> Environment: Fedora 29 in docker
>Reporter: Hari Sekhon
>Priority: Blocker
>
> ZooKeeper Perl client zkperl fails to compile on Fedora 29 (compiles ok on
> CentOS 7 though). I cannot build the project to get the zkperl dependencies
> to run on Fedora as it is. This happens on various versions of ZooKeeper 3.4.x
> {code:java}
> # perl Makefile.PL --zookeeper-include=/usr/local/include
> --zookeeper-lib=/usr/local/lib
> Generating a Unix-style Makefile
> Writing Makefile for Net::ZooKeeper
> Writing MYMETA.yml and MYMETA.json
> # make
> Skip blib/lib/Net/ZooKeeper.pm (unchanged)
> Running Mkbootstrap for ZooKeeper ()
> chmod 644 "ZooKeeper.bs"
> "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- ZooKeeper.bs
> blib/arch/auto/Net/ZooKeeper/ZooKeeper.bs 644
> gcc -c -I/usr/local/include -I. -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fwrapv
> -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -g -DVERSION=\"0.36\" -DXS_VERSION=\"0.36\" -fPIC
> "-I/usr/lib64/perl5/CORE" ZooKeeper.c
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_acl_constant’:
> ZooKeeper.c:784:7: warning: unused variable ‘RETVAL’ [-Wunused-variable]
> AV * RETVAL;
>^~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_CLONE’:
> ZooKeeper.c:1089:9: warning: unused variable ‘package’ [-Wunused-variable]
> char * package = (char *)SvPV_nolen(ST(0))
> ^~~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_CLONE_SKIP’:
> ZooKeeper.c:1109:9: warning: unused variable ‘package’ [-Wunused-variable]
> char * package = (char *)SvPV_nolen(ST(0))
> ^~~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_TIEHASH’:
> ZooKeeper.c:1129:9: warning: unused variable ‘package’ [-Wunused-variable]
> char * package = (char *)SvPV_nolen(ST(0))
> ^~~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_UNTIE’:
> ZooKeeper.c:1151:5: warning: unused variable ‘ref_count’ [-Wunused-variable]
> IV ref_count = (IV)SvIV(ST(1))
> ^
> ZooKeeper.c:1150:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_SCALAR’:
> ZooKeeper.c:1281:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_DELETE’:
> ZooKeeper.c:1528:7: warning: unused variable ‘attr_key’ [-Wunused-variable]
> SV * attr_key = ST(1)
>^~~~
> ZooKeeper.c:1527:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_CLEAR’:
> ZooKeeper.c:1561:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.xs: In function ‘XS_Net__ZooKeeper_add_auth’:
> ZooKeeper.xs:1206:30: warning: format ‘%u’ expects argument of type ‘unsigned
> int’, but argument 3 has type ‘STRLEN’ {aka ‘long unsigned int’} [-Wformat=]
> Perl_croak(aTHX_ "invalid certificate length: %u", cert_len);
> ^~~~
> ZooKeeper.xs: In function ‘XS_Net__ZooKeeper_create’:
> ZooKeeper.xs:1286:30: warning: format ‘%u’ expects argument of type ‘unsigned
> int’, but argument 3 has type ‘STRLEN’ {aka ‘long unsigned int’} [-Wformat=]
> Perl_croak(aTHX_ "invalid data length: %u", buf_len);
> ^ ~~~
> ZooKeeper.xs:1321:21: error: format not a string literal and no format
> arguments [-Werror=format-security]
>
[jira] [Updated] (ZOOKEEPER-3303) ZooKeeper Perl client zkperl doesn't compile on newer RHEL systems ie. Fedora
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen updated ZOOKEEPER-3303:
---
Priority: Minor (was: Blocker)
> ZooKeeper Perl client zkperl doesn't compile on newer RHEL systems ie. Fedora
> -
>
> Key: ZOOKEEPER-3303
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3303
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client, contrib
>Affects Versions: 3.4.8, 3.4.12, 3.4.13
> Environment: Fedora 29 in docker
>Reporter: Hari Sekhon
>Priority: Minor
>
> ZooKeeper Perl client zkperl fails to compile on Fedora 29 (compiles ok on
> CentOS 7 though). I cannot build the project to get the zkperl dependencies
> to run on Fedora as it is. This happens on various versions of ZooKeeper 3.4.x
> {code:java}
> # perl Makefile.PL --zookeeper-include=/usr/local/include
> --zookeeper-lib=/usr/local/lib
> Generating a Unix-style Makefile
> Writing Makefile for Net::ZooKeeper
> Writing MYMETA.yml and MYMETA.json
> # make
> Skip blib/lib/Net/ZooKeeper.pm (unchanged)
> Running Mkbootstrap for ZooKeeper ()
> chmod 644 "ZooKeeper.bs"
> "/usr/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- ZooKeeper.bs
> blib/arch/auto/Net/ZooKeeper/ZooKeeper.bs 644
> gcc -c -I/usr/local/include -I. -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe
> -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fwrapv
> -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
> -D_FILE_OFFSET_BITS=64 -g -DVERSION=\"0.36\" -DXS_VERSION=\"0.36\" -fPIC
> "-I/usr/lib64/perl5/CORE" ZooKeeper.c
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_acl_constant’:
> ZooKeeper.c:784:7: warning: unused variable ‘RETVAL’ [-Wunused-variable]
> AV * RETVAL;
>^~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_CLONE’:
> ZooKeeper.c:1089:9: warning: unused variable ‘package’ [-Wunused-variable]
> char * package = (char *)SvPV_nolen(ST(0))
> ^~~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_CLONE_SKIP’:
> ZooKeeper.c:1109:9: warning: unused variable ‘package’ [-Wunused-variable]
> char * package = (char *)SvPV_nolen(ST(0))
> ^~~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_TIEHASH’:
> ZooKeeper.c:1129:9: warning: unused variable ‘package’ [-Wunused-variable]
> char * package = (char *)SvPV_nolen(ST(0))
> ^~~
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_UNTIE’:
> ZooKeeper.c:1151:5: warning: unused variable ‘ref_count’ [-Wunused-variable]
> IV ref_count = (IV)SvIV(ST(1))
> ^
> ZooKeeper.c:1150:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_SCALAR’:
> ZooKeeper.c:1281:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_DELETE’:
> ZooKeeper.c:1528:7: warning: unused variable ‘attr_key’ [-Wunused-variable]
> SV * attr_key = ST(1)
>^~~~
> ZooKeeper.c:1527:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.c: In function ‘XS_Net__ZooKeeper_CLEAR’:
> ZooKeeper.c:1561:17: warning: variable ‘attr_hash’ set but not used
> [-Wunused-but-set-variable]
> Net__ZooKeeper attr_hash;
> ^
> ZooKeeper.xs: In function ‘XS_Net__ZooKeeper_add_auth’:
> ZooKeeper.xs:1206:30: warning: format ‘%u’ expects argument of type ‘unsigned
> int’, but argument 3 has type ‘STRLEN’ {aka ‘long unsigned int’} [-Wformat=]
> Perl_croak(aTHX_ "invalid certificate length: %u", cert_len);
> ^~~~
> ZooKeeper.xs: In function ‘XS_Net__ZooKeeper_create’:
> ZooKeeper.xs:1286:30: warning: format ‘%u’ expects argument of type ‘unsigned
> int’, but argument 3 has type ‘STRLEN’ {aka ‘long unsigned int’} [-Wformat=]
> Perl_croak(aTHX_ "invalid data length: %u", buf_len);
> ^ ~~~
> ZooKeeper.xs:1321:21: error: format not a string literal and no format
> arguments [-Werror=format-security]
> Perl_croak(aTHX_ err);
> ^~
> ZooKeeper.xs: In function ‘XS_Net__ZooKeeper_set’:
> ZooKeeper.xs:1760:30: warning: format ‘%u’ expects argument of
[jira] [Updated] (ZOOKEEPER-3293) ZooKeeper fails to compile on newer RHEL systems ie. Fedora
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen updated ZOOKEEPER-3293:
---
Priority: Minor (was: Blocker)
> ZooKeeper fails to compile on newer RHEL systems ie. Fedora
> ---
>
> Key: ZOOKEEPER-3293
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3293
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.8, 3.4.12, 3.4.13
> Environment: Fedora 29 in docker
>Reporter: Hari Sekhon
>Priority: Minor
>
> ZooKeeper fails to compile on Fedora 29 (compiles ok on CentOS 7 though). I
> cannot build the project to get the zkperl dependencies to run on Fedora as
> it is. This happens on various versions of ZooKeeper 3.4.x
> {code:java}
> cd zookeeper-3.4.8/src/c
> ./configure
> make
> make all-am
> make[1]: Entering directory '/github/nagios-plugins/zookeeper-3.4.13/src/c'
> /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I./include -I./tests -I./generated -Wall -Werror -g -O2 -D_GNU_SOURCE -MT
> zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f
> 'src/zookeeper.c' || echo './'`src/zookeeper.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests
> -I./generated -Wall -Werror -g -O2 -D_GNU_SOURCE -MT zookeeper.lo -MD -MP -MF
> .deps/zookeeper.Tpo -c src/zookeeper.c -fPIC -DPIC -o .libs/zookeeper.o
> src/zookeeper.c: In function ‘format_endpoint_info’:
> src/zookeeper.c:3506:21: error: ‘%d’ directive writing between 1 and 5 bytes
> into a region of size between 0 and 127 [-Werror=format-overflow=]
> sprintf(buf,"%s:%d",addrstr,ntohs(port));
> ^~
> src/zookeeper.c:3506:17: note: directive argument in the range [0, 65535]
> sprintf(buf,"%s:%d",addrstr,ntohs(port));
> ^~~
> src/zookeeper.c:3506:5: note: ‘sprintf’ output between 3 and 134 bytes into a
> destination of size 128
> sprintf(buf,"%s:%d",addrstr,ntohs(port));
> ^~~~
> cc1: all warnings being treated as errors
> make[1]: *** [Makefile:955: zookeeper.lo] Error 1
> make[1]: Leaving directory '/github/nagios-plugins/zookeeper-3.4.13/src/c'
> make: *** [Makefile:631: all] Error 2
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3293) ZooKeeper fails to compile on newer RHEL systems ie. Fedora
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259611#comment-17259611
]
Damien Diederen commented on ZOOKEEPER-3293:
[~harisekhon]: Would you agree to close this, as suggested by [~ctubbsii]? Or
do you still see problems with non-EOL versions of ZooKeeper on non-EOL
versions of Fedora?
In the meantime, downgrading from blocker as this should not block 3.7.0.
> ZooKeeper fails to compile on newer RHEL systems ie. Fedora
> ---
>
> Key: ZOOKEEPER-3293
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3293
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.8, 3.4.12, 3.4.13
> Environment: Fedora 29 in docker
>Reporter: Hari Sekhon
>Priority: Blocker
>
> ZooKeeper fails to compile on Fedora 29 (compiles ok on CentOS 7 though). I
> cannot build the project to get the zkperl dependencies to run on Fedora as
> it is. This happens on various versions of ZooKeeper 3.4.x
> {code:java}
> cd zookeeper-3.4.8/src/c
> ./configure
> make
> make all-am
> make[1]: Entering directory '/github/nagios-plugins/zookeeper-3.4.13/src/c'
> /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I.
> -I./include -I./tests -I./generated -Wall -Werror -g -O2 -D_GNU_SOURCE -MT
> zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f
> 'src/zookeeper.c' || echo './'`src/zookeeper.c
> libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests
> -I./generated -Wall -Werror -g -O2 -D_GNU_SOURCE -MT zookeeper.lo -MD -MP -MF
> .deps/zookeeper.Tpo -c src/zookeeper.c -fPIC -DPIC -o .libs/zookeeper.o
> src/zookeeper.c: In function ‘format_endpoint_info’:
> src/zookeeper.c:3506:21: error: ‘%d’ directive writing between 1 and 5 bytes
> into a region of size between 0 and 127 [-Werror=format-overflow=]
> sprintf(buf,"%s:%d",addrstr,ntohs(port));
> ^~
> src/zookeeper.c:3506:17: note: directive argument in the range [0, 65535]
> sprintf(buf,"%s:%d",addrstr,ntohs(port));
> ^~~
> src/zookeeper.c:3506:5: note: ‘sprintf’ output between 3 and 134 bytes into a
> destination of size 128
> sprintf(buf,"%s:%d",addrstr,ntohs(port));
> ^~~~
> cc1: all warnings being treated as errors
> make[1]: *** [Makefile:955: zookeeper.lo] Error 1
> make[1]: Leaving directory '/github/nagios-plugins/zookeeper-3.4.13/src/c'
> make: *** [Makefile:631: all] Error 2
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3292) ZooKeeper C Client for Windows: should include winports.h
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259608#comment-17259608 ] Damien Diederen commented on ZOOKEEPER-3292: Hi [~Vujic], Thank you for the report. CMake and Windows builds leave quite a lot to be desired right now. A patch would be welcome! I am downgrading this from blocker, however, as I don't think it should block 3.7.0. > ZooKeeper C Client for Windows: should include winports.h > - > > Key: ZOOKEEPER-3292 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3292 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.13 > Environment: Windows 10 > CMake > ZooKeeper 3.4.13 >Reporter: David Vujic >Priority: Blocker > > When building the C client on Windows with CMake: > cmake -DWANT_SYNCAPI=OFF -DCMAKE_GENERATOR_PLATFORM=x64 > > With this input, the header file winports.h will not be added in these files: > *zk_log.c* > *zk_adaptor.h* > Also, I think winports.h should be added to *zookeeper.c* > > Without winports.h compiling will fail on Windows. Errors are about strtok_r > and localtime_r - the Windows mappings in winports.h are missing. > I am guessing that other important includes are missing too (like Windows > Sockets). > > One solution could be to extract the winports.h include out from the THREADED > preprocessor, to a separate one: > #ifdef WIN32 > #include "winport.h" > #endif -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3292) ZooKeeper C Client for Windows: should include winports.h
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3292: --- Priority: Major (was: Blocker) > ZooKeeper C Client for Windows: should include winports.h > - > > Key: ZOOKEEPER-3292 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3292 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.13 > Environment: Windows 10 > CMake > ZooKeeper 3.4.13 >Reporter: David Vujic >Priority: Major > > When building the C client on Windows with CMake: > cmake -DWANT_SYNCAPI=OFF -DCMAKE_GENERATOR_PLATFORM=x64 > > With this input, the header file winports.h will not be added in these files: > *zk_log.c* > *zk_adaptor.h* > Also, I think winports.h should be added to *zookeeper.c* > > Without winports.h compiling will fail on Windows. Errors are about strtok_r > and localtime_r - the Windows mappings in winports.h are missing. > I am guessing that other important includes are missing too (like Windows > Sockets). > > One solution could be to extract the winports.h include out from the THREADED > preprocessor, to a separate one: > #ifdef WIN32 > #include "winport.h" > #endif -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3213) Transaction has delete log bug actually it is not delete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259607#comment-17259607 ] Damien Diederen commented on ZOOKEEPER-3213: Is this still relevant? I am downgrading it from blocker for the time being. > Transaction has delete log bug actually it is not delete > > > Key: ZOOKEEPER-3213 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3213 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection, server >Affects Versions: 3.4.10 > Environment: Linux > Java 1.8 > ZK 3.4.10 > server1: 10.35.104.123 > server2: 10.35.104.124 > server3: 10.35.104.125 >Reporter: miaojianlong >Priority: Blocker > Attachments: transactionlog.zip > > > # first i found my spark(2.2.0) turn to standby (HA mode with zk) and i can > not restart the service to restore the problem。 > # Then I found that there are three nodes in the /spark/leader_election/ > directory, which are 48, 93, and 94. These are temporary sequential nodes, > and 48 should have been timed out. And I looked at the transaction log and > did have a log of delete 48. But the actual data still exists. > The above phenomenon appears on the two nodes 10.35.104.123 and > 10.35.104.125, and only 93 and 94 on 10.35.104.124. > Unable to export logs due to phenomenon in the company intranet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3213) Transaction has delete log bug actually it is not delete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3213: --- Priority: Major (was: Blocker) > Transaction has delete log bug actually it is not delete > > > Key: ZOOKEEPER-3213 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3213 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection, server >Affects Versions: 3.4.10 > Environment: Linux > Java 1.8 > ZK 3.4.10 > server1: 10.35.104.123 > server2: 10.35.104.124 > server3: 10.35.104.125 >Reporter: miaojianlong >Priority: Major > Attachments: transactionlog.zip > > > # first i found my spark(2.2.0) turn to standby (HA mode with zk) and i can > not restart the service to restore the problem。 > # Then I found that there are three nodes in the /spark/leader_election/ > directory, which are 48, 93, and 94. These are temporary sequential nodes, > and 48 should have been timed out. And I looked at the transaction log and > did have a log of delete 48. But the actual data still exists. > The above phenomenon appears on the two nodes 10.35.104.123 and > 10.35.104.125, and only 93 and 94 on 10.35.104.124. > Unable to export logs due to phenomenon in the company intranet -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3211) zookeeper standalone mode，found a high level bug in kernel of centos7.0 ，zookeeper Server's tcp/ip socket connections(default 60 ) are CLOSE_WAIT ，this lead to zk ca
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-3211: --- Priority: Major (was: Blocker) > zookeeper standalone mode，found a high level bug in kernel of centos7.0 > ，zookeeper Server's tcp/ip socket connections(default 60 ) are CLOSE_WAIT > ，this lead to zk can't work for client any more > -- > > Key: ZOOKEEPER-3211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3211 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.5 > Environment: 1.zoo.cfg > server.1=127.0.0.1:2902:2903 > 2.kernel > kernel：Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Tue Feb 12 > 19:44:50 EST 2019 x86_64 x86_64 x86_64 GNU/Linux > JDK： > java version "1.7.0_181" > OpenJDK Runtime Environment (rhel-2.6.14.5.el7-x86_64 u181-b00) > OpenJDK 64-Bit Server VM (build 24.181-b00, mixed mode) > zk: 3.4.5 >Reporter: yeshuangshuang >Priority: Major > Fix For: 3.4.5 > > Attachments: 1.log, 2018-12-09_124131.png, 2018-12-09_124210.png, > 2018-12-09_132854.png, 2018-12-09_133017.png, 2018-12-09_133049.png, > 2018-12-09_133111.png, 2018-12-09_133131.png, 2018-12-09_133150.png, > 2018-12-09_133210.png, 2018-12-09_133229.png, 2018-12-09_133248.png, > 2018-12-09_133320.png, zookeeper.log > > Original Estimate: 168h > Remaining Estimate: 168h > > 1.config--zoo.cfg > server.1=127.0.0.1:2902:2903 > 2.kernel version > version：Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Tue Feb 12 > 19:44:50 EST 2019 x86_64 x86_64 x86_64 GNU/Linux > JDK： > java version "1.7.0_181" > OpenJDK Runtime Environment (rhel-2.6.14.5.el7-x86_64 u181-b00) > OpenJDK 64-Bit Server VM (build 24.181-b00, mixed mode) > zk: 3.4.5 > 3.bug details： > Occasionally，But the recurrence probability is extremely high. At first, the > read-write timeout takes about 6s, and after a few minutes, all connections > (including long ones) will be CLOSE_WAIT state. > 4.:Circumvention scheme: it is found that all connections become close_wait > to restart the zookeeper server side actively -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3211) zookeeper standalone mode，found a high level bug in kernel of centos7.0 ，zookeeper Server's tcp/ip socket connections(default 60 ) are CLOSE_WAIT ，this lead to zk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259605#comment-17259605 ] Damien Diederen commented on ZOOKEEPER-3211: Is this still relevant? I am downgrading it from blocker, at least for the time being. > zookeeper standalone mode，found a high level bug in kernel of centos7.0 > ，zookeeper Server's tcp/ip socket connections(default 60 ) are CLOSE_WAIT > ，this lead to zk can't work for client any more > -- > > Key: ZOOKEEPER-3211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3211 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.5 > Environment: 1.zoo.cfg > server.1=127.0.0.1:2902:2903 > 2.kernel > kernel：Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Tue Feb 12 > 19:44:50 EST 2019 x86_64 x86_64 x86_64 GNU/Linux > JDK： > java version "1.7.0_181" > OpenJDK Runtime Environment (rhel-2.6.14.5.el7-x86_64 u181-b00) > OpenJDK 64-Bit Server VM (build 24.181-b00, mixed mode) > zk: 3.4.5 >Reporter: yeshuangshuang >Priority: Blocker > Fix For: 3.4.5 > > Attachments: 1.log, 2018-12-09_124131.png, 2018-12-09_124210.png, > 2018-12-09_132854.png, 2018-12-09_133017.png, 2018-12-09_133049.png, > 2018-12-09_133111.png, 2018-12-09_133131.png, 2018-12-09_133150.png, > 2018-12-09_133210.png, 2018-12-09_133229.png, 2018-12-09_133248.png, > 2018-12-09_133320.png, zookeeper.log > > Original Estimate: 168h > Remaining Estimate: 168h > > 1.config--zoo.cfg > server.1=127.0.0.1:2902:2903 > 2.kernel version > version：Linux localhost.localdomain 3.10.0-123.el7.x86_64 #1 SMP Tue Feb 12 > 19:44:50 EST 2019 x86_64 x86_64 x86_64 GNU/Linux > JDK： > java version "1.7.0_181" > OpenJDK Runtime Environment (rhel-2.6.14.5.el7-x86_64 u181-b00) > OpenJDK 64-Bit Server VM (build 24.181-b00, mixed mode) > zk: 3.4.5 > 3.bug details： > Occasionally，But the recurrence probability is extremely high. At first, the > read-write timeout takes about 6s, and after a few minutes, all connections > (including long ones) will be CLOSE_WAIT state. > 4.:Circumvention scheme: it is found that all connections become close_wait > to restart the zookeeper server side actively -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-3192) zoo_multi/zoo_amulti crash
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen updated ZOOKEEPER-3192:
---
Priority: Major (was: Blocker)
> zoo_multi/zoo_amulti crash
> --
>
> Key: ZOOKEEPER-3192
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3192
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
>Affects Versions: 3.4.13
> Environment: VS2013 Building （/MD）
>Reporter: Jian Wang
>Priority: Major
>
> In the zoo_amulti function (zookeeper.c) , it seems an initialization problem.
> {code:java}
> struct RequestHeader h = { STRUCT_INITIALIZER(xid, get_xid()),
> STRUCT_INITIALIZER(type, ZOO_MULTI_OP) };
> struct MultiHeader mh = { STRUCT_INITIALIZER(type, -1),
> STRUCT_INITIALIZER(done, 1), STRUCT_INITIALIZER(err, -1) };
> struct oarchive *oa = create_buffer_oarchive();
> completion_head_t clist = { 0 };
> {code}
> variable "clist" 's member cond and lock are not initialized correctly. They
> should be initialized by pthread_cond_init and pthread_mutex_init. Otherwise
> zoo_amulti would crash when queue_completion was called witch calls
> pthread_cond_boardcast using clist->cond
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-3192) zoo_multi/zoo_amulti crash
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259604#comment-17259604
]
Damien Diederen commented on ZOOKEEPER-3192:
Hi [~wangjiandtc],
Thank you for the report. This is a Windows-only issue, so I am downgrading
this from blocker for now. A patch would be welcome, in case you feel like
contributing one!
> zoo_multi/zoo_amulti crash
> --
>
> Key: ZOOKEEPER-3192
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3192
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
>Affects Versions: 3.4.13
> Environment: VS2013 Building （/MD）
>Reporter: Jian Wang
>Priority: Blocker
>
> In the zoo_amulti function (zookeeper.c) , it seems an initialization problem.
> {code:java}
> struct RequestHeader h = { STRUCT_INITIALIZER(xid, get_xid()),
> STRUCT_INITIALIZER(type, ZOO_MULTI_OP) };
> struct MultiHeader mh = { STRUCT_INITIALIZER(type, -1),
> STRUCT_INITIALIZER(done, 1), STRUCT_INITIALIZER(err, -1) };
> struct oarchive *oa = create_buffer_oarchive();
> completion_head_t clist = { 0 };
> {code}
> variable "clist" 's member cond and lock are not initialized correctly. They
> should be initialized by pthread_cond_init and pthread_mutex_init. Otherwise
> zoo_amulti would crash when queue_completion was called witch calls
> pthread_cond_boardcast using clist->cond
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-2973) "Unreasonable length" exception
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Damien Diederen updated ZOOKEEPER-2973: --- Priority: Minor (was: Blocker) > "Unreasonable length" exception > > > Key: ZOOKEEPER-2973 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2973 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: wanggang_123 >Priority: Minor > > I am running a three node ZooKeeper cluster. At 2018-01-28 17:56:30,leader > node has error log: > 2018-01-28 17:56:30 > [UTC:20180128T175630+0800]|ERROR||LearnerHandler-/118.123.180.23:44836hread|Coordination > > Unexpected exception causing shutdown while sock still open > (LearnerHandler.java:633) > java.io.IOException: Unreasonable length = 1885430131 > at org.apache.jute.BinaryInputArchive.readBuffer(BinaryInputArchive.java:95) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:85) > at org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:103) > at > org.apache.zookeeper.server.quorum.LearnerHandler.run(LearnerHandler.java:546) > 2018-01-28 17:56:30 [UTC:20180128T175630+0800]|WARN > ||LearnerHandler-/118.123.180.23:44836hread|Coordination > *** GOODBYE > /118.123.180.23:44836 (LearnerHandler.java:646) > 2018-01-28 17:56:30 [UTC:20180128T175630+0800]|INFO ||ProcessThread(sid:2 > cport:-1):hread|Coordination > Got user-level KeeperException when processing > sessionid:0x16138593ad43cf9 type:delete cxid:0x5 zxid:0xc104b59e9 txntype:-1 > reqpath:n/a Error > Path:/VSP/Leader/syncScore-0/_c_9101a3d6-f431-4792-b71d-a493e938895d-latch-093037 > Error:KeeperErrorCode = NoNode for > /VSP/Leader/syncScore-0/_c_9101a3d6-f431-4792-b71d-a493e938895d-latch-093037 > (PrepRequestProcessor.java:645) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-2973) "Unreasonable length" exception
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259587#comment-17259587 ] Damien Diederen commented on ZOOKEEPER-2973: Same question as [~eolivelli] above. Downgrading from blocker. > "Unreasonable length" exception > > > Key: ZOOKEEPER-2973 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2973 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.6 >Reporter: wanggang_123 >Priority: Blocker > > I am running a three node ZooKeeper cluster. At 2018-01-28 17:56:30,leader > node has error log: > 2018-01-28 17:56:30 > [UTC:20180128T175630+0800]|ERROR||LearnerHandler-/118.123.180.23:44836hread|Coordination > > Unexpected exception causing shutdown while sock still open > (LearnerHandler.java:633) > java.io.IOException: Unreasonable length = 1885430131 > at org.apache.jute.BinaryInputArchive.readBuffer(BinaryInputArchive.java:95) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:85) > at org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:103) > at > org.apache.zookeeper.server.quorum.LearnerHandler.run(LearnerHandler.java:546) > 2018-01-28 17:56:30 [UTC:20180128T175630+0800]|WARN > ||LearnerHandler-/118.123.180.23:44836hread|Coordination > *** GOODBYE > /118.123.180.23:44836 (LearnerHandler.java:646) > 2018-01-28 17:56:30 [UTC:20180128T175630+0800]|INFO ||ProcessThread(sid:2 > cport:-1):hread|Coordination > Got user-level KeeperException when processing > sessionid:0x16138593ad43cf9 type:delete cxid:0x5 zxid:0xc104b59e9 txntype:-1 > reqpath:n/a Error > Path:/VSP/Leader/syncScore-0/_c_9101a3d6-f431-4792-b71d-a493e938895d-latch-093037 > Error:KeeperErrorCode = NoNode for > /VSP/Leader/syncScore-0/_c_9101a3d6-f431-4792-b71d-a493e938895d-latch-093037 > (PrepRequestProcessor.java:645) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ZOOKEEPER-2550) FollowerResyncConcurrencyTest failed in ZooKeeper 3.3.3
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damien Diederen updated ZOOKEEPER-2550:
---
Priority: Minor (was: Blocker)
> FollowerResyncConcurrencyTest failed in ZooKeeper 3.3.3
> ---
>
> Key: ZOOKEEPER-2550
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2550
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection, quorum, server, tests
>Affects Versions: 3.3.3
> Environment: Windows 10,
> Java 1.8.0,
> IDEA 2016.1.4,
> JUnit 4.8.1
>Reporter: KangYin
>Priority: Minor
> Labels: test
>
> I'm studying on the Test of ZooKeeper 3.3.3 but got a test failure when I
> run _testResyncBySnapThenDiffAfterFollowerCrashes_ in
> _FollowerResyncConcurrencyTest.java_.
> {quote}
> 2016-09-05 13:57:35,072 - INFO [main:QuorumBase@307] - FINISHED
> testResyncBySnapThenDiffAfterFollowerCrashes
> java.util.concurrent.TimeoutException: Did not connect
> at
> org.apache.zookeeper.test.ClientBase$CountdownWatcher.waitForConnected(ClientBase.java:119)
> at
> org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:95)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {quote}
> Which happened in _FollowerResyncConcurrencyTest.java_ at line 92.
> {quote}
> index = (index == 1) ? 2 : 1;
> qu.shutdown(index);
> final ZooKeeper zk3 = new DisconnectableZooKeeper("127.0.0.1:" +
> qu.getPeer(3).peer.getClientPort(), 1000,watcher3);
> {color:red}watcher3.waitForConnected(CONNECTION_TIMEOUT);{color}
> zk3.create("/mybar", null, ZooDefs.Ids.OPEN_ACL_UNSAFE,
> CreateMode.EPHEMERAL_SEQUENTIAL);
> {quote}
> I checked the Log Message, and I guess it is probably because of the
> following ERROR (marked as blue):
> {quote}
> 2016-09-05 13:56:54,928 - INFO
> [main-SendThread():ClientCnxn$SendThread@1041] - Opening socket connection to
> server /127.0.0.1:11237
> 2016-09-05 13:56:54,930 - INFO
> [main-SendThread(127.0.0.1:11237):ClientCnxn$SendThread@949] - Socket
> connection established to 127.0.0.1/127.0.0.1:11237, initiating session
> 2016-09-05 13:56:54,930 - INFO
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:NIOServerCnxn$Factory@251] -
> Accepted socket connection from /127.0.0.1:33566
> 2016-09-05 13:56:54,957 - INFO
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:NIOServerCnxn@777] - Client
> attempting to establish new session at /127.0.0.1:33566
> {color:blue}
> 2016-09-05 13:56:55,000 - INFO [SyncThread:3:FileTxnLog@197] - Creating new
> log file: log.10001
> 2016-09-05 13:56:55,000 - WARN
> [QuorumPeer:/0:0:0:0:0:0:0:0:11235:Follower@116] - Got zxid 0x10001
> expected 0x1
> 2016-09-05 13:56:55,000 - INFO [SyncThread:2:FileTxnLog@197] - Creating new
> log file: log.10001
> 2016-09-05 13:56:55,078 - ERROR [CommitProcessor:3:CommitProcessor@146] -
> Unexpected exception causing CommitProcessor to exit
> java.lang.AssertionError
> at
>
[jira] [Commented] (ZOOKEEPER-2550) FollowerResyncConcurrencyTest failed in ZooKeeper 3.3.3
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259586#comment-17259586
]
Damien Diederen commented on ZOOKEEPER-2550:
Is this still relevant? In any case, downgrading from blocker.
> FollowerResyncConcurrencyTest failed in ZooKeeper 3.3.3
> ---
>
> Key: ZOOKEEPER-2550
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2550
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection, quorum, server, tests
>Affects Versions: 3.3.3
> Environment: Windows 10,
> Java 1.8.0,
> IDEA 2016.1.4,
> JUnit 4.8.1
>Reporter: KangYin
>Priority: Blocker
> Labels: test
>
> I'm studying on the Test of ZooKeeper 3.3.3 but got a test failure when I
> run _testResyncBySnapThenDiffAfterFollowerCrashes_ in
> _FollowerResyncConcurrencyTest.java_.
> {quote}
> 2016-09-05 13:57:35,072 - INFO [main:QuorumBase@307] - FINISHED
> testResyncBySnapThenDiffAfterFollowerCrashes
> java.util.concurrent.TimeoutException: Did not connect
> at
> org.apache.zookeeper.test.ClientBase$CountdownWatcher.waitForConnected(ClientBase.java:119)
> at
> org.apache.zookeeper.test.FollowerResyncConcurrencyTest.testResyncBySnapThenDiffAfterFollowerCrashes(FollowerResyncConcurrencyTest.java:95)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at junit.framework.TestCase.runTest(TestCase.java:168)
> at junit.framework.TestCase.runBare(TestCase.java:134)
> at junit.framework.TestResult$1.protect(TestResult.java:110)
> at junit.framework.TestResult.runProtected(TestResult.java:128)
> at junit.framework.TestResult.run(TestResult.java:113)
> at junit.framework.TestCase.run(TestCase.java:124)
> at junit.framework.TestSuite.runTest(TestSuite.java:232)
> at junit.framework.TestSuite.run(TestSuite.java:227)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:119)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:42)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:234)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:74)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {quote}
> Which happened in _FollowerResyncConcurrencyTest.java_ at line 92.
> {quote}
> index = (index == 1) ? 2 : 1;
> qu.shutdown(index);
> final ZooKeeper zk3 = new DisconnectableZooKeeper("127.0.0.1:" +
> qu.getPeer(3).peer.getClientPort(), 1000,watcher3);
> {color:red}watcher3.waitForConnected(CONNECTION_TIMEOUT);{color}
> zk3.create("/mybar", null, ZooDefs.Ids.OPEN_ACL_UNSAFE,
> CreateMode.EPHEMERAL_SEQUENTIAL);
> {quote}
> I checked the Log Message, and I guess it is probably because of the
> following ERROR (marked as blue):
> {quote}
> 2016-09-05 13:56:54,928 - INFO
> [main-SendThread():ClientCnxn$SendThread@1041] - Opening socket connection to
> server /127.0.0.1:11237
> 2016-09-05 13:56:54,930 - INFO
> [main-SendThread(127.0.0.1:11237):ClientCnxn$SendThread@949] - Socket
> connection established to 127.0.0.1/127.0.0.1:11237, initiating session
> 2016-09-05 13:56:54,930 - INFO
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:NIOServerCnxn$Factory@251] -
> Accepted socket connection from /127.0.0.1:33566
> 2016-09-05 13:56:54,957 - INFO
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11237:NIOServerCnxn@777] - Client
> attempting to establish new session at /127.0.0.1:33566
> {color:blue}
> 2016-09-05 13:56:55,000 - INFO [SyncThread:3:FileTxnLog@197] - Creating new
> log file: log.10001
> 2016-09-05 13:56:55,000 - WARN
> [QuorumPeer:/0:0:0:0:0:0:0:0:11235:Follower@116] - Got zxid 0x10001
> expected 0x1
> 2016-09-05 13:56:55,000 - INFO [SyncThread:2:FileTxnLog@197] - Creating new
> log file: log.10001
> 2016-09-05 13:56:55,078 - ERROR [CommitProcessor:3:CommitProcessor@146] -
> Unexpected exception causing
[jira] [Commented] (ZOOKEEPER-2419) Zookeeper.log filling up faster due to clients without Auth (KeeperErrorCode = NoAuth)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259584#comment-17259584 ] Damien Diederen commented on ZOOKEEPER-2419: Is this still relevant? If so, it should at least be downgraded from blocker. > Zookeeper.log filling up faster due to clients without Auth (KeeperErrorCode > = NoAuth) > -- > > Key: ZOOKEEPER-2419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2419 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.6 >Reporter: Karthik Shivanna >Priority: Blocker > > I am seeing that the /var/log/zookeeper/zookeeper.out file is getting filled > up faster than usual. It has grown upto 5 GB. When I further saw the out > file, lot of them are [INFO] as follows: > 2016-03-22 02:03:42,621 - INFO [ProcessThread(sid:4 > cport:-1)::PrepRequestProcessor@645] - Got user-level KeeperException when > processing sessionid:0x4534413d1f70001 type:create cxid:0x71e0aa99 > zxid:0x5f00e3de69 txntype:-1 reqpath:n/a Error Path:null > Error:KeeperErrorCode = NoAuth > The log4j properties file was modified to change the parameter for logging > from INFO, CONSOLE to INFO, ROLLINGFILE. But I would like to understand where > the above INFO is coming from. > Any help is greatly appreciated. Thanks > Zookeeper version: 3.4.6-249--1 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-2332) Zookeeper failed to start for empty txn log
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17259580#comment-17259580
]
Damien Diederen commented on ZOOKEEPER-2332:
This is marked as a duplicate of ZOOKEEPER-2376, which has been resolved.
Should I resolve?
> Zookeeper failed to start for empty txn log
> ---
>
> Key: ZOOKEEPER-2332
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2332
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Shaohui Liu
>Assignee: Shaohui Liu
>Priority: Critical
> Fix For: 3.7.0
>
> Attachments: ZOOKEEPER-2332-v001.diff
>
>
> We found that the zookeeper server with version 3.4.6 failed to start for
> there is a empty txn log in log dir.
> I think we should skip the empty log file during restoring the datatree.
> Any suggestion?
> {code}
> 2015-11-27 19:16:16,887 [myid:] - ERROR [main:ZooKeeperServerMain@63] -
> Unexpected exception, exiting abnormally
> java.io.EOFException
> at java.io.DataInputStream.readInt(DataInputStream.java:392)
> at org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63)
> at
> org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64)
> at
> org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:576)
> at
> org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:595)
> at
> org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:561)
> at
> org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:643)
> at
> org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:158)
> at org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223)
> at
> org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:272)
> at
> org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:399)
> at
> org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:122)
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:113)
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86)
> at
> org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:116)
> at
> org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
