[jira] [Commented] (ZOOKEEPER-2251) Add Client side packet response timeout to avoid infinite wait.

[Michael Han (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734548#comment-15734548
 ] 

Michael Han commented on ZOOKEEPER-2251:


Has anyone that watching this issue able to have a deterministic reproduce of 
the issue? The timeout solution is trivial but it's important to try to figure 
out root cause of packet loss otherwise we could just fix the surface and then 
have unexpected bug bite us. 

> Add Client side packet response timeout to avoid infinite wait.
> ---
>
> Key: ZOOKEEPER-2251
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2251
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.9, 3.5.2
>Reporter: nijel
>Assignee: Arshad Mohammad
>Priority: Critical
>  Labels: fault
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2251-01.patch, ZOOKEEPER-2251-02.patch, 
> ZOOKEEPER-2251-03.patch, ZOOKEEPER-2251-04.patch
>
>
> I came across one issue related to Client side packet response timeout In my 
> cluster many packet drops happened for some time.
> One observation is the zookeeper client got hanged. As per the thread dump it 
> is waiting for the response/ACK for the operation performed (synchronous API 
> used here).
> I am using 
> zookeeper.serverCnxnFactory=org.apache.zookeeper.server.NIOServerCnxnFactory
> Since only few packets missed there is no DISCONNECTED event occurred.
> Need add a "response time out" for the operations or packets.
> *Comments from [~rakeshr]*
> My observation about the problem:-
> * Can use tools like 'Wireshark' to simulate the artificial packet loss.
> * Assume there is only one packet in the 'outgoingQueue' and unfortunately 
> the server response packet lost. Now, client will enter into infinite 
> waiting. 
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1515
> * Probably we can discuss more about this problem and possible solutions(add 
> packet ACK timeout or another better approach) in the jira.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] zookeeper pull request #119: ZOOKEEPER-2251:Add Client side packet response ...

[hanm]

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/119#discussion_r9147
  
--- Diff: src/java/main/org/apache/zookeeper/ClientCnxn.java ---
@@ -1495,10 +1504,21 @@ public ReplyHeader submitRequest(RequestHeader h, 
Record request,
 Packet packet = queuePacket(h, r, request, response, null, null, 
null,
 null, watchRegistration, watchDeregistration);
 synchronized (packet) {
+long waitStartTime = System.currentTimeMillis();
 while (!packet.finished) {
-packet.wait();
+packet.wait(requestTimeout);
--- End diff --

This unconditionally adds a timeout is a pretty significant semantic 
change. Whether or not we should wait indefinitely is a separate issue to 
discuss later, but from a compatibility point of view we'd at least provide a 
configuration option to let user opt in this feature rather than having this 
turned on by default. So by default there is no timeout and client still waits 
indefinitely, user who wants to opt in to turn on the timeout needs to explicit 
say so and provide a value they think make sense to them. Otherwise, we'd have 
to solve the problem of what the default timeout value we should set in ZK 
config if this feature is turned on by default, and that problem is hard and 
very likely there is no default value that makes everyone happy.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (ZOOKEEPER-2251) Add Client side packet response timeout to avoid infinite wait.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734535#comment-15734535
 ] 

ASF GitHub Bot commented on ZOOKEEPER-2251:
---

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/119#discussion_r9147
  
--- Diff: src/java/main/org/apache/zookeeper/ClientCnxn.java ---
@@ -1495,10 +1504,21 @@ public ReplyHeader submitRequest(RequestHeader h, 
Record request,
 Packet packet = queuePacket(h, r, request, response, null, null, 
null,
 null, watchRegistration, watchDeregistration);
 synchronized (packet) {
+long waitStartTime = System.currentTimeMillis();
 while (!packet.finished) {
-packet.wait();
+packet.wait(requestTimeout);
--- End diff --

This unconditionally adds a timeout is a pretty significant semantic 
change. Whether or not we should wait indefinitely is a separate issue to 
discuss later, but from a compatibility point of view we'd at least provide a 
configuration option to let user opt in this feature rather than having this 
turned on by default. So by default there is no timeout and client still waits 
indefinitely, user who wants to opt in to turn on the timeout needs to explicit 
say so and provide a value they think make sense to them. Otherwise, we'd have 
to solve the problem of what the default timeout value we should set in ZK 
config if this feature is turned on by default, and that problem is hard and 
very likely there is no default value that makes everyone happy.


> Add Client side packet response timeout to avoid infinite wait.
> ---
>
> Key: ZOOKEEPER-2251
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2251
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.9, 3.5.2
>Reporter: nijel
>Assignee: Arshad Mohammad
>Priority: Critical
>  Labels: fault
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2251-01.patch, ZOOKEEPER-2251-02.patch, 
> ZOOKEEPER-2251-03.patch, ZOOKEEPER-2251-04.patch
>
>
> I came across one issue related to Client side packet response timeout In my 
> cluster many packet drops happened for some time.
> One observation is the zookeeper client got hanged. As per the thread dump it 
> is waiting for the response/ACK for the operation performed (synchronous API 
> used here).
> I am using 
> zookeeper.serverCnxnFactory=org.apache.zookeeper.server.NIOServerCnxnFactory
> Since only few packets missed there is no DISCONNECTED event occurred.
> Need add a "response time out" for the operations or packets.
> *Comments from [~rakeshr]*
> My observation about the problem:-
> * Can use tools like 'Wireshark' to simulate the artificial packet loss.
> * Assume there is only one packet in the 'outgoingQueue' and unfortunately 
> the server response packet lost. Now, client will enter into infinite 
> waiting. 
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1515
> * Probably we can discuss more about this problem and possible solutions(add 
> packet ACK timeout or another better approach) in the jira.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2251) Add Client side packet response timeout to avoid infinite wait.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734534#comment-15734534
 ] 

ASF GitHub Bot commented on ZOOKEEPER-2251:
---

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/119#discussion_r91666945
  
--- Diff: src/java/main/org/apache/zookeeper/KeeperException.java ---
@@ -387,6 +389,8 @@ public void setCode(int code) {
 EPHEMERALONLOCALSESSION (EphemeralOnLocalSession),
 /** Attempts to remove a non-existing watcher */
 NOWATCHER (-121),
+/** Not received packet timely */
+TIMEOUT (-122),
--- End diff --

Similar error code needs to be added to C client to make both client 
library compatible.


> Add Client side packet response timeout to avoid infinite wait.
> ---
>
> Key: ZOOKEEPER-2251
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2251
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.9, 3.5.2
>Reporter: nijel
>Assignee: Arshad Mohammad
>Priority: Critical
>  Labels: fault
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2251-01.patch, ZOOKEEPER-2251-02.patch, 
> ZOOKEEPER-2251-03.patch, ZOOKEEPER-2251-04.patch
>
>
> I came across one issue related to Client side packet response timeout In my 
> cluster many packet drops happened for some time.
> One observation is the zookeeper client got hanged. As per the thread dump it 
> is waiting for the response/ACK for the operation performed (synchronous API 
> used here).
> I am using 
> zookeeper.serverCnxnFactory=org.apache.zookeeper.server.NIOServerCnxnFactory
> Since only few packets missed there is no DISCONNECTED event occurred.
> Need add a "response time out" for the operations or packets.
> *Comments from [~rakeshr]*
> My observation about the problem:-
> * Can use tools like 'Wireshark' to simulate the artificial packet loss.
> * Assume there is only one packet in the 'outgoingQueue' and unfortunately 
> the server response packet lost. Now, client will enter into infinite 
> waiting. 
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1515
> * Probably we can discuss more about this problem and possible solutions(add 
> packet ACK timeout or another better approach) in the jira.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2251) Add Client side packet response timeout to avoid infinite wait.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734533#comment-15734533
 ] 

ASF GitHub Bot commented on ZOOKEEPER-2251:
---

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/119#discussion_r91666999
  
--- Diff: src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml 
---
@@ -1538,6 +1538,24 @@ public abstract class ServerAuthenticationProvider 
implements AuthenticationProv
 Specifies path to kinit binary. Default is 
"/usr/bin/kinit".
 
 
+
+zookeeper.request.timeout
+
+
+New in 3.5.3:
--- End diff --

This probably would not make to 3.5.3. 3.6.0 would be a more realistic 
value.


> Add Client side packet response timeout to avoid infinite wait.
> ---
>
> Key: ZOOKEEPER-2251
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2251
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.9, 3.5.2
>Reporter: nijel
>Assignee: Arshad Mohammad
>Priority: Critical
>  Labels: fault
> Fix For: 3.4.10, 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2251-01.patch, ZOOKEEPER-2251-02.patch, 
> ZOOKEEPER-2251-03.patch, ZOOKEEPER-2251-04.patch
>
>
> I came across one issue related to Client side packet response timeout In my 
> cluster many packet drops happened for some time.
> One observation is the zookeeper client got hanged. As per the thread dump it 
> is waiting for the response/ACK for the operation performed (synchronous API 
> used here).
> I am using 
> zookeeper.serverCnxnFactory=org.apache.zookeeper.server.NIOServerCnxnFactory
> Since only few packets missed there is no DISCONNECTED event occurred.
> Need add a "response time out" for the operations or packets.
> *Comments from [~rakeshr]*
> My observation about the problem:-
> * Can use tools like 'Wireshark' to simulate the artificial packet loss.
> * Assume there is only one packet in the 'outgoingQueue' and unfortunately 
> the server response packet lost. Now, client will enter into infinite 
> waiting. 
> https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1515
> * Probably we can discuss more about this problem and possible solutions(add 
> packet ACK timeout or another better approach) in the jira.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] zookeeper pull request #119: ZOOKEEPER-2251:Add Client side packet response ...

[hanm]

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/119#discussion_r91666945
  
--- Diff: src/java/main/org/apache/zookeeper/KeeperException.java ---
@@ -387,6 +389,8 @@ public void setCode(int code) {
 EPHEMERALONLOCALSESSION (EphemeralOnLocalSession),
 /** Attempts to remove a non-existing watcher */
 NOWATCHER (-121),
+/** Not received packet timely */
+TIMEOUT (-122),
--- End diff --

Similar error code needs to be added to C client to make both client 
library compatible.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] zookeeper pull request #119: ZOOKEEPER-2251:Add Client side packet response ...

[hanm]

Github user hanm commented on a diff in the pull request:

https://github.com/apache/zookeeper/pull/119#discussion_r91666999
  
--- Diff: src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml 
---
@@ -1538,6 +1538,24 @@ public abstract class ServerAuthenticationProvider 
implements AuthenticationProv
 Specifies path to kinit binary. Default is 
"/usr/bin/kinit".
 
 
+
+zookeeper.request.timeout
+
+
+New in 3.5.3:
--- End diff --

This probably would not make to 3.5.3. 3.6.0 would be a more realistic 
value.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (ZOOKEEPER-261) Reinitialized servers should not participate in leader election

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15734431#comment-15734431
 ] 

