[jira] [Resolved] (ZOOKEEPER-2727) WARN and stacktrace for normally closed socket
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes resolved ZOOKEEPER-2727.
---
Resolution: Won't Fix
> WARN and stacktrace for normally closed socket
> --
>
> Key: ZOOKEEPER-2727
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2727
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.9
>Reporter: Andrey
>Assignee: Mark Fenes
>Priority: Major
>
> Steps to reproduce:
> * setup zookeeper
> * setup TCP load balancer. This balancer should check zookeeper clientPort
> liveness(healthcheck) by opening and closing TCP connection to clientPort.
> See
> https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/
> or
> https://www.digitalocean.com/community/tutorials/how-to-create-your-first-digitalocean-load-balancer#step-2-—-creating-the-load-balancer
> for details.
> * in logs:
> {code}
> 2017-03-17 15:41:19,843 [myid:1] - WARN
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@357] - caught end of
> stream exception
> EndOfStreamException: Unable to read additional data from client sessionid
> 0x0, likely client has closed socket
> at
> org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:228)
> at
> org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:203)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> Issue is here:
> https://github.com/apache/zookeeper/blob/5fe68506f217246c7ebd96803f9c78e13ec2f11a/src/java/main/org/apache/zookeeper/server/NIOServerCnxn.java#L322
> -1 is a normal socket termination.
> Expected:
> * reduce log level to INFO
> * do not log stacktrace.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (ZOOKEEPER-1363) Categorise unit tests by 'test-commit', 'full-test' etc
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes resolved ZOOKEEPER-1363. --- Resolution: Won't Fix > Categorise unit tests by 'test-commit', 'full-test' etc > --- > > Key: ZOOKEEPER-1363 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1363 > Project: ZooKeeper > Issue Type: Improvement > Components: build, tests >Reporter: Henry Robinson >Assignee: Mark Fenes >Priority: Major > Labels: newbie > > As discussed on the list, it would be good to split the Java test suite into > categories so that it's easy to run a small set of unit tests against a > patch, and to leave Jenkins to run the full suite of stress tests etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-1990) suspicious instantiation of java Random instances
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16406301#comment-16406301
]
Mark Fenes commented on ZOOKEEPER-1990:
---
[~shralex] According to Random's source, the parameterless instantiation of
Random (new Random()) does the following:
{code:java}
public Random() {
this(seedUniquifier() ^ System.nanoTime());
}{code}
The above looks to me at least as random as
{code:java}
sourceOfRandomness = new Random(System.currentTimeMillis() ^ this.hashCode());
{code}
or probably new Random() is even more random, as seedUniquifier() seems to be
different each time, but this.hashCode() returns the same value if the same
StaticHostProvider instance is used.
I understand those cases, when in tests, we would like to have the same
repeatable results (e.g. when new Random(1) is used), but what is the purpose
of setting a less random seed (e.g. sessionId ^ superSecret) instead of using
new Random(), which appears to be more random?
> suspicious instantiation of java Random instances
> -
>
> Key: ZOOKEEPER-1990
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1990
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Critical
> Fix For: 3.5.4, 3.6.0
>
>
> It's not clear to me why we are doing this, but it looks very suspicious. Why
> aren't we just calling "new Random()" in these cases? (even for the tests I
> don't really see it - typically that would just be for repeatability)
> {noformat}
> ag "new Random[ \t]*\(" .
> src/java/main/org/apache/zookeeper/ClientCnxn.java
> 817:private Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/client/StaticHostProvider.java
> 75: sourceOfRandomness = new Random(System.currentTimeMillis() ^
> this.hashCode());
> 98:sourceOfRandomness = new Random(randomnessSeed);
> src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java
> 420:rand = new Random(java.lang.Thread.currentThread().getId()
> src/java/main/org/apache/zookeeper/server/SyncRequestProcessor.java
> 64:private final Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java
> 537:Random r = new Random(id ^ superSecret);
> 554:Random r = new Random(sessionId ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/WatchLeakTest.java
> 271:Random r = new Random(SESSION_ID ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
> 151:Random rand = new Random(Thread.currentThread().getId());
> 258:Random rand = new Random(Thread.currentThread().getId());
> 288:Random rand = new Random(Thread.currentThread().getId());
> src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java
> 40:private Random r = new Random(1);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2983) Print the classpath when running compile and test ant targets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes updated ZOOKEEPER-2983: -- Description: Printing the classpath helps to verify that we have only the intended classes, jars on the classpath, e.g. clover.jar is included only when running coverage tests. > Print the classpath when running compile and test ant targets > - > > Key: ZOOKEEPER-2983 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2983 > Project: ZooKeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.5.3, 3.4.11 >Reporter: Mark Fenes >Assignee: Mark Fenes >Priority: Major > > Printing the classpath helps to verify that we have only the intended > classes, jars on the classpath, e.g. clover.jar is included only when running > coverage tests. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2983) Print the classpath when running compile and test ant targets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes updated ZOOKEEPER-2983: -- Priority: Major (was: Minor) > Print the classpath when running compile and test ant targets > - > > Key: ZOOKEEPER-2983 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2983 > Project: ZooKeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.5.3, 3.4.11 >Reporter: Mark Fenes >Assignee: Mark Fenes >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-2983) Print the classpath when running compile and test ant targets
Mark Fenes created ZOOKEEPER-2983: - Summary: Print the classpath when running compile and test ant targets Key: ZOOKEEPER-2983 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2983 Project: ZooKeeper Issue Type: Improvement Components: build Affects Versions: 3.4.11, 3.5.3 Reporter: Mark Fenes Assignee: Mark Fenes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-1990) suspicious instantiation of java Random instances
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes reassigned ZOOKEEPER-1990:
-
Assignee: Mark Fenes
> suspicious instantiation of java Random instances
> -
>
> Key: ZOOKEEPER-1990
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1990
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.0
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Critical
> Fix For: 3.5.4, 3.6.0
>
>
> It's not clear to me why we are doing this, but it looks very suspicious. Why
> aren't we just calling "new Random()" in these cases? (even for the tests I
> don't really see it - typically that would just be for repeatability)
> {noformat}
> ag "new Random[ \t]*\(" .
> src/java/main/org/apache/zookeeper/ClientCnxn.java
> 817:private Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/client/StaticHostProvider.java
> 75: sourceOfRandomness = new Random(System.currentTimeMillis() ^
> this.hashCode());
> 98:sourceOfRandomness = new Random(randomnessSeed);
> src/java/main/org/apache/zookeeper/server/quorum/AuthFastLeaderElection.java
> 420:rand = new Random(java.lang.Thread.currentThread().getId()
> src/java/main/org/apache/zookeeper/server/SyncRequestProcessor.java
> 64:private final Random r = new Random(System.nanoTime());
> src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java
> 537:Random r = new Random(id ^ superSecret);
> 554:Random r = new Random(sessionId ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/WatchLeakTest.java
> 271:Random r = new Random(SESSION_ID ^ superSecret);
> src/java/test/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
> 151:Random rand = new Random(Thread.currentThread().getId());
> 258:Random rand = new Random(Thread.currentThread().getId());
> 288:Random rand = new Random(Thread.currentThread().getId());
> src/java/test/org/apache/zookeeper/test/StaticHostProviderTest.java
> 40:private Random r = new Random(1);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2970) Flaky Test: testNullQuorumAuthServerWithValidQuorumAuthPacket
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes updated ZOOKEEPER-2970: -- Summary: Flaky Test: testNullQuorumAuthServerWithValidQuorumAuthPacket (was: Flaky test: testNullQuorumAuthServerWithValidQuorumAuthPacket ) > Flaky Test: testNullQuorumAuthServerWithValidQuorumAuthPacket > -- > > Key: ZOOKEEPER-2970 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2970 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.4.5 >Reporter: Mark Fenes >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-2970) Flaky test: testNullQuorumAuthServerWithValidQuorumAuthPacket
Mark Fenes created ZOOKEEPER-2970: - Summary: Flaky test: testNullQuorumAuthServerWithValidQuorumAuthPacket Key: ZOOKEEPER-2970 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2970 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.5 Reporter: Mark Fenes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-2967) Add check to validate dataDir and dataLogDir parameters at startup
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes reassigned ZOOKEEPER-2967: - Assignee: Mark Fenes (was: Andor Molnar) > Add check to validate dataDir and dataLogDir parameters at startup > -- > > Key: ZOOKEEPER-2967 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2967 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.4.11 >Reporter: Andor Molnar >Assignee: Mark Fenes >Priority: Major > Labels: startup, validation > Fix For: 3.5.4, 3.6.0, 3.4.12 > > > According to -ZOOKEEPER-2960- we should at a startup check to validate that > dataDir and dataLogDir parameters are set correctly. > Perhaps we should introduce a check of some kind? If datalogdir is different > that datadir and snapshots exist in datalogdir we throw an exception and quit. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-2960) The dataDir and dataLogDir are used opposingly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes reassigned ZOOKEEPER-2960:
-
Assignee: Mark Fenes (was: Andor Molnar)
> The dataDir and dataLogDir are used opposingly
> --
>
> Key: ZOOKEEPER-2960
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2960
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.11
> Environment: Not relevant.
>Reporter: Dan Milon
>Assignee: Mark Fenes
>Priority: Critical
> Fix For: 3.4.12
>
>
> _emphasized text_After upgrading from zookeeper 3.4.5, to 3.4.11, without
> editing {{zoo.cfg}}, the new version of the server tries to use the
> {{dataDir}} as the {{dataLogDir}}, and the {{dataLogDir}} as the {{dataDir}}.
> Or at least some parts of the server.
> Configuration file has:
> {noformat}
> $ grep -i data /etc/zookeeper/zoo.cfg
> dataLogDir=/var/lib/zookeeper/datalog
> dataDir=/var/lib/zookeeper/data
> {noformat}
> But runtime configuration has:
> {noformat}
> $ echo conf | nc localhost 2181 | grep -i data
> dataDir=/var/lib/zookeeper/datalog/version-2
> dataLogDir=/var/lib/zookeeper/data/version-2
> {noformat}
> Also, I got this in the debug logs, so clearly some parts of the server
> confuse things.
> {noformat}
> [PurgeTask:FileTxnSnapLog@79] - Opening datadir:/var/lib/zookeeper/datalog
> snapDir:/var/lib/zookeeper/data
> [main:FileTxnSnapLog@79] - Opening datadir:/var/lib/zookeeper/data
> snapDir:/var/lib/zookeeper/datalog
> {noformat}
> I tried to look in the code for wrong uses of the directories. I only found
> [ZookeeperServer.java|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L227]
> is passing the arguments to {{FileTxnSnapLog}} in the wrong order, but the
> code comment says that this is legacy only for tests, so I assume it isn't
> the cause for my case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-2960) The dataDir and dataLogDir are used opposingly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes reassigned ZOOKEEPER-2960:
-
Assignee: Andor Molnar (was: Mark Fenes)
> The dataDir and dataLogDir are used opposingly
> --
>
> Key: ZOOKEEPER-2960
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2960
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.4.11
> Environment: Not relevant.
>Reporter: Dan Milon
>Assignee: Andor Molnar
>Priority: Critical
> Fix For: 3.4.12
>
>
> _emphasized text_After upgrading from zookeeper 3.4.5, to 3.4.11, without
> editing {{zoo.cfg}}, the new version of the server tries to use the
> {{dataDir}} as the {{dataLogDir}}, and the {{dataLogDir}} as the {{dataDir}}.
> Or at least some parts of the server.
> Configuration file has:
> {noformat}
> $ grep -i data /etc/zookeeper/zoo.cfg
> dataLogDir=/var/lib/zookeeper/datalog
> dataDir=/var/lib/zookeeper/data
> {noformat}
> But runtime configuration has:
> {noformat}
> $ echo conf | nc localhost 2181 | grep -i data
> dataDir=/var/lib/zookeeper/datalog/version-2
> dataLogDir=/var/lib/zookeeper/data/version-2
> {noformat}
> Also, I got this in the debug logs, so clearly some parts of the server
> confuse things.
> {noformat}
> [PurgeTask:FileTxnSnapLog@79] - Opening datadir:/var/lib/zookeeper/datalog
> snapDir:/var/lib/zookeeper/data
> [main:FileTxnSnapLog@79] - Opening datadir:/var/lib/zookeeper/data
> snapDir:/var/lib/zookeeper/datalog
> {noformat}
> I tried to look in the code for wrong uses of the directories. I only found
> [ZookeeperServer.java|https://github.com/apache/zookeeper/blob/master/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L227]
> is passing the arguments to {{FileTxnSnapLog}} in the wrong order, but the
> code comment says that this is legacy only for tests, so I assume it isn't
> the cause for my case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2955) Enable Clover code coverage report
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes updated ZOOKEEPER-2955: -- Affects Version/s: 3.5.3 3.4.11 > Enable Clover code coverage report > -- > > Key: ZOOKEEPER-2955 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2955 > Project: ZooKeeper > Issue Type: Test > Components: tests >Affects Versions: 3.5.3, 3.4.11 >Reporter: Mark Fenes >Assignee: Mark Fenes > > We have limited code coverage support in ZK. Clover for Java was running in > the past but was turned off. > Enable Clover code coverage report to make us more confident on the quality, > stability and compatibility of future ZK releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (ZOOKEEPER-2955) Enable Clover code coverage report
Mark Fenes created ZOOKEEPER-2955: - Summary: Enable Clover code coverage report Key: ZOOKEEPER-2955 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2955 Project: ZooKeeper Issue Type: Test Components: tests Reporter: Mark Fenes Assignee: Mark Fenes We have limited code coverage support in ZK. Clover for Java was running in the past but was turned off. Enable Clover code coverage report to make us more confident on the quality, stability and compatibility of future ZK releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-2908) quorum.auth.MiniKdcTest.testKerberosLogin failing with NPE on java 9
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes reassigned ZOOKEEPER-2908:
-
Assignee: Mark Fenes
> quorum.auth.MiniKdcTest.testKerberosLogin failing with NPE on java 9
>
>
> Key: ZOOKEEPER-2908
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2908
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.5.4, 3.4.11
>Reporter: Patrick Hunt
>Assignee: Mark Fenes
>Priority: Blocker
> Fix For: 3.5.4, 3.4.11
>
>
> quorum.auth.MiniKdcTest.testKerberosLogin is failing with an NPE on Java 9.
> I recently setup jenkins jobs for java 9 on branch 3.4 and 3.5 and the test
> is failing as follows.
> {noformat}
> javax.security.auth.login.LoginException: java.lang.NullPointerException:
> invalid null input(s)
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at
> java.base/javax.security.auth.Subject$SecureSet.remove(Subject.java:1172)
> at
> java.base/java.util.Collections$SynchronizedCollection.remove(Collections.java:2039)
> at
> jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.logout(Krb5LoginModule.java:1193)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:732)
> at
> java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.logout(LoginContext.java:613)
> at
> org.apache.zookeeper.server.quorum.auth.MiniKdcTest.testKerberosLogin(MiniKdcTest.java:179)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)
> at
> java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
> at
> java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> at
> java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> at java.base/java.security.AccessController.doPrivileged(Native Method)
> at
> java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> at
> java.base/javax.security.auth.login.LoginContext.logout(LoginContext.java:613)
> at
> org.apache.zookeeper.server.quorum.auth.MiniKdcTest.testKerberosLogin(MiniKdcTest.java:179)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:55)
> {noformat}
> https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper_branch34_java9/1/testReport/junit/org.apache.zookeeper.server.quorum.auth/MiniKdcTest/testKerberosLogin/
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-2893) very poor choice of logging if client fails to connect to server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes reassigned ZOOKEEPER-2893:
-
Assignee: Mark Fenes
> very poor choice of logging if client fails to connect to server
>
>
> Key: ZOOKEEPER-2893
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2893
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.6
>Reporter: Paul Millar
>Assignee: Mark Fenes
>
> We are using ZooKeeper in our project and have received reports that, when
> suffering a networking problem, log files become flooded with messages like:
> {quote}
> 07 Sep 2017 08:22:00 (System) [] Session 0x45d3151be3600a9 for server null,
> unexpected error, closing socket connection and attempting reconnect
> java.net.NoRouteToHostException: No route to host
> at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
> ~[na:1.8.0_131]
> at
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
> ~[na:1.8.0_131]
> at
> org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:361)
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
> at
> org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1081)
> ~[zookeeper-3.4.6.jar:3.4.6-1569965]
> {quote}
> Looking at the code that logs this message ({{ClientCnxn}}), there seems to
> be quite a few problems here:
> # the code logs a stack-trace, even though there is no bug here. In our
> project, we treat all logged stack-traces as bugs,
> # if the networking issue is not fixed promptly, the log files is flooded
> with these message,
> # The message is built using {{ClientCnxnSocket#getRemoteSocketAddress}}, yet
> in this case, this does not provide the expected information (yielding
> {{null}}),
> # The log message fails to include a description of what actually went wrong.
> (Additionally, the code uses string concatenation rather than templating when
> building the message; however, this is an optimisation issue)
> My suggestion is that this log entry is updated so that it doesn't log a
> stack-trace, but does include some indication why the connection failed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-2873) print error and/or abort on invalid server definition
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Fenes reassigned ZOOKEEPER-2873:
-
Assignee: Mark Fenes
> print error and/or abort on invalid server definition
> -
>
> Key: ZOOKEEPER-2873
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2873
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.4.10
>Reporter: Christopher Smith
>Assignee: Mark Fenes
>Priority: Minor
>
> While bringing up a new cluster, I managed to fat-finger a sed script and put
> some lines like this into my config file:
> {code}
> server.1=zookeeper1:2888:2888
> {code}
> This led to a predictable spew of error messages when the client and election
> components fought over the single port. Since a configuration of this case is
> *always* an error, I suggest that it would be sensible to abort the server
> startup if an entry is found with the same port for both client and election.
> (Logging the error explicitly without shutting down is less helpful because
> of how fast the logs pile up.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-2690) Update documentation source for ZOOKEEPER-2574
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes reassigned ZOOKEEPER-2690: - Assignee: Mark Fenes > Update documentation source for ZOOKEEPER-2574 > -- > > Key: ZOOKEEPER-2690 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2690 > Project: ZooKeeper > Issue Type: Bug > Components: documentation >Affects Versions: 3.4.9, 3.5.2 >Reporter: Michael Han >Assignee: Mark Fenes >Priority: Minor > Labels: newbie > > In ZOOKEEPER-2574, the documentation change > (https://github.com/apache/zookeeper/pull/111/) was done directly on the > generated document files instead of on the document source. This JIRA is > created to track the work of porting the doc change on the doc source so the > change of the doc will not get lost between releases. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (ZOOKEEPER-1363) Categorise unit tests by 'test-commit', 'full-test' etc
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Fenes reassigned ZOOKEEPER-1363: - Assignee: Mark Fenes > Categorise unit tests by 'test-commit', 'full-test' etc > --- > > Key: ZOOKEEPER-1363 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1363 > Project: ZooKeeper > Issue Type: Improvement > Components: build, tests >Reporter: Henry Robinson >Assignee: Mark Fenes > Labels: newbie > > As discussed on the list, it would be good to split the Java test suite into > categories so that it's easy to run a small set of unit tests against a > patch, and to leave Jenkins to run the full suite of stress tests etc. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