ASF GitHub Bot commented on ZOOKEEPER-261:
--

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/120
  
lgtm +1


> Reinitialized servers should not participate in leader election
> ---
>
> Key: ZOOKEEPER-261
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-261
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: leaderElection, quorum
>Reporter: Benjamin Reed
>
> A server that has lost its data should not participate in leader election 
> until it has resynced with a leader. Our leader election algorithm and 
> NEW_LEADER commit assumes that the followers voting on a leader have not lost 
> any of their data. We should have a flag in the data directory saying whether 
> or not the data is preserved so that the the flag will be cleared if the data 
> is ever cleared.
> Here is the problematic scenario: you have have ensemble of machines A, B, 
> and C. C is down. the last transaction seen by C is z. a transaction, z+1, is 
> committed on A and B. Now there is a power outage. B's data gets 
> reinitialized. when power comes back up, B and C comes up, but A does not. C 
> will be elected leader and transaction z+1 is lost. (note, this can happen 
> even if all three machines are up and C just responds quickly. in that case C 
> would tell A to truncate z+1 from its log.) in theory we haven't violated our 
> 2f+1 guarantee, since A is failed and B still hasn't recovered from failure, 
> but it would be nice if when we don't have quorum that system stops working 
> rather than works incorrectly if we lose quorum.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] zookeeper issue #120: ZOOKEEPER-261

[hanm]

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/120
  
lgtm +1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

ZooKeeper-trunk-WinVS2008 - Build # 2353 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008/2353/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 78 lines...]

ivy-retrieve:
[ivy:retrieve] :: Apache Ivy 2.4.0 - 20141213170938 :: 
http://ant.apache.org/ivy/ ::
[ivy:retrieve] :: loading settings :: file = 
f:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-WinVS2008\ivysettings.xml
[ivy:retrieve] :: resolving dependencies :: 
org.apache.zookeeper#zookeeper;3.6.0-SNAPSHOT
[ivy:retrieve]  confs: [default]
[ivy:retrieve]  found jline#jline;2.11 in maven2
[ivy:retrieve]  found org.eclipse.jetty#jetty-server;9.2.18.v20160721 in maven2
[ivy:retrieve]  found javax.servlet#javax.servlet-api;3.1.0 in maven2
[ivy:retrieve]  found org.eclipse.jetty#jetty-http;9.2.18.v20160721 in maven2
[ivy:retrieve]  found org.eclipse.jetty#jetty-util;9.2.18.v20160721 in maven2
[ivy:retrieve]  found org.eclipse.jetty#jetty-io;9.2.18.v20160721 in maven2
[ivy:retrieve]  found org.eclipse.jetty#jetty-servlet;9.2.18.v20160721 in maven2
[ivy:retrieve]  found org.eclipse.jetty#jetty-security;9.2.18.v20160721 in 
maven2
[ivy:retrieve]  found org.codehaus.jackson#jackson-mapper-asl;1.9.11 in maven2
[ivy:retrieve]  found org.codehaus.jackson#jackson-core-asl;1.9.11 in maven2
[ivy:retrieve]  found org.slf4j#slf4j-api;1.7.5 in maven2
[ivy:retrieve]  found org.slf4j#slf4j-log4j12;1.7.5 in maven2
[ivy:retrieve]  found commons-cli#commons-cli;1.2 in maven2
[ivy:retrieve]  found log4j#log4j;1.2.17 in maven2
[ivy:retrieve]  found io.netty#netty;3.10.5.Final in maven2
[ivy:retrieve]  found net.java.dev.javacc#javacc;5.0 in maven2
[ivy:retrieve] :: resolution report :: resolve 401ms :: artifacts dl 21ms
-
|  |modules||   artifacts   |
|   conf   | number| search|dwnlded|evicted|| number|dwnlded|
-
|  default |   16  |   0   |   0   |   0   ||   16  |   0   |
-
[ivy:retrieve] :: retrieving :: org.apache.zookeeper#zookeeper
[ivy:retrieve]  confs: [default]
[ivy:retrieve]  16 artifacts copied, 0 already retrieved (4635kB/39ms)

generate_jute_parser:
[mkdir] Created dir: 
f:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-WinVS2008\build\jute_compiler\org\apache\jute\compiler\generated
[ivy:artifactproperty] DEPRECATED: 'ivy.conf.file' is deprecated, use 
'ivy.settings.file' instead
[ivy:artifactproperty] :: loading settings :: file = 
f:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-WinVS2008\ivysettings.xml
 [move] Moving 1 file to 
f:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-WinVS2008\build\lib
   [javacc] Java Compiler Compiler Version 5.0 (Parser Generator)
   [javacc] (type "javacc" with no arguments for help)
   [javacc] Reading from file 
f:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-WinVS2008\src\java\main\org\apache\jute\compiler\generated\rcc.jj
 . . .
   [javacc] File "TokenMgrError.java" does not exist.  Will create one.
   [javacc] File "ParseException.java" does not exist.  Will create one.
   [javacc] File "Token.java" does not exist.  Will create one.
   [javacc] File "SimpleCharStream.java" does not exist.  Will create one.
   [javacc] Parser generated successfully.

jute:

BUILD FAILED
f:\jenkins\jenkins-slave\workspace\ZooKeeper-trunk-WinVS2008\build.xml:273: 
Unable to find a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to "C:\Program Files\Java\jre1.8.0_92"

Total time: 3 seconds
Build step 'Invoke Ant' marked build as failure
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



###
## FAILED TESTS (if any) 
##
No tests ran.

ZooKeeper_branch34_jdk7 - Build # 1317 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_jdk7/1317/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 231117 lines...]
[junit] 2016-12-09 03:02:02,621 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@219] - 
NIOServerCnxn factory exited run method
[junit] 2016-12-09 03:02:02,621 [myid:] - INFO  [main:ZooKeeperServer@497] 
- shutting down
[junit] 2016-12-09 03:02:02,621 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-09 03:02:02,622 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-12-09 03:02:02,622 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-12-09 03:02:02,622 [myid:] - INFO  
[main:SyncRequestProcessor@208] - Shutting down
[junit] 2016-12-09 03:02:02,622 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-12-09 03:02:02,622 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@186] - SyncRequestProcessor exited!
[junit] 2016-12-09 03:02:02,623 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-12-09 03:02:02,623 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-12-09 03:02:02,624 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-12-09 03:02:02,625 [myid:] - INFO  [main:ClientBase@445] - 
STARTING server
[junit] 2016-12-09 03:02:02,626 [myid:] - INFO  [main:ClientBase@366] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-12-09 03:02:02,626 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-12-09 03:02:02,626 [myid:] - INFO  [main:ClientBase@341] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-12-09 03:02:02,627 [myid:] - INFO  [main:ZooKeeperServer@173] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/build/test/tmp/test4164773545365295843.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/build/test/tmp/test4164773545365295843.junit.dir/version-2
[junit] 2016-12-09 03:02:02,631 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-09 03:02:02,632 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-12-09 03:02:02,632 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:37495
[junit] 2016-12-09 03:02:02,633 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:37495
[junit] 2016-12-09 03:02:02,633 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-12-09 03:02:02,634 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:37495 (no session established for client)
[junit] 2016-12-09 03:02:02,634 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-12-09 03:02:02,636 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-12-09 03:02:02,637 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-12-09 03:02:02,637 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-12-09 03:02:02,637 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-12-09 03:02:02,637 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 32679
[junit] 2016-12-09 03:02:02,638 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-12-09 03:02:02,638 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-12-09 03:02:02,638 [myid:] - INFO  [main:ClientBase@522] - 
tearDown starting
[junit] 2016-12-09 03:02:02,675 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x158e187c84e closed
[junit] 2016-12-09 03:02:02,675 [myid:] - INFO  [main:ClientBase@492] - 
STOPPING server
[junit] 2016-12-09 03:02:02,675 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x158e187c84e
[junit] 2016-12-09 

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Rakesh R (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733973#comment-15733973
 ] 

Rakesh R commented on ZOOKEEPER-1045:
-

Thanks [~hanm] for adding that point. IIUC, this has to be covered in both 
client-server and server-server sasl layers. How about discuss & implement this 
separately via another jira task?

> Support Quorum Peer mutual authentication via SASL
> --
>
> Key: ZOOKEEPER-1045
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: quorum, security
>Reporter: Eugene Koontz
>Assignee: Rakesh R
>Priority: Critical
> Fix For: 3.4.10
>
> Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch, 
> 1045_failing_phunt.tar.gz, HOST_RESOLVER-ZK-1045.patch, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-10.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-25.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-29.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-30.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Sep-25.pdf, 
> TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt, 
> ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045 Test Plan.pdf, 
> ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045TestValidationDesign.pdf, 
> org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.testRollingUpgrade.log
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers. 
> This bug, on the other hand, is for authentication among quorum peers. 
> Hopefully much of the work done on SASL integration with Zookeeper for 
> ZOOKEEPER-938 can be used as a foundation for this enhancement.
> Review board: https://reviews.apache.org/r/47354/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1045) Support Quorum Peer mutual authentication via SASL

[Michael Han (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733923#comment-15733923
 ] 

Michael Han commented on ZOOKEEPER-1045:


Sounds good. These captures the following up work to forward port 1045 to 
master / 3.5.x. Just add one additional note, we talked about one issue 
previously that Kerberos treats frequent login attempts as replay attacks, so 
we'd need some code to deal with this. What Chris commented earlier:

bq. Hadoop's RPC framework handles this case with a brief backoff and retry to 
work around the case of getting flagged as a replay attack.

This would need on both 3.4.x and 3.5 I think. 

> Support Quorum Peer mutual authentication via SASL
> --
>
> Key: ZOOKEEPER-1045
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1045
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: quorum, security
>Reporter: Eugene Koontz
>Assignee: Rakesh R
>Priority: Critical
> Fix For: 3.4.10
>
> Attachments: 0001-ZOOKEEPER-1045-br-3-4.patch, 
> 1045_failing_phunt.tar.gz, HOST_RESOLVER-ZK-1045.patch, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-10.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-25.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-29.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Nov-30.pdf, QuorumPeer Mutual 
> Authentication Via Sasl Feature Doc - 2016-Sep-25.pdf, 
> TEST-org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.txt, 
> ZK-1045-test-case-failure-logs.zip, ZOOKEEPER-1045 Test Plan.pdf, 
> ZOOKEEPER-1045-00.patch, ZOOKEEPER-1045-Rolling Upgrade Design Proposal.pdf, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045-br-3-4.patch, ZOOKEEPER-1045-br-3-4.patch, 
> ZOOKEEPER-1045TestValidationDesign.pdf, 
> org.apache.zookeeper.server.quorum.auth.QuorumAuthUpgradeTest.testRollingUpgrade.log
>
>
> ZOOKEEPER-938 addresses mutual authentication between clients and servers. 
> This bug, on the other hand, is for authentication among quorum peers. 
> Hopefully much of the work done on SASL integration with Zookeeper for 
> ZOOKEEPER-938 can be used as a foundation for this enhancement.
> Review board: https://reviews.apache.org/r/47354/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: reconfig APIs

[Jordan Zimmerman]

Thanks for the replies everyone. Adding the methods back with a deprecation 
notice solves Curator’s problems so I’ll proceed with that on ZOOKEEPER-2642.

-Jordan

> On Dec 8, 2016, at 6:56 PM, Michael Han  wrote:
> 
> Thanks Jordan for raising the concern. It's a reasonable concern with good
> intention to make user's life easier, which is important to the project.
> 
> There are two separate issues we need to reach a consensus here:
> 
> * Move reconfig API
> The details of why the decision was made is documented in ZOOKEEPER-2014
> JIRA, but just to recap, the API is moved because it's the right thing to
> do in long term, which yield a cleaner interface design for ZooKeeper
> client API. In future, we might also want to clean up other APIs (i.e. move
> quota related APIs over as well.) as well. While seemingly stylish as it
> might look like, I believe a clean API is also important for a project's
> usability / adoption. From the discussions so far I think everyone either
> agree with this, or have no strong opinion against it, so I consider this
> question is solved.
> 
> * Backward compatibility between releases
> Since we decide refactor reconfig API, the question is when. The reconfig
> API was removed from ZOOKEEPER-2014 (which targets 3.5.3 alpha) because of
> the definition of alpha / beta releases in the context of ZooKeeper project
> (I'm not saying this is right or wrong, simply state a fact up to date): an
> alpha release implies that we allow backward incompatible changes, and a
> beta release implies that the APIs are locked down and none backward
> compatible change. Given this definition, it is perfectly legitimate to
> move API around w/o considering compatibility. Now what Jordan pointed out
> regarding definition of 'alpha' combined with some old discussion threads I
> found in user list indicate that our definition of 'alpha', and 'beta' is
> none standard and could cause confusions. So I think we should try reach a
> consensus on whether we stick with current definition of 'alpha' and 'beta'
> release during 3.5.3 release cycle, or adopt something else.
> 
> With all these said, I think options are:
> * Do nothing, stick with current alpha / beta definition.
> * Try redefine what 'alpha' and 'beta' means in the context of ZooKeeper
> and then go from there in 3.5.3 release cycle.
> 
> In any cases, I'd like to propose we keep the reconfig API in
> ZooKeeperAdmin which as previously stated is the right thing to do in long
> term. If we decide to maintain backward API compatibility for 3.5.3-beta
> release, we could add reconfig API back to ZooKeeper but mark it as
> deprecated, then remove the API in next major release (3.6 or 4.x).
> 
> 
> On Thu, Dec 8, 2016 at 8:27 AM, Patrick Hunt  wrote:
> 
>> I've only seen a few questions about versioning come up on the ZK lists,
>> they were quickly responded to with pointers to the process. iirc we based
>> our versioning scheme on what Hadoop was/is using. Additionally if we don't
>> allow for alpha time it will further slow progress as there will be no
>> opportunity to adjust things like APIs once they are committed and
>> generally available for people to "kick the tires".
>> 
>> I'll leave it up to the rest of the community to state their opinions, but
>> as i have stated imo it would be a mistake to revert this change. Jordan
>> has raised a reasonable concern - I consider this a blocker for 3.5.3-alpha
>> until it is resolved.
>> 
>> Patrick
>> 
>> On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman <
>> jor...@jordanzimmerman.com
>>> wrote:
>> 
 I think people understand what alpha means.
>>> 
>>> With respect, the ZooKeeper team has used “alpha” in a novel way that is
>>> sowing considerable confusion. I wrote emails about this a while back.
>> But,
>>> here again, is another case where the non-standard usage of “alpha” will
>>> cause confusion. To reiterate: someone who sees "3.5.2-alpha” will think
>>> that there will eventually be a “3.5.2-beta” and finally a “3.5.2”
>> release
>>> version. But, with ZooKeeper there will never be a “3.5.2” release. In
>>> fact, the “-alpha” label is mis-located. The real version is
>>> “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication
>> here.
>>> If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees
>>> “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two
>>> different releases. What ZOOKEEPER-2014 has done is remove an existing
>> API
>>> from what appears to be a released version 3.5.2 (which never really
>>> existed). This change violates semantic versioning. For external users,
>> the
>>> version after “3.5.2” should be “4.x.x” as it has breaking changes.
>>> 
 It's not about style, there were a number of concerns addressed in that
 patch.
>>> 
>>> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be
>>> addressed completely without moving the reconfig() methods to a new
>> 

[jira] [Commented] (ZOOKEEPER-2517) jute.maxbuffer is ignored

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733566#comment-15733566
 ] 

ASF GitHub Bot commented on ZOOKEEPER-2517:
---

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/113
  
@rgs1 this is the blocker issue we were talking about, please take a look 
at it.


> jute.maxbuffer is ignored
> -
>
> Key: ZOOKEEPER-2517
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2517
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.5.2
>Reporter: Benjamin Jaton
>Assignee: Arshad Mohammad
>Priority: Blocker
> Fix For: 3.5.3, 3.6.0
>
> Attachments: ZOOKEEPER-2517-01.patch, ZOOKEEPER-2517-02.patch, 
> ZOOKEEPER-2517-03.patch, ZOOKEEPER-2517-04.patch, ZOOKEEPER-2517.patch
>
>
> In ClientCnxnSocket.java the parsing of the system property is erroneous:
> {code}packetLen = Integer.getInteger(
>   clientConfig.getProperty(ZKConfig.JUTE_MAXBUFFER),
>   ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT
> );{code}
> Javadoc of Integer.getInteger states "The first argument is treated as the 
> name of a system property", whereas here the value of the property is passed.
> Instead I believe the author meant to write something like:
> {code}packetLen = Integer.parseInt(
>   clientConfig.getProperty(
> ZKConfig.JUTE_MAXBUFFER,
> String.valueOf(ZKClientConfig.CLIENT_MAX_PACKET_LENGTH_DEFAULT)
>   )
> );{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] zookeeper issue #113: ZOOKEEPER-2517:jute.maxbuffer is ignored

[hanm]

Github user hanm commented on the issue:

https://github.com/apache/zookeeper/pull/113
  
@rgs1 this is the blocker issue we were talking about, please take a look 
at it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Success: ZOOKEEPER- PreCommit Build #107

[Apache Jenkins Server]

Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/107/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 470368 lines...]
 [exec] +1 overall.  GitHub Pull Request  Build
 [exec]   
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +0 tests included.  The patch appears to be a documentation 
patch that doesn't require tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 3.0.1) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/107//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/107//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-github-pr-build/107//console
 [exec] 
 [exec] This message is automatically generated.
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Adding comment to Jira.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] Error: No value specified for option "issue"
 [exec] 768b11c3bd02cdb526ed35a961b285536172fd62 logged out
 [exec] 
 [exec] 
 [exec] 
==
 [exec] 
==
 [exec] Finished build.
 [exec] 
==
 [exec] 
==
 [exec] 
 [exec] 
 [exec] mv: 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 and 
'/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-github-pr-build/patchprocess'
 are the same file

BUILD SUCCESSFUL
Total time: 19 minutes 1 second
Archiving artifacts
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Recording test results
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
[description-setter] Could not determine description.
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Email was triggered for: Success
Sending email for trigger: Success
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7
Setting JDK_1_7_LATEST__HOME=/home/jenkins/tools/java/latest1.7



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-261) Reinitialized servers should not participate in leader election

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15733423#comment-15733423
 ] 

ASF GitHub Bot commented on ZOOKEEPER-261:
--

Github user enixon commented on the issue:

https://github.com/apache/zookeeper/pull/120
  
- add documentation on 'zookeeper.db.autocreate' to zookeeperAdmin.xml
- extend  bin/zkServer-initialize.sh to create the initialize file
- treat failure to delete initialization file as fatal, throw IOException 
instead of logging a warning


> Reinitialized servers should not participate in leader election
> ---
>
> Key: ZOOKEEPER-261
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-261
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: leaderElection, quorum
>Reporter: Benjamin Reed
>
> A server that has lost its data should not participate in leader election 
> until it has resynced with a leader. Our leader election algorithm and 
> NEW_LEADER commit assumes that the followers voting on a leader have not lost 
> any of their data. We should have a flag in the data directory saying whether 
> or not the data is preserved so that the the flag will be cleared if the data 
> is ever cleared.
> Here is the problematic scenario: you have have ensemble of machines A, B, 
> and C. C is down. the last transaction seen by C is z. a transaction, z+1, is 
> committed on A and B. Now there is a power outage. B's data gets 
> reinitialized. when power comes back up, B and C comes up, but A does not. C 
> will be elected leader and transaction z+1 is lost. (note, this can happen 
> even if all three machines are up and C just responds quickly. in that case C 
> would tell A to truncate z+1 from its log.) in theory we haven't violated our 
> 2f+1 guarantee, since A is failed and B still hasn't recovered from failure, 
> but it would be nice if when we don't have quorum that system stops working 
> rather than works incorrectly if we lose quorum.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] zookeeper issue #120: ZOOKEEPER-261

[enixon]

Github user enixon commented on the issue:

https://github.com/apache/zookeeper/pull/120
  
- add documentation on 'zookeeper.db.autocreate' to zookeeperAdmin.xml
- extend  bin/zkServer-initialize.sh to create the initialize file
- treat failure to delete initialization file as fatal, throw IOException 
instead of logging a warning


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: reconfig APIs

[Michael Han]

Thanks Jordan for raising the concern. It's a reasonable concern with good
intention to make user's life easier, which is important to the project.

There are two separate issues we need to reach a consensus here:

* Move reconfig API
The details of why the decision was made is documented in ZOOKEEPER-2014
JIRA, but just to recap, the API is moved because it's the right thing to
do in long term, which yield a cleaner interface design for ZooKeeper
client API. In future, we might also want to clean up other APIs (i.e. move
quota related APIs over as well.) as well. While seemingly stylish as it
might look like, I believe a clean API is also important for a project's
usability / adoption. From the discussions so far I think everyone either
agree with this, or have no strong opinion against it, so I consider this
question is solved.

* Backward compatibility between releases
Since we decide refactor reconfig API, the question is when. The reconfig
API was removed from ZOOKEEPER-2014 (which targets 3.5.3 alpha) because of
the definition of alpha / beta releases in the context of ZooKeeper project
(I'm not saying this is right or wrong, simply state a fact up to date): an
alpha release implies that we allow backward incompatible changes, and a
beta release implies that the APIs are locked down and none backward
compatible change. Given this definition, it is perfectly legitimate to
move API around w/o considering compatibility. Now what Jordan pointed out
regarding definition of 'alpha' combined with some old discussion threads I
found in user list indicate that our definition of 'alpha', and 'beta' is
none standard and could cause confusions. So I think we should try reach a
consensus on whether we stick with current definition of 'alpha' and 'beta'
release during 3.5.3 release cycle, or adopt something else.

With all these said, I think options are:
* Do nothing, stick with current alpha / beta definition.
* Try redefine what 'alpha' and 'beta' means in the context of ZooKeeper
and then go from there in 3.5.3 release cycle.

In any cases, I'd like to propose we keep the reconfig API in
ZooKeeperAdmin which as previously stated is the right thing to do in long
term. If we decide to maintain backward API compatibility for 3.5.3-beta
release, we could add reconfig API back to ZooKeeper but mark it as
deprecated, then remove the API in next major release (3.6 or 4.x).


On Thu, Dec 8, 2016 at 8:27 AM, Patrick Hunt  wrote:

> I've only seen a few questions about versioning come up on the ZK lists,
> they were quickly responded to with pointers to the process. iirc we based
> our versioning scheme on what Hadoop was/is using. Additionally if we don't
> allow for alpha time it will further slow progress as there will be no
> opportunity to adjust things like APIs once they are committed and
> generally available for people to "kick the tires".
>
> I'll leave it up to the rest of the community to state their opinions, but
> as i have stated imo it would be a mistake to revert this change. Jordan
> has raised a reasonable concern - I consider this a blocker for 3.5.3-alpha
> until it is resolved.
>
> Patrick
>
> On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman <
> jor...@jordanzimmerman.com
> > wrote:
>
> > > I think people understand what alpha means.
> >
> > With respect, the ZooKeeper team has used “alpha” in a novel way that is
> > sowing considerable confusion. I wrote emails about this a while back.
> But,
> > here again, is another case where the non-standard usage of “alpha” will
> > cause confusion. To reiterate: someone who sees "3.5.2-alpha” will think
> > that there will eventually be a “3.5.2-beta” and finally a “3.5.2”
> release
> > version. But, with ZooKeeper there will never be a “3.5.2” release. In
> > fact, the “-alpha” label is mis-located. The real version is
> > “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication
> here.
> > If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees
> > “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two
> > different releases. What ZOOKEEPER-2014 has done is remove an existing
> API
> > from what appears to be a released version 3.5.2 (which never really
> > existed). This change violates semantic versioning. For external users,
> the
> > version after “3.5.2” should be “4.x.x” as it has breaking changes.
> >
> > > It's not about style, there were a number of concerns addressed in that
> > > patch.
> >
> > The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be
> > addressed completely without moving the reconfig() methods to a new
> class.
> > It may be useful to move APIs around for clarity, etc. but these breaking
> > changes should be for a version that signals breaking changes - 4.x.x or
> > something. i.e. moving the reconfig() APIs is orthogonal to the concerns
> of
> > ZOOKEEPER-2014 and should be a separate Jira issue.
> >
> > > I think people understand what alpha means. 

ZooKeeper_branch35_solaris - Build # 344 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_solaris/344/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 464344 lines...]
[junit] 2016-12-08 17:14:57,607 [myid:] - INFO  [main:ClientBase@386] - 
CREATING server instance 127.0.0.1:11222
[junit] 2016-12-08 17:14:57,607 [myid:] - INFO  
[main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2016-12-08 17:14:57,608 [myid:] - INFO  
[main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2016-12-08 17:14:57,608 [myid:] - INFO  [main:ClientBase@361] - 
STARTING server instance 127.0.0.1:11222
[junit] 2016-12-08 17:14:57,609 [myid:] - INFO  [main:ZooKeeperServer@893] 
- minSessionTimeout set to 6000
[junit] 2016-12-08 17:14:57,609 [myid:] - INFO  [main:ZooKeeperServer@902] 
- maxSessionTimeout set to 6
[junit] 2016-12-08 17:14:57,609 [myid:] - INFO  [main:ZooKeeperServer@159] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test9103091309487047784.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test9103091309487047784.junit.dir/version-2
[junit] 2016-12-08 17:14:57,610 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test9103091309487047784.junit.dir/version-2/snapshot.b
[junit] 2016-12-08 17:14:57,612 [myid:] - INFO  [main:FileTxnSnapLog@306] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch35_solaris/build/test/tmp/test9103091309487047784.junit.dir/version-2/snapshot.b
[junit] 2016-12-08 17:14:57,613 [myid:] - ERROR [main:ZooKeeperServer@505] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-08 17:14:57,613 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 11222
[junit] 2016-12-08 17:14:57,614 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11222:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:40861
[junit] 2016-12-08 17:14:57,615 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@485] - Processing stat command from 
/127.0.0.1:40861
[junit] 2016-12-08 17:14:57,615 [myid:] - INFO  
[NIOWorkerThread-1:StatCommand@49] - Stat command output
[junit] 2016-12-08 17:14:57,615 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@607] - Closed socket connection for client 
/127.0.0.1:40861 (no session established for client)
[junit] 2016-12-08 17:14:57,615 [myid:] - INFO  [main:JMXEnv@228] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-12-08 17:14:57,617 [myid:] - INFO  [main:JMXEnv@245] - 
expect:InMemoryDataTree
[junit] 2016-12-08 17:14:57,617 [myid:] - INFO  [main:JMXEnv@249] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222,name1=InMemoryDataTree
[junit] 2016-12-08 17:14:57,617 [myid:] - INFO  [main:JMXEnv@245] - 
expect:StandaloneServer_port
[junit] 2016-12-08 17:14:57,617 [myid:] - INFO  [main:JMXEnv@249] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11222
[junit] 2016-12-08 17:14:57,618 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 17749
[junit] 2016-12-08 17:14:57,618 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 24
[junit] 2016-12-08 17:14:57,618 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testQuota
[junit] 2016-12-08 17:14:57,618 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-12-08 17:14:57,692 [myid:] - INFO  [main:ZooKeeper@1311] - 
Session: 0x1255c684eaf closed
[junit] 2016-12-08 17:14:57,692 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x1255c684eaf
[junit] 2016-12-08 17:14:57,692 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-12-08 17:14:57,693 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2016-12-08 17:14:57,693 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2016-12-08 17:14:57,693 [myid:] - INFO  

Re: reconfig APIs

[Patrick Hunt]

I've only seen a few questions about versioning come up on the ZK lists,
they were quickly responded to with pointers to the process. iirc we based
our versioning scheme on what Hadoop was/is using. Additionally if we don't
allow for alpha time it will further slow progress as there will be no
opportunity to adjust things like APIs once they are committed and
generally available for people to "kick the tires".

I'll leave it up to the rest of the community to state their opinions, but
as i have stated imo it would be a mistake to revert this change. Jordan
has raised a reasonable concern - I consider this a blocker for 3.5.3-alpha
until it is resolved.

Patrick

On Thu, Dec 8, 2016 at 1:46 AM, Jordan Zimmerman  wrote:

> > I think people understand what alpha means.
>
> With respect, the ZooKeeper team has used “alpha” in a novel way that is
> sowing considerable confusion. I wrote emails about this a while back. But,
> here again, is another case where the non-standard usage of “alpha” will
> cause confusion. To reiterate: someone who sees "3.5.2-alpha” will think
> that there will eventually be a “3.5.2-beta” and finally a “3.5.2” release
> version. But, with ZooKeeper there will never be a “3.5.2” release. In
> fact, the “-alpha” label is mis-located. The real version is
> “3.5.?-alpha1”, “3.5.?-alpha2”, etc. There’s an important implication here.
> If a ZooKeeper user who doesn’t follow the mailing lists, etc. sees
> “3.5.2-alpha” and “3.5.3-alpha” they will mentally see these as two
> different releases. What ZOOKEEPER-2014 has done is remove an existing API
> from what appears to be a released version 3.5.2 (which never really
> existed). This change violates semantic versioning. For external users, the
> version after “3.5.2” should be “4.x.x” as it has breaking changes.
>
> > It's not about style, there were a number of concerns addressed in that
> > patch.
>
> The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be
> addressed completely without moving the reconfig() methods to a new class.
> It may be useful to move APIs around for clarity, etc. but these breaking
> changes should be for a version that signals breaking changes - 4.x.x or
> something. i.e. moving the reconfig() APIs is orthogonal to the concerns of
> ZOOKEEPER-2014 and should be a separate Jira issue.
>
> > I think people understand what alpha means. There may be some short term
> > impact for a few, but a significant benefit over the long term.
>
> Again with respect - 3.5.0-alpha was made available in Maven Central
> August 2014 - over 2 years ago. Regardless of the ZooKeeper team’s intent,
> this is NOT an alpha in users’ minds. This is a released library that is in
> production in major organizations. The ZooKeeper team should realize this
> and adjust their thinking about the “alpha” tag. For Apache Curator, we’re
> now put in a position where the reconfig() APIs have disappeared. In order
> to maintain our own internal semantic versioning we will have to consider a
> third branch of Curator (we currently have a ZooKeeper 3.4.x compatible
> version and a ZooKeeper 3.5.x compatible version). It would be awesome if
> we didn’t have to do this.
>
> -Jordan
>
> > On Dec 7, 2016, at 7:16 PM, Patrick Hunt  wrote:
> >
> > It's not about style, there were a number of concerns addressed in that
> > patch. We didn't take the change lightly, we've been discussing it over
> > jira and the mailing list over the past two years.
> >
> > I think people understand what alpha means. There may be some short term
> > impact for a few, but a significant benefit over the long term.
> >
> > Patrick
> >
> > On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" 
> > wrote:
> >
> >> I read through the issue and disagree about the decision to move the
> APIs
> >> out. That was a stylistic choice that breaks client code. I realize that
> >> 3.5.x has been advertised as an alpha but you must realize that most of
> the
> >> world is using it in production. These APIs have now been published.
> This
> >> will create a real headache for Curator which is why I’ve created
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 <
> >> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can
> >> move these APIs back into ZooKeeper.java.
> >>
> >> -Jordan
> >>
> >>> On Dec 7, 2016, at 5:54 PM, Patrick Hunt  wrote:
> >>>
> >>> It's discussed in more depth in the JIRA iirc, but basically;
> >>> ZooKeeper.java provides client APIs, reconfig is an admiistrative API.
> >>>
> >>> Patrick
> >>>
> >>> On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman <
> >> jor...@jordanzimmerman.com
>  wrote:
> >>>
>  I understand the need to make the methods require proper auth but
> >> there's
>  no reason to move it to a different class that I can see. Am I missing
>  something?
> 
>  
>  Jordan Zimmerman
> 
> > On 

Re: Upcoming 3.4/3.5 releases.

[Patrick Hunt]

The inclusion of ZOOKEEPER-2014 has been raised as a problem by Jordan (see
the separate thread on this list). I don't feel I can cut a 3.5.3-alpha
release until the issue has been resolved by the community. I was hoping to
get a release candidate created before vacation starts, so please comment
on that thread asap so that we can progress.

Patrick

On Thu, Nov 24, 2016 at 8:53 AM, Flavio Junqueira  wrote:

> We need to regenerate the documentation to include recent changes. I have
> created ZK-2635 and assigned to myself. It should be simple enough, though.
> I've marked the fix version to include 3.5.3 and 3.6.0, but I'm not sure if
> anything has been merged recently into the 3.4 branch that had
> documentation changes. If anyone is aware of such a change, please change
> the jira accordingly.
>
> This is not necessarily a blocker, but there is one issue that we need to
> resolve with our current workflow. Previously, we submitted patches by
> uploading the patch and hitting the "Submit Patch" button. Submitting the
> patch triggers the QA build, which executes the test script, which goes to
> jira and fetches the patch to test. With pull requests, the process is
> different. The github plugin triggers the build, which fetches the diff
> from the PR and runs the test script.
>
> Ideally, if it is a pull request, we change the status of the jira to
> "Patch Available", but we do not trigger the QA for jira patches. I don't
> know how to do it, though, so the choices we have are:
>
> 1- To only change the status to "Patch Available" if there is a jira
> patch, which is not ideal.
> 2- To disable the jira patch QA and rely only on pull requests.
>
> Unless someone comes up with a solution that enables us to change the
> status of the jira to path available and only triggers QA in the case there
> is a jira patch, I believe the best option is number 2 and the [DISCUSS]
> thread I started about this seems to indicate that others prefer that
> option too. If folks feel it is necessary to vote to capture more precisely
> the decision, I can start a vote thread on the dev list.
>
> -Flavio
>
>
> > On 23 Nov 2016, at 17:39, Patrick Hunt  wrote:
> >
> > Forgot to mention. These will be our first releases using git rather than
> > svn. Does anyone know of remaining issues we need to resolve related to
> > this prior to cutting a release?
> >
> > Patrick
> >
> > On Wed, Nov 23, 2016 at 9:38 AM, Patrick Hunt  wrote:
> >
> >> Hi folks. Now that ZOOKEEPER-2014 has been committed I think we should
> cut
> >> a 3.5.3-alpha release. We're getting close to beta with that one
> finalized.
> >> There are about 10 blockers, although I have not recently gone through
> and
> >> triaged them
> >> https://issues.apache.org/jira/secure/Dashboard.jspa?
> selectPageId=12327688
> >> note that about half of those are patch available, if you have some free
> >> cycles please focus on these, here's the prioritized list:
> >> https://issues.apache.org/jira/issues/?filter=12336872;
> >> jql=project%20%3D%20zookeeper%20AND%20fixVersion%20%3D%203.
> >> 5.3%20and%20resolution%20%3D%20unresolved%20ORDER%20BY%
> 20priority%20DESC
> >>
> >> I believe Rakesh (please confirm) is interested in releasing 3.4.10 once
> >> ZOOKEEPER-1045 is committed. That patch has had extensive testing and
> >> documentation (kudos Rakesh, et. al.) and is in final review -- unless
> >> someone speaks up it will be committed soon, probably next week. Here's
> the
> >> prioritized list, not sure of those blockers really are blockers -
> Flavio
> >> do we still need to address the netty license issue:
> >> https://issues.apache.org/jira/issues/?filter=12338391;
> >> jql=project%20%3D%20zookeeper%20AND%20fixVersion%20%3D%203.
> >> 4.10%20and%20resolution%20%3D%20unresolved%20ORDER%20BY%
> 20priority%20DESC
> >>
> >> Patrick
> >>
> >>
>
>

ZooKeeper_branch34_solaris - Build # 1382 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch34_solaris/1382/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 187566 lines...]
[junit] 2016-12-08 13:54:34,655 [myid:] - INFO  [main:ZooKeeperServer@497] 
- shutting down
[junit] 2016-12-08 13:54:34,655 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-08 13:54:34,655 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2016-12-08 13:54:34,655 [myid:] - INFO  
[main:PrepRequestProcessor@765] - Shutting down
[junit] 2016-12-08 13:54:34,656 [myid:] - INFO  
[main:SyncRequestProcessor@208] - Shutting down
[junit] 2016-12-08 13:54:34,656 [myid:] - INFO  [ProcessThread(sid:0 
cport:11221)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2016-12-08 13:54:34,656 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@186] - SyncRequestProcessor exited!
[junit] 2016-12-08 13:54:34,656 [myid:] - INFO  
[main:FinalRequestProcessor@402] - shutdown of request processor complete
[junit] 2016-12-08 13:54:34,656 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-12-08 13:54:34,657 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-12-08 13:54:34,657 [myid:] - INFO  [main:ClientBase@445] - 
STARTING server
[junit] 2016-12-08 13:54:34,658 [myid:] - INFO  [main:ClientBase@366] - 
CREATING server instance 127.0.0.1:11221
[junit] 2016-12-08 13:54:34,658 [myid:] - INFO  
[main:NIOServerCnxnFactory@89] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2016-12-08 13:54:34,658 [myid:] - INFO  [main:ClientBase@341] - 
STARTING server instance 127.0.0.1:11221
[junit] 2016-12-08 13:54:34,659 [myid:] - INFO  [main:ZooKeeperServer@173] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/build/test/tmp/test1211537121188287877.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris/build/test/tmp/test1211537121188287877.junit.dir/version-2
[junit] 2016-12-08 13:54:34,661 [myid:] - ERROR [main:ZooKeeperServer@472] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-08 13:54:34,661 [myid:] - INFO  
[main:FourLetterWordMain@62] - connecting to 127.0.0.1 11221
[junit] 2016-12-08 13:54:34,662 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@192] - 
Accepted socket connection from /127.0.0.1:54629
[junit] 2016-12-08 13:54:34,662 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:54629
[junit] 2016-12-08 13:54:34,662 [myid:] - INFO  
[Thread-5:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2016-12-08 13:54:34,662 [myid:] - INFO  
[Thread-5:NIOServerCnxn@1008] - Closed socket connection for client 
/127.0.0.1:54629 (no session established for client)
[junit] 2016-12-08 13:54:34,663 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2016-12-08 13:54:34,664 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2016-12-08 13:54:34,664 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree
[junit] 2016-12-08 13:54:34,664 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2016-12-08 13:54:34,664 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port11221
[junit] 2016-12-08 13:54:34,664 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@58] - Memory used 8878
[junit] 2016-12-08 13:54:34,665 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@63] - Number of threads 20
[junit] 2016-12-08 13:54:34,665 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@78] - FINISHED TEST METHOD testQuota
[junit] 2016-12-08 13:54:34,665 [myid:] - INFO  [main:ClientBase@522] - 
tearDown starting
[junit] 2016-12-08 13:54:34,742 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x158deb6d68e closed
[junit] 2016-12-08 13:54:34,742 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@519] - EventThread shut down for 
session: 0x158deb6d68e
[junit] 2016-12-08 13:54:34,742 [myid:] - INFO  [main:ClientBase@492] - 
STOPPING server
[junit] 2016-12-08 13:54:34,743 [myid:] - INFO  [main:ZooKeeperServer@497] 
- shutting down
[junit] 2016-12-08 13:54:34,743 [myid:] - 

ZooKeeper_branch35_jdk8 - Build # 327 - Failure

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_jdk8/327/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 485988 lines...]
[junit] 2016-12-08 12:14:11,741 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-12-08 12:14:11,741 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:30317
[junit] 2016-12-08 12:14:11,740 [myid:] - INFO  
[SyncThread:0:MBeanRegistry@128] - Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port30317,name1=Connections,name2=127.0.0.1,name3=0x102242c8838]
[junit] 2016-12-08 12:14:11,742 [myid:] - INFO  [main:ZooKeeperServer@533] 
- shutting down
[junit] 2016-12-08 12:14:11,742 [myid:] - ERROR [main:ZooKeeperServer@505] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  
[main:PrepRequestProcessor@974] - Shutting down
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  [ProcessThread(sid:0 
cport:30317)::PrepRequestProcessor@154] - PrepRequestProcessor exited loop!
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  
[main:FinalRequestProcessor@479] - shutdown of request processor complete
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port30317,name1=InMemoryDataTree]
[junit] 2016-12-08 12:14:11,743 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port30317]
[junit] 2016-12-08 12:14:11,753 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 30317
[junit] 2016-12-08 12:14:11,753 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-12-08 12:14:11,757 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 1461 at start it was 1461
[junit] 2016-12-08 12:14:11,757 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-12-08 12:14:11,757 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
459.935 sec, Thread: 8, Class: org.apache.zookeeper.test.NettyNettySuiteTest
[junit] 2016-12-08 12:14:11,974 [myid:127.0.0.1:30197] - INFO  
[main-SendThread(127.0.0.1:30197):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:30197. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-12-08 12:14:11,975 [myid:] - INFO  [New I/O boss 
#2727:ClientCnxnSocketNetty$1@127] - future isn't success, cause: {}
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:30197
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.processSelectedKeys(NioClientBoss.java:105)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.process(NioClientBoss.java:79)
[junit] at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.run(NioClientBoss.java:42)
[junit] at 
org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)
[junit] at 
org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
[junit] at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[junit] at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-12-08 12:14:11,975 [myid:] - WARN  [New I/O boss 
#2727:ClientCnxnSocketNetty$ZKClientHandler@439] - Exception caught: [id: 
0x53f94162] EXCEPTION: java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:30197
[junit] java.net.ConnectException: Connection refused: 
127.0.0.1/127.0.0.1:30197
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.jboss.netty.channel.socket.nio.NioClientBoss.connect(NioClientBoss.java:152)
   

ZooKeeper-trunk-jdk8 - Build # 849 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper-trunk-jdk8/849/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 449473 lines...]
[junit] at java.lang.Thread.run(Thread.java:745)
[junit] 2016-12-08 12:01:29,755 [myid:] - INFO  [main:ZooKeeper@1313] - 
Session: 0x10172058b00 closed
[junit] 2016-12-08 12:01:29,755 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@82] - Memory used 166627
[junit] 2016-12-08 12:01:29,755 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@87] - Number of threads 1644
[junit] 2016-12-08 12:01:29,755 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down for 
session: 0x10172058b00
[junit] 2016-12-08 12:01:29,755 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@102] - FINISHED TEST METHOD 
testWatcherAutoResetWithLocal
[junit] 2016-12-08 12:01:29,755 [myid:] - INFO  [main:ClientBase@543] - 
tearDown starting
[junit] 2016-12-08 12:01:29,756 [myid:] - INFO  [main:ClientBase@513] - 
STOPPING server
[junit] 2016-12-08 12:01:29,756 [myid:] - INFO  
[main:NettyServerCnxnFactory@464] - shutdown called 0.0.0.0/0.0.0.0:16852
[junit] 2016-12-08 12:01:29,761 [myid:] - INFO  [main:ZooKeeperServer@534] 
- shutting down
[junit] 2016-12-08 12:01:29,762 [myid:] - ERROR [main:ZooKeeperServer@506] 
- ZKShutdownHandler is not registered, so ZooKeeper server won't take any 
action on ERROR or SHUTDOWN server state changes
[junit] 2016-12-08 12:01:29,762 [myid:] - INFO  
[main:SessionTrackerImpl@232] - Shutting down
[junit] 2016-12-08 12:01:29,762 [myid:] - INFO  
[main:PrepRequestProcessor@1009] - Shutting down
[junit] 2016-12-08 12:01:29,762 [myid:] - INFO  
[main:SyncRequestProcessor@191] - Shutting down
[junit] 2016-12-08 12:01:29,762 [myid:] - INFO  [ProcessThread(sid:0 
cport:16852)::PrepRequestProcessor@157] - PrepRequestProcessor exited loop!
[junit] 2016-12-08 12:01:29,762 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited!
[junit] 2016-12-08 12:01:29,763 [myid:] - INFO  
[main:FinalRequestProcessor@481] - shutdown of request processor complete
[junit] 2016-12-08 12:01:29,763 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean 
[org.apache.ZooKeeperService:name0=StandaloneServer_port16852,name1=InMemoryDataTree]
[junit] 2016-12-08 12:01:29,763 [myid:] - INFO  [main:MBeanRegistry@128] - 
Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port16852]
[junit] 2016-12-08 12:01:29,763 [myid:] - INFO  
[main:FourLetterWordMain@85] - connecting to 127.0.0.1 16852
[junit] 2016-12-08 12:01:29,764 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2016-12-08 12:01:29,771 [myid:] - INFO  [main:ClientBase@568] - 
fdcount after test is: 4831 at start it was 4835
[junit] 2016-12-08 12:01:29,771 [myid:] - INFO  [main:ZKTestCase$1@65] - 
SUCCEEDED testWatcherAutoResetWithLocal
[junit] 2016-12-08 12:01:29,771 [myid:] - INFO  [main:ZKTestCase$1@60] - 
FINISHED testWatcherAutoResetWithLocal
[junit] Tests run: 101, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 
604.038 sec, Thread: 3, Class: org.apache.zookeeper.test.NioNettySuiteTest
[junit] 2016-12-08 12:01:30,164 [myid:127.0.0.1:16729] - INFO  
[main-SendThread(127.0.0.1:16729):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:16729. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-12-08 12:01:30,164 [myid:127.0.0.1:16729] - WARN  
[main-SendThread(127.0.0.1:16729):ClientCnxn$SendThread@1235] - Session 
0x10172023404 for server 127.0.0.1/127.0.0.1:16729, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 
sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:717)
[junit] at 
org.apache.zookeeper.ClientCnxnSocketNIO.doTransport(ClientCnxnSocketNIO.java:357)
[junit] at 
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1214)
[junit] 2016-12-08 12:01:30,271 [myid:127.0.0.1:16732] - INFO  
[main-SendThread(127.0.0.1:16732):ClientCnxn$SendThread@1113] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:16732. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2016-12-08 12:01:30,271 [myid:127.0.0.1:16732] - WARN  
[main-SendThread(127.0.0.1:16732):ClientCnxn$SendThread@1235] - Session 
0x20172023528 for server 127.0.0.1/127.0.0.1:16732, unexpected error, 
closing socket connection and attempting reconnect
[junit] java.net.ConnectException: Connection refused
[junit] at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
[junit] at 

ZooKeeper_branch35_openjdk7 - Build # 324 - Still Failing

[Apache Jenkins Server]

See https://builds.apache.org/job/ZooKeeper_branch35_openjdk7/324/

###
## LAST 60 LINES OF THE CONSOLE 
###
Started by timer
[EnvInject] - Loading node environment variables.
Building remotely on H16 (ubuntu) in workspace 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_openjdk7
 > git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
 > git config remote.origin.url git://git.apache.org/zookeeper.git # timeout=10
Fetching upstream changes from git://git.apache.org/zookeeper.git
 > git --version # timeout=10
 > git -c core.askpass=true fetch --tags --progress 
 > git://git.apache.org/zookeeper.git +refs/heads/*:refs/remotes/origin/*
 > git rev-parse refs/remotes/origin/branch-3.5^{commit} # timeout=10
 > git rev-parse refs/remotes/origin/origin/branch-3.5^{commit} # timeout=10
Checking out Revision 3119a194ac0738b00a4e22095449ea4c4dbb8f31 
(refs/remotes/origin/branch-3.5)
 > git config core.sparsecheckout # timeout=10
 > git checkout -f 3119a194ac0738b00a4e22095449ea4c4dbb8f31
 > git rev-list 3119a194ac0738b00a4e22095449ea4c4dbb8f31 # timeout=10
No emails were triggered.
[ZooKeeper_branch35_openjdk7] $ /home/jenkins/tools/ant/latest/bin/ant 
-Dtest.output=yes -Dtest.junit.threads=8 -Dtest.junit.output.format=xml 
-Djavac.target=1.7 clean test-core-java
Error: JAVA_HOME is not defined correctly.
  We cannot execute /usr/lib/jvm/java-7-openjdk-amd64//bin/java
Build step 'Invoke Ant' marked build as failure
Recording test results
ERROR: Step ?Publish JUnit test result report? failed: No test report files 
were found. Configuration error?
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any



###
## FAILED TESTS (if any) 
##
No tests ran.

Re: reconfig APIs

[Jordan Zimmerman]

> I think people understand what alpha means.

With respect, the ZooKeeper team has used “alpha” in a novel way that is sowing 
considerable confusion. I wrote emails about this a while back. But, here 
again, is another case where the non-standard usage of “alpha” will cause 
confusion. To reiterate: someone who sees "3.5.2-alpha” will think that there 
will eventually be a “3.5.2-beta” and finally a “3.5.2” release version. But, 
with ZooKeeper there will never be a “3.5.2” release. In fact, the “-alpha” 
label is mis-located. The real version is “3.5.?-alpha1”, “3.5.?-alpha2”, etc. 
There’s an important implication here. If a ZooKeeper user who doesn’t follow 
the mailing lists, etc. sees “3.5.2-alpha” and “3.5.3-alpha” they will mentally 
see these as two different releases. What ZOOKEEPER-2014 has done is remove an 
existing API from what appears to be a released version 3.5.2 (which never 
really existed). This change violates semantic versioning. For external users, 
the version after “3.5.2” should be “4.x.x” as it has breaking changes.

> It's not about style, there were a number of concerns addressed in that
> patch.

The auth issues are very real ones. The issues in ZOOKEEPER-2014 can be 
addressed completely without moving the reconfig() methods to a new class. It 
may be useful to move APIs around for clarity, etc. but these breaking changes 
should be for a version that signals breaking changes - 4.x.x or something. 
i.e. moving the reconfig() APIs is orthogonal to the concerns of ZOOKEEPER-2014 
and should be a separate Jira issue.

> I think people understand what alpha means. There may be some short term
> impact for a few, but a significant benefit over the long term.

Again with respect - 3.5.0-alpha was made available in Maven Central August 
2014 - over 2 years ago. Regardless of the ZooKeeper team’s intent, this is NOT 
an alpha in users’ minds. This is a released library that is in production in 
major organizations. The ZooKeeper team should realize this and adjust their 
thinking about the “alpha” tag. For Apache Curator, we’re now put in a position 
where the reconfig() APIs have disappeared. In order to maintain our own 
internal semantic versioning we will have to consider a third branch of Curator 
(we currently have a ZooKeeper 3.4.x compatible version and a ZooKeeper 3.5.x 
compatible version). It would be awesome if we didn’t have to do this.

-Jordan

> On Dec 7, 2016, at 7:16 PM, Patrick Hunt  wrote:
> 
> It's not about style, there were a number of concerns addressed in that
> patch. We didn't take the change lightly, we've been discussing it over
> jira and the mailing list over the past two years.
> 
> I think people understand what alpha means. There may be some short term
> impact for a few, but a significant benefit over the long term.
> 
> Patrick
> 
> On Dec 7, 2016 9:24 AM, "Jordan Zimmerman" 
> wrote:
> 
>> I read through the issue and disagree about the decision to move the APIs
>> out. That was a stylistic choice that breaks client code. I realize that
>> 3.5.x has been advertised as an alpha but you must realize that most of the
>> world is using it in production. These APIs have now been published. This
>> will create a real headache for Curator which is why I’ve created
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642 <
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2642> - I hope we can
>> move these APIs back into ZooKeeper.java.
>> 
>> -Jordan
>> 
>>> On Dec 7, 2016, at 5:54 PM, Patrick Hunt  wrote:
>>> 
>>> It's discussed in more depth in the JIRA iirc, but basically;
>>> ZooKeeper.java provides client APIs, reconfig is an admiistrative API.
>>> 
>>> Patrick
>>> 
>>> On Wed, Dec 7, 2016 at 8:48 AM, Jordan Zimmerman <
>> jor...@jordanzimmerman.com
 wrote:
>>> 
 I understand the need to make the methods require proper auth but
>> there's
 no reason to move it to a different class that I can see. Am I missing
 something?
 
 
 Jordan Zimmerman
 
> On Dec 7, 2016, at 4:37 PM, Patrick Hunt  wrote:
> 
> This problem has been a long standing blocker issue for 3.5 and
 identified
> early on as something that would need to change. This has been one of
>> the
> reasons why 3.5 has stayed in alpha - because we allow non-backward
> compatible changes to new APIs in alpha and we knew we would have to
>> fix
> this. The description/comments of ZOOKEEPER-2014 does a good job
> documenting why this had to change.
> 
> Patrick
> 
> On Wed, Dec 7, 2016 at 3:18 AM, Jordan Zimmerman <
 jor...@jordanzimmerman.com
>> wrote:
> 
>> OK - I found the offending issue: ZOOKEEPER-2014
>> 
>> What is the benefit/logic of moving the reconfig() variants into a new
>> class? I can see if this was done from the start but you have now
>> broken
>> Curator in a