ZooKeeper_branch33_solaris - Build # 671 - Failure
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/671/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 104226 lines...] [junit] 2013-10-09 06:57:44,260 - INFO [main:ZooKeeperServer@154] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test6899297871980764186.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test6899297871980764186.junit.dir/version-2 [junit] 2013-10-09 06:57:44,261 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-09 06:57:44,263 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test6899297871980764186.junit.dir/version-2/snapshot.0 [junit] 2013-10-09 06:57:44,266 - INFO [main:FileTxnSnapLog@256] - Snapshotting: b [junit] 2013-10-09 06:57:44,268 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 06:57:44,269 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:35247 [junit] 2013-10-09 06:57:44,269 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:35247 [junit] 2013-10-09 06:57:44,271 - INFO [Thread-4:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2013-10-09 06:57:44,271 - INFO [Thread-4:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:35247 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 06:57:44,273 - INFO [main:ClientBase@408] - STOPPING server [junit] 2013-10-09 06:57:44,275 - INFO [SyncThread:0:SyncRequestProcessor@151] - SyncRequestProcessor exited! [junit] 2013-10-09 06:57:44,275 - INFO [ProcessThread:-1:PrepRequestProcessor@128] - PrepRequestProcessor exited loop! [junit] 2013-10-09 06:57:44,275 - INFO [main:FinalRequestProcessor@370] - shutdown of request processor complete [junit] 2013-10-09 06:57:44,277 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] ensureOnly:[] [junit] 2013-10-09 06:57:44,278 - INFO [main:ClientBase@401] - STARTING server [junit] 2013-10-09 06:57:44,279 - INFO [main:ZooKeeperServer@154] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test6899297871980764186.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test6899297871980764186.junit.dir/version-2 [junit] 2013-10-09 06:57:44,280 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-09 06:57:44,281 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test6899297871980764186.junit.dir/version-2/snapshot.b [junit] 2013-10-09 06:57:44,284 - INFO [main:FileTxnSnapLog@256] - Snapshotting: b [junit] 2013-10-09 06:57:44,285 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 06:57:44,286 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:35249 [junit] 2013-10-09 06:57:44,287 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:35249 [junit] 2013-10-09 06:57:44,288 - INFO [Thread-5:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2013-10-09 06:57:44,288 - INFO [Thread-5:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:35249 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 06:57:44,291 - INFO [main:Clie
[jira] [Updated] (ZOOKEEPER-1459) Standalone ZooKeeperServer is not closing the transaction log files on shutdown
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh R updated ZOOKEEPER-1459: Description: When shutdown the standalone ZK server, its only clearing the zkdatabase and not closing the transaction log streams. When tries to delete the temporary files in unit tests on windows, its failing. ZooKeeperServer.java {noformat} if (zkDb != null) { zkDb.clear(); } {noformat} Suggestion to close the zkDb as follows, this inturn will take care transaction logs: {noformat} if (zkDb != null) { zkDb.clear(); try { zkDb.close(); } catch (IOException ie) { LOG.warn("Error closing logs ", ie); } } {noformat} was: When shutdown the standalone ZK server, its only clearing the zkdatabase and not closing the transaction log streams. This will leaks the transaction log streams. ZooKeeperServer.java {noformat} if (zkDb != null) { zkDb.clear(); } {noformat} Suggestion to close the zkDb as follows, this inturn will take care transaction logs: {noformat} if (zkDb != null) { zkDb.clear(); try { zkDb.close(); } catch (IOException ie) { LOG.warn("Error closing logs ", ie); } } {noformat} > Standalone ZooKeeperServer is not closing the transaction log files on > shutdown > --- > > Key: ZOOKEEPER-1459 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1459 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.0 >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1459.patch, ZOOKEEPER-1459.patch, > ZOOKEEPER-1459.patch, ZOOKEEPER-1459.patch > > > When shutdown the standalone ZK server, its only clearing the zkdatabase and > not closing the transaction log streams. When tries to delete the temporary > files in unit tests on windows, its failing. > ZooKeeperServer.java > {noformat} > if (zkDb != null) { > zkDb.clear(); > } > {noformat} > Suggestion to close the zkDb as follows, this inturn will take care > transaction logs: > {noformat} > if (zkDb != null) { > zkDb.clear(); > try { > zkDb.close(); > } catch (IOException ie) { > LOG.warn("Error closing logs ", ie); > } > } > {noformat} -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1459) Standalone ZooKeeperServer is not closing the transaction log files on shutdown
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790101#comment-13790101 ] Rakesh R commented on ZOOKEEPER-1459: - [~fpj] exactly unit test case is failing in windows. I've modified the defect description and attached latest patch to fix the problem. Please see. > Standalone ZooKeeperServer is not closing the transaction log files on > shutdown > --- > > Key: ZOOKEEPER-1459 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1459 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.0 >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1459.patch, ZOOKEEPER-1459.patch, > ZOOKEEPER-1459.patch, ZOOKEEPER-1459.patch > > > When shutdown the standalone ZK server, its only clearing the zkdatabase and > not closing the transaction log streams. When tries to delete the temporary > files in unit tests on windows, its failing. > ZooKeeperServer.java > {noformat} > if (zkDb != null) { > zkDb.clear(); > } > {noformat} > Suggestion to close the zkDb as follows, this inturn will take care > transaction logs: > {noformat} > if (zkDb != null) { > zkDb.clear(); > try { > zkDb.close(); > } catch (IOException ie) { > LOG.warn("Error closing logs ", ie); > } > } > {noformat} -- This message was sent by Atlassian JIRA (v6.1#6144)
Success: ZOOKEEPER-1459 PreCommit Build #1667
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1459 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1667/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 253377 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607524/ZOOKEEPER-1459.patch [exec] against trunk revision 1530166. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified 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 1.3.9) 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-Build/1667//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1667//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1667//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] eab1168c59b1792dd989140b55734977abed8b3d logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 31 minutes 21 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1459 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1459) Standalone ZooKeeperServer is not closing the transaction log files on shutdown
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790123#comment-13790123 ] Hadoop QA commented on ZOOKEEPER-1459: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607524/ZOOKEEPER-1459.patch against trunk revision 1530166. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1667//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1667//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1667//console This message is automatically generated. > Standalone ZooKeeperServer is not closing the transaction log files on > shutdown > --- > > Key: ZOOKEEPER-1459 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1459 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.0 >Reporter: Rakesh R >Assignee: Rakesh R > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1459.patch, ZOOKEEPER-1459.patch, > ZOOKEEPER-1459.patch, ZOOKEEPER-1459.patch > > > When shutdown the standalone ZK server, its only clearing the zkdatabase and > not closing the transaction log streams. When tries to delete the temporary > files in unit tests on windows, its failing. > ZooKeeperServer.java > {noformat} > if (zkDb != null) { > zkDb.clear(); > } > {noformat} > Suggestion to close the zkDb as follows, this inturn will take care > transaction logs: > {noformat} > if (zkDb != null) { > zkDb.clear(); > try { > zkDb.close(); > } catch (IOException ie) { > LOG.warn("Error closing logs ", ie); > } > } > {noformat} -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1509) Please update documentation to reflect updated FreeBSD support.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790148#comment-13790148 ] Hadoop QA commented on ZOOKEEPER-1509: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12539307/ZOOKEEPER-1509.patch against trunk revision 1530166. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1668//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1668//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1668//console This message is automatically generated. > Please update documentation to reflect updated FreeBSD support. > --- > > Key: ZOOKEEPER-1509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1509 > Project: ZooKeeper > Issue Type: Task >Affects Versions: 3.4.6, 3.5.0 >Reporter: George Neville-Neil >Assignee: George Neville-Neil > Labels: newbie > Attachments: ZOOKEEPER-1509.patch > > > I noticed on this page: > http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html > that FreeBSD was listed as being supported only as a client due to a problem > with the JVM on FreeBSD. > As of Friday zookeeper is fully supported on FreeBSD, using openjdk version 7 > and I have created a port for it in our ports collection: > http://www.freshports.org/devel/zookeeper/ > The zookeeper port tracks the stable release at the moment and in the near > future to track the current release, as the plain zookeeper port tracks the > stable. > Please update your documentation to reflect this change in support. > Best, > George Neville-Neil > g...@freebsd.org -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1509 PreCommit Build #1668
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1509 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1668/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 284609 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12539307/ZOOKEEPER-1509.patch [exec] against trunk revision 1530166. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [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 1.3.9) 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-Build/1668//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1668//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1668//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] fb378696884573c40677ed892b0eb014ac4a4600 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 31 minutes 30 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1509 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Created] (ZOOKEEPER-1786) ZooKeeper data model documentation is incorrect
Niraj Tolia created ZOOKEEPER-1786: -- Summary: ZooKeeper data model documentation is incorrect Key: ZOOKEEPER-1786 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1786 Project: ZooKeeper Issue Type: Bug Components: documentation Affects Versions: 3.4.6 Reporter: Niraj Tolia Priority: Minor Fix For: 3.4.6 When I look at https://zookeeper.apache.org/doc/trunk/zookeeperProgrammers.html#ch_zkDataModel, I see two things that seem wrong in terms of restricted characters: * \uXFFFE - \uX (where X is a digit 1 - E) * \uF - \uF These definitions are invalid characters in Java and aren't reflected in PathUtils either (or PathUtilsTest). In fact the code in PathUtils states: {code:borderStyle=solid} } else if (c > '\u' && c <= '\u001f' || c >= '\u007f' && c <= '\u009F' || c >= '\ud800' && c <= '\uf8ff' || c >= '\ufff0' && c <= '\u') { reason = "invalid charater @" + i; break; } {code} Unless I am missing something, this simple patch should fix the documentation problem: {code} Index: src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml === --- src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml (revision 1530514) +++ src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml (working copy) @@ -139,8 +139,7 @@ The following characters are not allowed: \ud800 - uF8FF, -\uFFF0 - u, \uXFFFE - \uX (where X is a digit 1 - E), \uF - -\uF. +\uFFF0 - u. {code} -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1783) Distinguish initial configuration from first established configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790165#comment-13790165 ] Hadoop QA commented on ZOOKEEPER-1783: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607526/ZOOKEEPER-1783.patch against trunk revision 1530166. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1669//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1669//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1669//console This message is automatically generated. > Distinguish initial configuration from first established configuration > -- > > Key: ZOOKEEPER-1783 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1783.patch > > > We need a way to distinguish an initial config of a server and an initial > config of a running ensemble (before any reconfigs happen). Currently both > have version 0. > The version of a config increases with each reconfiguration, so the problem > is just with the initial config. -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1783 PreCommit Build #1669
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1669/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 892013 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607526/ZOOKEEPER-1783.patch [exec] against trunk revision 1530166. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified 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 1.3.9) 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 failed 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-Build/1669//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1669//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1669//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 2edf1ab13278695161c33b11acb310c939a0aa2e logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 42 minutes 12 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1783 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 2 tests failed. REGRESSION: org.apache.zookeeper.test.AsyncHammerTest.testObserversHammer Error Message: waiting for server up Stack Trace: junit.framework.AssertionFailedError: waiting for server up at org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:205) at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:113) at org.apache.zookeeper.test.AsyncHammerTest.setUp(AsyncHammerTest.java:52) at org.apache.zookeeper.test.AsyncHammerTest.testObserversHammer(AsyncHammerTest.java:203) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) REGRESSION: org.apache.zookeeper.test.ReadOnlyModeTest.testSeekForRwServer Error Message: Timeout occurred. Please note the time in the report does not reflect the time until the timeout. Stack Trace: junit.framework.AssertionFailedError: Timeout occurred. Please note the time in the report does not reflect the time until the timeout.
ZooKeeper-trunk-ibm6 - Build # 307 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk-ibm6/307/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 292749 lines...] [junit] 2013-10-09 09:09:19,215 [myid:] - INFO [main:ZooKeeperServer@422] - shutting down [junit] 2013-10-09 09:09:19,215 [myid:] - INFO [main:SessionTrackerImpl@180] - Shutting down [junit] 2013-10-09 09:09:19,215 [myid:] - INFO [main:PrepRequestProcessor@929] - Shutting down [junit] 2013-10-09 09:09:19,216 [myid:] - INFO [main:SyncRequestProcessor@190] - Shutting down [junit] 2013-10-09 09:09:19,216 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop! [junit] 2013-10-09 09:09:19,216 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2013-10-09 09:09:19,216 [myid:] - INFO [main:FinalRequestProcessor@427] - shutdown of request processor complete [junit] 2013-10-09 09:09:19,217 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 09:09:19,218 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-09 09:09:19,219 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-10-09 09:09:19,219 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/hudson/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test8238608194212831234.junit.dir/version-2 snapdir /home/hudson/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test8238608194212831234.junit.dir/version-2 [junit] 2013-10-09 09:09:19,220 [myid:] - INFO [main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 kB direct buffers. [junit] 2013-10-09 09:09:19,220 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-09 09:09:19,222 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/hudson/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test8238608194212831234.junit.dir/version-2/snapshot.b [junit] 2013-10-09 09:09:19,224 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to /home/hudson/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test8238608194212831234.junit.dir/version-2/snapshot.b [junit] 2013-10-09 09:09:19,226 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 09:09:19,226 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:46164 [junit] 2013-10-09 09:09:19,227 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from /127.0.0.1:46164 [junit] 2013-10-09 09:09:19,227 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output [junit] 2013-10-09 09:09:19,228 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client /127.0.0.1:46164 (no session established for client) [junit] 2013-10-09 09:09:19,228 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-09 09:09:19,231 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-09 09:09:19,231 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-09 09:09:19,231 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-09 09:09:19,232 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 09:09:19,232 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-09 09:09:19,232 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-09 09:09:19,288 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down [junit] 2013-10-09 09:09:19,288 [myid:] - INFO [main:ZooKeeper@777] - Session: 0x1419c7a3d36 closed [junit] 2013-10-09 09:09:19,289 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-10-09 09:09:19,289 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2013-10-09 09:09:19,289 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2013-10-09 09:09:19,289 [myid:] - INFO [NIOServerCxnFactory.SelectorThrea
ZooKeeper-trunk-solaris - Build # 695 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/695/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 199252 lines...] [junit] 2013-10-09 09:10:58,417 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2013-10-09 09:10:58,418 [myid:] - INFO [main:ZooKeeperServer@422] - shutting down [junit] 2013-10-09 09:10:58,418 [myid:] - INFO [main:SessionTrackerImpl@180] - Shutting down [junit] 2013-10-09 09:10:58,418 [myid:] - INFO [main:PrepRequestProcessor@929] - Shutting down [junit] 2013-10-09 09:10:58,419 [myid:] - INFO [main:SyncRequestProcessor@190] - Shutting down [junit] 2013-10-09 09:10:58,419 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop! [junit] 2013-10-09 09:10:58,419 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2013-10-09 09:10:58,419 [myid:] - INFO [main:FinalRequestProcessor@427] - shutdown of request processor complete [junit] 2013-10-09 09:10:58,420 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 09:10:58,420 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-09 09:10:58,421 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-10-09 09:10:58,421 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4718238081059251442.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4718238081059251442.junit.dir/version-2 [junit] 2013-10-09 09:10:58,422 [myid:] - INFO [main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 kB direct buffers. [junit] 2013-10-09 09:10:58,422 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-09 09:10:58,423 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4718238081059251442.junit.dir/version-2/snapshot.b [junit] 2013-10-09 09:10:58,425 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4718238081059251442.junit.dir/version-2/snapshot.b [junit] 2013-10-09 09:10:58,427 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 09:10:58,428 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:54206 [junit] 2013-10-09 09:10:58,429 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from /127.0.0.1:54206 [junit] 2013-10-09 09:10:58,429 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output [junit] 2013-10-09 09:10:58,429 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client /127.0.0.1:54206 (no session established for client) [junit] 2013-10-09 09:10:58,430 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-09 09:10:58,431 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-09 09:10:58,431 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-09 09:10:58,431 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-09 09:10:58,431 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 09:10:58,431 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-09 09:10:58,432 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-09 09:10:58,503 [myid:] - INFO [main:ZooKeeper@777] - Session: 0x1419c7bc19c closed [junit] 2013-10-09 09:10:58,503 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down [junit] 2013-10-09 09:10:58,503 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-10-09 09:10:58,504 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420]
ZooKeeper-3.4-WinVS2008_java - Build # 319 - Still Failing
See https://builds.apache.org/job/ZooKeeper-3.4-WinVS2008_java/319/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 193460 lines...] [junit] 2013-10-09 11:10:39,169 [myid:] - INFO [main:FinalRequestProcessor@415] - shutdown of request processor complete [junit] 2013-10-09 11:10:39,268 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 11:10:39,482 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@968] - Opening socket connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to authenticate using SASL (java.lang.SecurityException: Unable to locate a login configuration) [junit] 2013-10-09 11:10:40,267 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-09 11:10:40,268 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-10-09 11:10:40,268 [myid:] - INFO [main:ZooKeeperServer@162] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test2492858975536941634.junit.dir\version-2 snapdir f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test2492858975536941634.junit.dir\version-2 [junit] 2013-10-09 11:10:40,275 [myid:] - INFO [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-09 11:10:40,276 [myid:] - INFO [main:FileSnap@83] - Reading snapshot f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test2492858975536941634.junit.dir\version-2\snapshot.b [junit] 2013-10-09 11:10:40,279 [myid:] - INFO [main:FileTxnSnapLog@240] - Snapshotting: 0xb to f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test2492858975536941634.junit.dir\version-2\snapshot.b [junit] 2013-10-09 11:10:40,377 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 11:10:40,378 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:55478 [junit] 2013-10-09 11:10:40,378 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@817] - Processing stat command from /127.0.0.1:55478 [junit] 2013-10-09 11:10:40,378 [myid:] - INFO [Thread-5:NIOServerCnxn$StatCommand@653] - Stat command output [junit] 2013-10-09 11:10:40,472 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:55468 [junit] 2013-10-09 11:10:40,476 [myid:] - INFO [Thread-5:NIOServerCnxn@997] - Closed socket connection for client /127.0.0.1:55478 (no session established for client) [junit] 2013-10-09 11:10:40,472 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@849] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2013-10-09 11:10:40,476 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-09 11:10:40,477 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@863] - Client attempting to renew session 0x1419cb25ba8 at /127.0.0.1:55468 [junit] 2013-10-09 11:10:40,577 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@619] - Established session 0x1419cb25ba8 with negotiated timeout 3 for client /127.0.0.1:55468 [junit] 2013-10-09 11:10:40,577 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-09 11:10:40,577 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1228] - Session establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 0x1419cb25ba8, negotiated timeout = 3 [junit] 2013-10-09 11:10:40,577 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-09 11:10:40,577 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-09 11:10:40,578 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 11:10:40,578 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-09 11:10:40,578 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-09 11:10:40,579 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@476] - Processed session termination for sessionid: 0x1419cb25ba8 [junit] 2013-10-09 11:10:40,678 [myid:] - INFO [SyncThread:0:FileTxnLog@199] - Creating new log file: log.c [j
ZooKeeper_branch34_jdk7 - Build # 369 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch34_jdk7/369/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 217977 lines...] [junit] 2013-10-09 10:16:16,260 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-09 10:16:16,260 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 10:16:16,260 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-10-09 10:16:16,260 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - NIOServerCnxn factory exited run method [junit] 2013-10-09 10:16:16,260 [myid:] - INFO [main:ZooKeeperServer@443] - shutting down [junit] 2013-10-09 10:16:16,261 [myid:] - INFO [main:SessionTrackerImpl@225] - Shutting down [junit] 2013-10-09 10:16:16,261 [myid:] - INFO [main:PrepRequestProcessor@743] - Shutting down [junit] 2013-10-09 10:16:16,261 [myid:] - INFO [main:SyncRequestProcessor@190] - Shutting down [junit] 2013-10-09 10:16:16,261 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop! [junit] 2013-10-09 10:16:16,261 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2013-10-09 10:16:16,261 [myid:] - INFO [main:FinalRequestProcessor@415] - shutdown of request processor complete [junit] 2013-10-09 10:16:16,262 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 10:16:16,262 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-09 10:16:16,263 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-10-09 10:16:16,264 [myid:] - INFO [main:ZooKeeperServer@162] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test7510986478130578168.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test7510986478130578168.junit.dir/version-2 [junit] 2013-10-09 10:16:16,264 [myid:] - INFO [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-09 10:16:16,265 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test7510986478130578168.junit.dir/version-2/snapshot.b [junit] 2013-10-09 10:16:16,267 [myid:] - INFO [main:FileTxnSnapLog@240] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test7510986478130578168.junit.dir/version-2/snapshot.b [junit] 2013-10-09 10:16:16,268 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 10:16:16,269 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:57880 [junit] 2013-10-09 10:16:16,269 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@817] - Processing stat command from /127.0.0.1:57880 [junit] 2013-10-09 10:16:16,269 [myid:] - INFO [Thread-4:NIOServerCnxn$StatCommand@653] - Stat command output [junit] 2013-10-09 10:16:16,270 [myid:] - INFO [Thread-4:NIOServerCnxn@997] - Closed socket connection for client /127.0.0.1:57880 (no session established for client) [junit] 2013-10-09 10:16:16,270 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-09 10:16:16,271 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-09 10:16:16,271 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-09 10:16:16,271 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-09 10:16:16,272 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 10:16:16,272 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-09 10:16:16,272 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-09 10:16:16,346 [myid:] - INFO [main:ZooKeeper@684] - Session: 0x1419cb787b2 closed [junit] 2013-10-09 10:16:16,346 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@509] - EventThread shut down [junit] 2013-10-09 10:16:16,347 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-10-09 10:16:16,347 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnF
ZooKeeper-trunk-WinVS2008_java - Build # 567 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/567/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 250186 lines...] [junit] 2013-10-09 11:23:02,840 [myid:] - INFO [main:FileSnap@83] - Reading snapshot f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test4491328918703903298.junit.dir\version-2\snapshot.b [junit] 2013-10-09 11:23:02,917 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1008] - Opening socket connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to authenticate using SASL (java.lang.SecurityException: Unable to locate a login configuration) [junit] 2013-10-09 11:23:02,938 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@882] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2013-10-09 11:23:02,939 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:57349 [junit] 2013-10-09 11:23:03,001 [myid:] - INFO [SessionTracker:SessionTrackerImpl@135] - SessionTrackerImpl exited loop! [junit] 2013-10-09 11:23:03,000 [myid:] - INFO [SessionTracker:SessionTrackerImpl@135] - SessionTrackerImpl exited loop! [junit] 2013-10-09 11:23:02,940 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test4491328918703903298.junit.dir\version-2\snapshot.b [junit] 2013-10-09 11:23:03,039 [myid:] - WARN [NIOWorkerThread-1:NIOServerCnxn@365] - Exception causing close of session 0x0: ZooKeeperServer not running [junit] 2013-10-09 11:23:03,041 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-09 11:23:03,139 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client /127.0.0.1:57349 (no session established for client) [junit] 2013-10-09 11:23:03,140 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1124] - Unable to read additional data from server sessionid 0x1419cbdaf62, likely server has closed socket, closing socket connection and attempting reconnect [junit] 2013-10-09 11:23:03,140 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:57350 [junit] 2013-10-09 11:23:03,240 [myid:] - INFO [NIOWorkerThread-2:NIOServerCnxn@828] - Processing stat command from /127.0.0.1:57350 [junit] 2013-10-09 11:23:03,240 [myid:] - INFO [NIOWorkerThread-2:NIOServerCnxn$StatCommand@677] - Stat command output [junit] 2013-10-09 11:23:03,241 [myid:] - INFO [NIOWorkerThread-2:NIOServerCnxn@999] - Closed socket connection for client /127.0.0.1:57350 (no session established for client) [junit] 2013-10-09 11:23:03,241 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-09 11:23:03,341 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-09 11:23:03,341 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-09 11:23:03,342 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-09 11:23:03,342 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-09 11:23:03,342 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-09 11:23:03,441 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-09 11:23:04,731 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1008] - Opening socket connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to authenticate using SASL (java.lang.SecurityException: Unable to locate a login configuration) [junit] 2013-10-09 11:23:04,734 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@882] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2013-10-09 11:23:04,735 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:57351 [junit] 2013-10-09 11:23:04,749 [myid:] - INFO [NIOWorkerThread-3:ZooKeeperServer@846] - Client attempting to renew session 0x1419cbdaf62 at /127.0.0.1:57351 [junit] 2013-10-09 11:23:04,751 [myid:] - INFO [NIOWorkerThread-3:ZooKeeperServer@590] - Established session 0x1419cbdaf62 with negotiated timeout 3 for cl
[jira] [Commented] (ZOOKEEPER-1485) client xid overflow is not handled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790263#comment-13790263 ] Jacky007 commented on ZOOKEEPER-1485: - We fixed this by use 31-bit only. > client xid overflow is not handled > -- > > Key: ZOOKEEPER-1485 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1485 > Project: ZooKeeper > Issue Type: Bug > Components: c client, java client >Affects Versions: 3.4.3, 3.3.5 >Reporter: Michi Mutsuzaki >Assignee: Bruce Gao > > Both Java and C clients use signed 32-bit int as XIDs. XIDs are assumed to be > non-negative, and zookeeper uses some negative values as special XIDs (e.g. > -2 for ping, -4 for auth). However, neither Java nor C client ensures the > XIDs it generates are non-negative, and the server doesn't reject negative > XIDs. > Pat had some suggestions on how to fix this: > - (bin-compat) Expire the session when the client sends a negative XID. > - (bin-incompat) In addition to expiring the session, use 64-bit int for XID > so that overflow will practically never happen. > --Michi -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1485) client xid overflow is not handled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790264#comment-13790264 ] Jacky007 commented on ZOOKEEPER-1485: - As I said,it may core or hang after about ten days on one of our internal services. > client xid overflow is not handled > -- > > Key: ZOOKEEPER-1485 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1485 > Project: ZooKeeper > Issue Type: Bug > Components: c client, java client >Affects Versions: 3.4.3, 3.3.5 >Reporter: Michi Mutsuzaki >Assignee: Bruce Gao > > Both Java and C clients use signed 32-bit int as XIDs. XIDs are assumed to be > non-negative, and zookeeper uses some negative values as special XIDs (e.g. > -2 for ping, -4 for auth). However, neither Java nor C client ensures the > XIDs it generates are non-negative, and the server doesn't reject negative > XIDs. > Pat had some suggestions on how to fix this: > - (bin-compat) Expire the session when the client sends a negative XID. > - (bin-incompat) In addition to expiring the session, use 64-bit int for XID > so that overflow will practically never happen. > --Michi -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1777) Missing ephemeral nodes in one of the members of the ensemble
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790305#comment-13790305 ] Germán Blanco commented on ZOOKEEPER-1777: -- Could anybody help me see if this might work? - The hash check of each transaction is stored together with the rest of session data. - This hash check is sent together with the transaction response to the clients. - Clients store the last transaction's hash check. - Clients send the last transaction's hash check when connecting to the ensemble. 1 - The problem is detected when a server with wrong data tries to connect to the leader. 2 - Big WARN in the log. 3 - An snapshot is sent to this server, including the session data with the transactions' hash checks. 4 - If a client attempts to connect using a wrong transaction hash check, the session for that client is closed. Another WARN in the log. > Missing ephemeral nodes in one of the members of the ensemble > - > > Key: ZOOKEEPER-1777 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1777 > Project: ZooKeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.4.5 > Environment: Linux, Java 1.7 >Reporter: Germán Blanco >Assignee: Germán Blanco >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > Attachments: logs_trunk.tar.gz, snaps.tar, ZOOKEEPER-1777-3.4.patch, > ZOOKEEPER-1777.patch, ZOOKEEPER-1777.patch, ZOOKEEPER-1777.tar.gz > > > In a 3-servers ensemble, one of the followers doesn't see part of the > ephemeral nodes that are present in the leader and the other follower. > The 8 missing nodes in "the follower that is not ok" were created in the end > of epoch 1, the ensemble is running in epoch 2. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1740) Zookeeper 3.3.4 loses ephemeral nodes under stress
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790309#comment-13790309 ] Germán Blanco commented on ZOOKEEPER-1740: -- Shouldn't this be a Blocker? > Zookeeper 3.3.4 loses ephemeral nodes under stress > -- > > Key: ZOOKEEPER-1740 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1740 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.3.4 >Reporter: Neha Narkhede >Assignee: Neha Narkhede >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > > The current behavior of zookeeper for ephemeral nodes is that session > expiration and ephemeral node deletion is not an atomic operation. > The side-effect of the above zookeeper behavior in Kafka, for certain corner > cases, is that ephemeral nodes can be lost even if the session is not > expired. The sequence of events that can lead to lossy ephemeral nodes is as > follows - > 1. The session expires on the client, it assumes the ephemeral nodes are > deleted, so it establishes a new session with zookeeper and tries to > re-create the ephemeral nodes. > 2. However, when it tries to re-create the ephemeral node,zookeeper throws > back a NodeExists error code. Now this is legitimate during a session > disconnect event (since zkclient automatically retries the > operation and raises a NodeExists error). Also by design, Kafka server > doesn't have multiple zookeeper clients create the same ephemeral node, so > Kafka server assumes the NodeExists is normal. > 3. However, after a few seconds zookeeper deletes that ephemeral node. So > from the client's perspective, even though the client has a new valid > session, its ephemeral node is gone. > This behavior is triggered due to very long fsync operations on the zookeeper > leader. When the leader wakes up from such a long fsync operation, it has > several sessions to expire. And the time between the session expiration and > the ephemeral node deletion is magnified. Between these 2 operations, a > zookeeper client can issue a ephemeral node creation operation, that could've > appeared to have succeeded, but the leader later deletes the ephemeral node > leading to permanent ephemeral node loss from the client's perspective. > Thread from zookeeper mailing list: > http://zookeeper.markmail.org/search/?q=Zookeeper+3.3.4#query:Zookeeper%203.3.4%20date%3A201307%20+page:1+mid:zma242a2qgp6gxvx+state:results > The way to reproduce this behavior is as follows - > 1. Bring up a zookeeper 3.3.4 cluster and create several sessions with > ephemeral ndoes on it using zkclient. Make sure the session expiration > callback is implemented and it re-registers the ephemeral node. > 2. Run the following script on the zookeeper leader - > while true > do >kill -STOP $1 >sleep 8 >kill -CONT $1 >sleep 60 > done > 3. Run another script to check for existence of ephemeral nodes. > This script shows that zookeeper loses the ephemeral nodes and the clients > still have a valid session. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1740) Zookeeper 3.3.4 loses ephemeral nodes under stress
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790313#comment-13790313 ] Flavio Junqueira commented on ZOOKEEPER-1740: - This issue has been created for the 3.3 branch and there is no further evidence that it happens in the 3.4 branch. In fact, Neha was not able to reproduce it in the 3.4 branch according to the e-mail thread posted above. I'm actually thinking about closing this issue, since users should actually consider upgrading to the 3.4 branch. Short answer is that I don't think this is a blocker. > Zookeeper 3.3.4 loses ephemeral nodes under stress > -- > > Key: ZOOKEEPER-1740 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1740 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.3.4 >Reporter: Neha Narkhede >Assignee: Neha Narkhede >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > > The current behavior of zookeeper for ephemeral nodes is that session > expiration and ephemeral node deletion is not an atomic operation. > The side-effect of the above zookeeper behavior in Kafka, for certain corner > cases, is that ephemeral nodes can be lost even if the session is not > expired. The sequence of events that can lead to lossy ephemeral nodes is as > follows - > 1. The session expires on the client, it assumes the ephemeral nodes are > deleted, so it establishes a new session with zookeeper and tries to > re-create the ephemeral nodes. > 2. However, when it tries to re-create the ephemeral node,zookeeper throws > back a NodeExists error code. Now this is legitimate during a session > disconnect event (since zkclient automatically retries the > operation and raises a NodeExists error). Also by design, Kafka server > doesn't have multiple zookeeper clients create the same ephemeral node, so > Kafka server assumes the NodeExists is normal. > 3. However, after a few seconds zookeeper deletes that ephemeral node. So > from the client's perspective, even though the client has a new valid > session, its ephemeral node is gone. > This behavior is triggered due to very long fsync operations on the zookeeper > leader. When the leader wakes up from such a long fsync operation, it has > several sessions to expire. And the time between the session expiration and > the ephemeral node deletion is magnified. Between these 2 operations, a > zookeeper client can issue a ephemeral node creation operation, that could've > appeared to have succeeded, but the leader later deletes the ephemeral node > leading to permanent ephemeral node loss from the client's perspective. > Thread from zookeeper mailing list: > http://zookeeper.markmail.org/search/?q=Zookeeper+3.3.4#query:Zookeeper%203.3.4%20date%3A201307%20+page:1+mid:zma242a2qgp6gxvx+state:results > The way to reproduce this behavior is as follows - > 1. Bring up a zookeeper 3.3.4 cluster and create several sessions with > ephemeral ndoes on it using zkclient. Make sure the session expiration > callback is implemented and it re-registers the ephemeral node. > 2. Run the following script on the zookeeper leader - > while true > do >kill -STOP $1 >sleep 8 >kill -CONT $1 >sleep 60 > done > 3. Run another script to check for existence of ephemeral nodes. > This script shows that zookeeper loses the ephemeral nodes and the clients > still have a valid session. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790569#comment-13790569 ] Flavio Junqueira commented on ZOOKEEPER-1147: - This looks great, +1. > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 observers. Majority of these clients are > read only - ie they do not do any updates or create ephemeral nodes. > In ZooKeeper today, the client creates a session and the session creation is > handled like any other update. In the above use case, the session create/drop > workload can easily overwhelm an ensemble. The following is a proposal for a > "local session", to support a larger number of connections. > 1. The idea is to introduce a new type of session - "local" session. A > "local" session doesn't have a full functionality of a normal session. > 2. Local sessions cannot create ephemeral nodes. > 3. Once a local session is lost, you cannot re-establish it using the > session-id/password. The session and its watches are gone for good. > 4. When a local session connects, the session info is only maintained > on the zookeeper server (in this case, an observer) that it is connected to. > The leader is not aware of the creation of such a session and there is no > state written to disk. > 5. The pings and expiration is handled by the server that the session > is connected to. > With the above changes, we can make ZooKeeper scale to a much larger number > of clients without making the core ensemble a bottleneck. > In terms of API, there are two options that are being considered > 1. Let the client specify at the connect time which kind of session do they > want. > 2. All sessions connect as local sessions and automatically get promoted to > global sessions when they do an operation that requires a global session > (e.g. creating an ephemeral node) > Chubby took the approach of lazily promoting all sessions to global, but I > don't think that would work in our case, where we want to keep sessions which > never create ephemeral nodes as always local. Option 2 would make it more > broadly usable but option 1 would be easier to implement. > We are thinking of implementing option 1 as the first cut. There would be a > client flag, IsLocalSession (much like the current readOnly flag) that would > be used to determine whether to create a local session or a global session. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1509) Please update documentation to reflect updated FreeBSD support.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Neville-Neil updated ZOOKEEPER-1509: --- Attachment: signature.asc Thank you! Best, George > Please update documentation to reflect updated FreeBSD support. > --- > > Key: ZOOKEEPER-1509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1509 > Project: ZooKeeper > Issue Type: Task >Affects Versions: 3.4.6, 3.5.0 >Reporter: George Neville-Neil >Assignee: George Neville-Neil > Labels: newbie > Fix For: 3.5.0 > > Attachments: signature.asc, ZOOKEEPER-1509.patch > > > I noticed on this page: > http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html > that FreeBSD was listed as being supported only as a client due to a problem > with the JVM on FreeBSD. > As of Friday zookeeper is fully supported on FreeBSD, using openjdk version 7 > and I have created a port for it in our ports collection: > http://www.freshports.org/devel/zookeeper/ > The zookeeper port tracks the stable release at the moment and in the near > future to track the current release, as the plain zookeeper port tracks the > stable. > Please update your documentation to reflect this change in support. > Best, > George Neville-Neil > g...@freebsd.org -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790623#comment-13790623 ] Patrick Hunt commented on ZOOKEEPER-1742: - Seems there is an issue as well for Ubuntu (I'm on 13.04), however I'm only seeing it on trunk and not branch 34 {noformat} make check make zktest-st zktest-mt make[1]: Entering directory `/home/phunt/dev/svn/svn-zookeeper/src/c' g++ -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -DUSE_STATIC_LIB -DZKSERVER_CMD="\"./tests/zkServer.sh\"" -DZOO_IPV6_ENABLED -g -O2 -MT zktest_st-TestReconfigServer.o -MD -MP -MF .deps/zktest_st-TestReconfigServer.Tpo -c -o zktest_st-TestReconfigServer.o `test -f 'tests/TestReconfigServer.cc' || echo './'`tests/TestReconfigServer.cc tests/TestReconfigServer.cc: In member function ‘bool TestReconfigServer::waitForConnected(zhandle_t*, uint32_t)’: tests/TestReconfigServer.cc:128:16: error: ‘sleep’ was not declared in this scope make[1]: *** [zktest_st-TestReconfigServer.o] Error 1 make[1]: Leaving directory `/home/phunt/dev/svn/svn-zookeeper/src/c' make: *** [check-am] Error 2 {noformat} I have {noformat} g++ --version g++ (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. {noformat} > "make check" doesn't work on macos > -- > > Key: ZOOKEEPER-1742 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > Project: ZooKeeper > Issue Type: Bug >Reporter: Flavio Junqueira >Assignee: Benjamin Reed > Fix For: 3.4.6, 3.5.0 > > > There are two problems I have spotted when running "make check" with the C > client. First, it complains that the sleep call is not defined in two test > files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1785) Small fix in zkServer.sh to support new configuration format
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1785: Component/s: scripts > Small fix in zkServer.sh to support new configuration format > > > Key: ZOOKEEPER-1785 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1785 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer >Priority: Minor > Fix For: 3.5.0 > > Attachments: zkServersh.patch > > > The problem can be reproduced by running a server with the following type of > config file: > dataDir=/Users/shralex/zookeeper-test/zookeeper1 > syncLimit=2 > initLimit=5 > tickTime=2000 > server.1=localhost:2721:2731:participant;2791 > server.2=localhost:2722:2732:participant;2792 > and then trying to do "zkServer.sh status" > Here I specified the servers using the new config format but still used the > static config file and didn't include the "clientPort" key. > zkServer.sh already supports the new configuration format, but expects server > spec to appear in the dynamic config file if it uses the new format. > So in the example above it will not find the client port. > The current logic for executing something like 'zkServer.sh status' is: > 1. Look for clientPort keyword in the static config file > 2. Look for the client port in the server spec in the dynamic config file > The attached patch adds an intermediate step: > 1'. Look for the client port in the server spec in the static config file -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790630#comment-13790630 ] Patrick Hunt commented on ZOOKEEPER-1742: - Should we split these out? How do you want to handle it? The failing test is a blocker for 3.4.6 IMO. > "make check" doesn't work on macos > -- > > Key: ZOOKEEPER-1742 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > Project: ZooKeeper > Issue Type: Bug >Reporter: Flavio Junqueira >Assignee: Benjamin Reed > Fix For: 3.4.6, 3.5.0 > > > There are two problems I have spotted when running "make check" with the C > client. First, it complains that the sleep call is not defined in two test > files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790629#comment-13790629 ] Patrick Hunt commented on ZOOKEEPER-1742: - Also I'm seeing this fail consistently in branch34 {noformat} Zookeeper_watchers::testDefaultSessionWatcher1zktest-mt: tests/ZKMocks.cc:271: SyncedBoolCondition DeliverWatchersWrapper::isDelivered() const: Assertion `i<1000' failed. {noformat} > "make check" doesn't work on macos > -- > > Key: ZOOKEEPER-1742 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > Project: ZooKeeper > Issue Type: Bug >Reporter: Flavio Junqueira >Assignee: Benjamin Reed > Fix For: 3.4.6, 3.5.0 > > > There are two problems I have spotted when running "make check" with the C > client. First, it complains that the sleep call is not defined in two test > files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ZOOKEEPER-1787) Add support enabling local session in rolling upgrade
Thawan Kooburat created ZOOKEEPER-1787: -- Summary: Add support enabling local session in rolling upgrade Key: ZOOKEEPER-1787 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1787 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.5.0 Reporter: Thawan Kooburat Priority: Minor Currently, local session need to be enable by stopping the entire ensemble. If a rolling upgrade is used, all write request from a local session will fail with session move until the local session is enabled on the leader. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1787) Add support enabling local session in rolling upgrade
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790692#comment-13790692 ] Raul Gutierrez Segales commented on ZOOKEEPER-1787: --- [~thawan]: would you like me to rebase the patch I proposed in ZOOKEEPER-1147 (with the comments you suggested) or do you have a better/different approach? > Add support enabling local session in rolling upgrade > - > > Key: ZOOKEEPER-1787 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1787 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Thawan Kooburat >Priority: Minor > > Currently, local session need to be enable by stopping the entire ensemble. > If a rolling upgrade is used, all write request from a local session will > fail with session move until the local session is enabled on the leader. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1787) Add support enabling local session in rolling upgrade
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1787?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790718#comment-13790718 ] Thawan Kooburat commented on ZOOKEEPER-1787: Your original patch is to add 4lw comment to disable session validation on the leader right? If you could try my approach, I think the patch should be much smaller. > Add support enabling local session in rolling upgrade > - > > Key: ZOOKEEPER-1787 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1787 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Thawan Kooburat >Priority: Minor > > Currently, local session need to be enable by stopping the entire ensemble. > If a rolling upgrade is used, all write request from a local session will > fail with session move until the local session is enabled on the leader. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ZOOKEEPER-1788) Support clientID field on connection requests
Raul Gutierrez Segales created ZOOKEEPER-1788: - Summary: Support clientID field on connection requests Key: ZOOKEEPER-1788 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1788 Project: ZooKeeper Issue Type: Improvement Reporter: Raul Gutierrez Segales Priority: Minor I suspect it's very common for deployments to have a wide variety of client libraries (different versions/languages) connecting to a given cluster. It would be handy to have a way to identify clients via a clientID (akin to HTTP's User-Agent header). This could be implemented in ZooKeeperServer#processConnectRequest [1] and be fully backwards compatible. The clientID could then be kept with the corresponding ServerCnxn instance and be used for better logging (or stats expose through 4-letter commands). The corresponding client side change would be to expose API to set the clientID on each connection handler (and by default it could be something like "zk java $version", "zk c $version", etc). Thoughts? [1] https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java#L797 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790823#comment-13790823 ] Thawan Kooburat commented on ZOOKEEPER-1147: Committed to trunk. Thanks a lot everyone. > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 observers. Majority of these clients are > read only - ie they do not do any updates or create ephemeral nodes. > In ZooKeeper today, the client creates a session and the session creation is > handled like any other update. In the above use case, the session create/drop > workload can easily overwhelm an ensemble. The following is a proposal for a > "local session", to support a larger number of connections. > 1. The idea is to introduce a new type of session - "local" session. A > "local" session doesn't have a full functionality of a normal session. > 2. Local sessions cannot create ephemeral nodes. > 3. Once a local session is lost, you cannot re-establish it using the > session-id/password. The session and its watches are gone for good. > 4. When a local session connects, the session info is only maintained > on the zookeeper server (in this case, an observer) that it is connected to. > The leader is not aware of the creation of such a session and there is no > state written to disk. > 5. The pings and expiration is handled by the server that the session > is connected to. > With the above changes, we can make ZooKeeper scale to a much larger number > of clients without making the core ensemble a bottleneck. > In terms of API, there are two options that are being considered > 1. Let the client specify at the connect time which kind of session do they > want. > 2. All sessions connect as local sessions and automatically get promoted to > global sessions when they do an operation that requires a global session > (e.g. creating an ephemeral node) > Chubby took the approach of lazily promoting all sessions to global, but I > don't think that would work in our case, where we want to keep sessions which > never create ephemeral nodes as always local. Option 2 would make it more > broadly usable but option 1 would be easier to implement. > We are thinking of implementing option 1 as the first cut. There would be a > client flag, IsLocalSession (much like the current readOnly flag) that would > be used to determine whether to create a local session or a global session. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790871#comment-13790871 ] Flavio Junqueira commented on ZOOKEEPER-1147: - Committed revision: 1530781 > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 observers. Majority of these clients are > read only - ie they do not do any updates or create ephemeral nodes. > In ZooKeeper today, the client creates a session and the session creation is > handled like any other update. In the above use case, the session create/drop > workload can easily overwhelm an ensemble. The following is a proposal for a > "local session", to support a larger number of connections. > 1. The idea is to introduce a new type of session - "local" session. A > "local" session doesn't have a full functionality of a normal session. > 2. Local sessions cannot create ephemeral nodes. > 3. Once a local session is lost, you cannot re-establish it using the > session-id/password. The session and its watches are gone for good. > 4. When a local session connects, the session info is only maintained > on the zookeeper server (in this case, an observer) that it is connected to. > The leader is not aware of the creation of such a session and there is no > state written to disk. > 5. The pings and expiration is handled by the server that the session > is connected to. > With the above changes, we can make ZooKeeper scale to a much larger number > of clients without making the core ensemble a bottleneck. > In terms of API, there are two options that are being considered > 1. Let the client specify at the connect time which kind of session do they > want. > 2. All sessions connect as local sessions and automatically get promoted to > global sessions when they do an operation that requires a global session > (e.g. creating an ephemeral node) > Chubby took the approach of lazily promoting all sessions to global, but I > don't think that would work in our case, where we want to keep sessions which > never create ephemeral nodes as always local. Option 2 would make it more > broadly usable but option 1 would be easier to implement. > We are thinking of implementing option 1 as the first cut. There would be a > client flag, IsLocalSession (much like the current readOnly flag) that would > be used to determine whether to create a local session or a global session. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1627) Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Arnoud Glimmerveen updated ZOOKEEPER-1627: -- Attachment: ZOOKEEPER-1627-trunk.patch I re-created the patch based on the current trunk. This patch adds the {{org.apache.zookeeper.common}} package to Export-Package OSGi manifest header (both the source jar and the bin-jar), making it visible to other bundles in an OSGi environment. This patch can also be applied to the 3.4 branch. > Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers > - > > Key: ZOOKEEPER-1627 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1627 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.5 > Environment: Java: 1.6.0_31 > OSGi environment: Karaf 2.3.0 >Reporter: Arnoud Glimmerveen >Assignee: Arnoud Glimmerveen > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1627.patch, ZOOKEEPER-1627-trunk.patch > > > The utilities contained in the org.apache.zookeeper.common package are not > part of the exported packages in an OSGi environment, thus making them not > available to other bundles using ZooKeeper. > Propose to add the org.apache.zookeeper.common package to the Export-Package > MANIFEST header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790913#comment-13790913 ] Patrick Hunt commented on ZOOKEEPER-1147: - Kudos! Great feature addition. > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 observers. Majority of these clients are > read only - ie they do not do any updates or create ephemeral nodes. > In ZooKeeper today, the client creates a session and the session creation is > handled like any other update. In the above use case, the session create/drop > workload can easily overwhelm an ensemble. The following is a proposal for a > "local session", to support a larger number of connections. > 1. The idea is to introduce a new type of session - "local" session. A > "local" session doesn't have a full functionality of a normal session. > 2. Local sessions cannot create ephemeral nodes. > 3. Once a local session is lost, you cannot re-establish it using the > session-id/password. The session and its watches are gone for good. > 4. When a local session connects, the session info is only maintained > on the zookeeper server (in this case, an observer) that it is connected to. > The leader is not aware of the creation of such a session and there is no > state written to disk. > 5. The pings and expiration is handled by the server that the session > is connected to. > With the above changes, we can make ZooKeeper scale to a much larger number > of clients without making the core ensemble a bottleneck. > In terms of API, there are two options that are being considered > 1. Let the client specify at the connect time which kind of session do they > want. > 2. All sessions connect as local sessions and automatically get promoted to > global sessions when they do an operation that requires a global session > (e.g. creating an ephemeral node) > Chubby took the approach of lazily promoting all sessions to global, but I > don't think that would work in our case, where we want to keep sessions which > never create ephemeral nodes as always local. Option 2 would make it more > broadly usable but option 1 would be easier to implement. > We are thinking of implementing option 1 as the first cut. There would be a > client flag, IsLocalSession (much like the current readOnly flag) that would > be used to determine whether to create a local session or a global session. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-1627) Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-1627. - Resolution: Fixed Release Note: Committed to 3.4.6 and trunk. Thanks Arnoud! Hadoop Flags: Reviewed > Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers > - > > Key: ZOOKEEPER-1627 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1627 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.5 > Environment: Java: 1.6.0_31 > OSGi environment: Karaf 2.3.0 >Reporter: Arnoud Glimmerveen >Assignee: Arnoud Glimmerveen > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1627.patch, ZOOKEEPER-1627-trunk.patch > > > The utilities contained in the org.apache.zookeeper.common package are not > part of the exported packages in an OSGi environment, thus making them not > available to other bundles using ZooKeeper. > Propose to add the org.apache.zookeeper.common package to the Export-Package > MANIFEST header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1627) Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790920#comment-13790920 ] Patrick Hunt commented on ZOOKEEPER-1627: - Committed to 3.4.6 and trunk. Thanks Arnoud! > Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers > - > > Key: ZOOKEEPER-1627 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1627 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.5 > Environment: Java: 1.6.0_31 > OSGi environment: Karaf 2.3.0 >Reporter: Arnoud Glimmerveen >Assignee: Arnoud Glimmerveen > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1627.patch, ZOOKEEPER-1627-trunk.patch > > > The utilities contained in the org.apache.zookeeper.common package are not > part of the exported packages in an OSGi environment, thus making them not > available to other bundles using ZooKeeper. > Propose to add the org.apache.zookeeper.common package to the Export-Package > MANIFEST header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1499: Attachment: ZOOKEEPER-1499-ver1.java > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790922#comment-13790922 ] Alexander Shraer commented on ZOOKEEPER-1499: - thanks Ben. I made a slight change to the patch. > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1627) Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1627: Release Note: (was: Committed to 3.4.6 and trunk. Thanks Arnoud!) > Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers > - > > Key: ZOOKEEPER-1627 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1627 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.5 > Environment: Java: 1.6.0_31 > OSGi environment: Karaf 2.3.0 >Reporter: Arnoud Glimmerveen >Assignee: Arnoud Glimmerveen > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1627.patch, ZOOKEEPER-1627-trunk.patch > > > The utilities contained in the org.apache.zookeeper.common package are not > part of the exported packages in an OSGi environment, thus making them not > available to other bundles using ZooKeeper. > Propose to add the org.apache.zookeeper.common package to the Export-Package > MANIFEST header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1558) Leader should not snapshot uncommitted state
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790929#comment-13790929 ] Flavio Junqueira commented on ZOOKEEPER-1558: - [~thawan], could you please chime in here? > Leader should not snapshot uncommitted state > > > Key: ZOOKEEPER-1558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1558 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum >Affects Versions: 3.4.6 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, > ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch > > > Leader currently takes a snapshot when it calls loadData in the beginning of > the lead() method. The loaded data, however, may contain uncommitted state. -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1499 PreCommit Build #1670
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1670/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 299610 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607672/ZOOKEEPER-1499-ver1.java [exec] against trunk revision 1530809. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [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 1.3.9) 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 failed 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-Build/1670//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1670//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1670//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 85aab413c97e88a40a75f9d28f450eea551f11b4 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 2 Total time: 28 minutes 44 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1499 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. REGRESSION: org.apache.zookeeper.test.ReconfigTest.testQuorumSystemChange Error Message: Address already in use Stack Trace: java.net.BindException: Address already in use at sun.nio.ch.Net.bind(Native Method) at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:126) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59) at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52) at org.apache.zookeeper.server.NIOServerCnxnFactory.configure(NIOServerCnxnFactory.java:684) at org.apache.zookeeper.server.ServerCnxnFactory.createFactory(ServerCnxnFactory.java:127) at org.apache.zookeeper.server.quorum.QuorumPeer.(QuorumPeer.java:735) at org.apache.zookeeper.test.QuorumUtil.start(QuorumUtil.java:202) at org.apache.zookeeper.test.QuorumUtil.restart(QuorumUtil.java:213) at org.apache.zookeeper.test.ReconfigTest.testQuorumSystemChange(ReconfigTest.java:673) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Comment Edited] (ZOOKEEPER-1667) Watch event isn't handled correctly when a client reestablish to a server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790957#comment-13790957 ] Flavio Junqueira edited comment on ZOOKEEPER-1667 at 10/9/13 10:51 PM: --- [~fanster.z], do you think you can generate the documentation for this? was (Author: fpj): @jacky007, do you think you can generate the documentation for this? > Watch event isn't handled correctly when a client reestablish to a server > - > > Key: ZOOKEEPER-1667 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1667 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.3.6, 3.4.5 >Reporter: Jacky007 >Assignee: Jacky007 >Priority: Blocker > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1667.patch, ZOOKEEPER-1667-r34.patch > > > When a client reestablish to a server, it will send the watches which have > not been triggered. But the code in DataTree does not handle it correctly. > It is obvious, we just do not notice it :) > scenario: > 1) Client a set a data watch on /d, then disconnect, client b delete /d and > create it again. When client a reestablish to zk, it will receive a > NodeCreated rather than a NodeDataChanged. > 2) Client a set a exists watch on /e(not exist), then disconnect, client b > create /e. When client a reestablish to zk, it will receive a NodeDataChanged > rather than a NodeCreated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1667) Watch event isn't handled correctly when a client reestablish to a server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790957#comment-13790957 ] Flavio Junqueira commented on ZOOKEEPER-1667: - @jacky007, do you think you can generate the documentation for this? > Watch event isn't handled correctly when a client reestablish to a server > - > > Key: ZOOKEEPER-1667 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1667 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.3.6, 3.4.5 >Reporter: Jacky007 >Assignee: Jacky007 >Priority: Blocker > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1667.patch, ZOOKEEPER-1667-r34.patch > > > When a client reestablish to a server, it will send the watches which have > not been triggered. But the code in DataTree does not handle it correctly. > It is obvious, we just do not notice it :) > scenario: > 1) Client a set a data watch on /d, then disconnect, client b delete /d and > create it again. When client a reestablish to zk, it will receive a > NodeCreated rather than a NodeDataChanged. > 2) Client a set a exists watch on /e(not exist), then disconnect, client b > create /e. When client a reestablish to zk, it will receive a NodeDataChanged > rather than a NodeCreated. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790955#comment-13790955 ] Hadoop QA commented on ZOOKEEPER-1499: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607672/ZOOKEEPER-1499-ver1.java against trunk revision 1530809. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1670//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1670//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1670//console This message is automatically generated. > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1499: Attachment: ZOOKEEPER-1499-ver2.java > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-1304) [IGNORE THIS --- MOVING TO BOOKKEEPER JIRA] publish and subscribe methods get ServiceDownException even when the hubs, bookies, and zookeepers are running
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-1304. - Resolution: Duplicate > [IGNORE THIS --- MOVING TO BOOKKEEPER JIRA] publish and subscribe methods get > ServiceDownException even when the hubs, bookies, and zookeepers are running > -- > > Key: ZOOKEEPER-1304 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1304 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.5.0 > Environment: CentOS 5.5 for all servers and workstations (however > zookeeper, bookies, and hubs are all built in Ubuntu 11); > OpenJDK Runtime Environment (IcedTea6 1.9.10) (rhel-1.23.1.9.10.el5_7-i386); > OpenJDK Client VM (build 19.0-b09, mixed mode); >Reporter: Daniel Kim > Original Estimate: 336h > Remaining Estimate: 336h > > **[Sorry. I don't know how to delete an issue that is already submitted. I > just learned of the Bookkeeper jira, and I will submit this issue there > instead. You can all ignore this issue.] > Since I couldn't finish building all hedwig components in CentOS, I built it > successfully in Ubuntu, then I deployed it to CentOS (no ubuntu image in my > company's cloud). I configured zookeeper, bookies and hubs as they were > described in the documentations. First, I copied TestPubSubClient.java's > publish and subscribe tests into my own test code. I also had to create > another object that extends ClientConfiguration. I named it "HedwigConf", and > overwrote getDefaultServerHedwigSocketAddress() method because the server was > not on the same machine as the workstation. I targetted the right host and > publish seemed to work. However, it throws me ServiceDownException for > publish sometimes. I checked the logs of the hubs. They seem to have > connected ok with the bookies. There was no error or warning there. However, > the problem seemed to exist in bookies and zookeeper. This was found in the > zookeeper log: "Got user-level KeeperException when processing > sessionid:0x--- type:create cxid:0x5 zxid:0x29 txntype:-1 reqpath:n/a > Error Path:/hedwig/standalone/topics Error:KeeperErrorCode = NoNode for > /hedwig/standalone/topics". Normally this znode path is created > automatically. Also, some bookies complained this: "WARN [NIOServerFactory] > org.apache.bookkeeper.proto.NIOServerFactory - Exception in server socket > loop: /0:0:0:0:0:0:0:0 > java.lang.NullPointerException". For some reason, this problem comes and > goes. Sometimes everything just works and the new topic is saved in a new > znode, and the message is saved in bookie(s). I spent hours trying to > recreate this yesterday, but I couldn't. Now it is back again. Subscribe > seems to have the similar issue. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-903) Create a testing jar with useful classes from ZK test source
[ https://issues.apache.org/jira/browse/ZOOKEEPER-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-903: --- Fix Version/s: (was: 3.5.0) > Create a testing jar with useful classes from ZK test source > > > Key: ZOOKEEPER-903 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-903 > Project: ZooKeeper > Issue Type: Improvement > Components: tests >Reporter: Camille Fournier > > From mailing list: > -Original Message- > From: Benjamin Reed > Sent: Monday, October 18, 2010 11:12 AM > To: zookeeper-u...@hadoop.apache.org > Subject: Re: Testing zookeeper outside the source distribution? > we should be exposing those classes and releasing them as a testing > jar. do you want to open up a jira to track this issue? > ben > On 10/18/2010 05:17 AM, Anthony Urso wrote: > > Anyone have any pointers on how to test against ZK outside of the > > source distribution? All the fun classes (e.g. ClientBase) do not make > > it into the ZK release jar. > > > > Right now I am manually running a ZK node for the unit tests to > > connect to prior to running my test, but I would rather have something > > that ant could reliably > > automate starting and stopping for CI. > > > > Thanks, > > Anthony -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-903) Create a testing jar with useful classes from ZK test source
[ https://issues.apache.org/jira/browse/ZOOKEEPER-903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-903. Resolution: Implemented At some point we started doing this. The Apache Nexus repository has the test jars available for downstream users. > Create a testing jar with useful classes from ZK test source > > > Key: ZOOKEEPER-903 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-903 > Project: ZooKeeper > Issue Type: Improvement > Components: tests >Reporter: Camille Fournier > Fix For: 3.5.0 > > > From mailing list: > -Original Message- > From: Benjamin Reed > Sent: Monday, October 18, 2010 11:12 AM > To: zookeeper-u...@hadoop.apache.org > Subject: Re: Testing zookeeper outside the source distribution? > we should be exposing those classes and releasing them as a testing > jar. do you want to open up a jira to track this issue? > ben > On 10/18/2010 05:17 AM, Anthony Urso wrote: > > Anyone have any pointers on how to test against ZK outside of the > > source distribution? All the fun classes (e.g. ClientBase) do not make > > it into the ZK release jar. > > > > Right now I am manually running a ZK node for the unit tests to > > connect to prior to running my test, but I would rather have something > > that ant could reliably > > automate starting and stopping for CI. > > > > Thanks, > > Anthony -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-883) Idle cluster increasingly consumes CPU resources
[ https://issues.apache.org/jira/browse/ZOOKEEPER-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-883. Resolution: Implemented Sounds like this was resolved with ZOOKEEPER-880. Please reopen if it happens again. Thanks Lars. > Idle cluster increasingly consumes CPU resources > > > Key: ZOOKEEPER-883 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-883 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.3.1 >Reporter: Lars George > Attachments: Archive.zip > > > Monitoring the ZooKeeper nodes by polling the various ports using Nagios' > open port checks seems to cause a substantial raise of CPU being used by the > ZooKeeper daemons. Over the course of a week an idle cluster grew from a > baseline 2% to >10% CPU usage. Attached is a stack dump and logs showing the > occupied threads. At the end the daemon starts failing on "too many open > files" errors as all handles are used up. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791049#comment-13791049 ] Hadoop QA commented on ZOOKEEPER-1499: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607695/ZOOKEEPER-1499-ver2.java against trunk revision 1530809. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1671//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1671//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1671//console This message is automatically generated. > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
Success: ZOOKEEPER-1499 PreCommit Build #1671
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1671/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 288982 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607695/ZOOKEEPER-1499-ver2.java [exec] against trunk revision 1530809. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified 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 1.3.9) 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-Build/1671//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1671//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1671//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] c765d881527d6755f1c09a87a98a0442a298d7b2 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 33 minutes 28 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1499 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791138#comment-13791138 ] Benjamin Reed commented on ZOOKEEPER-1499: -- shouldn't you test using 0.0.0.0 in the test? > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
Re: [jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
i've been looking into the --wrap issue. the linker on osx just doesn't support it, and the functionality is pretty magical. i think we should just disable the tests that use them on osx On Wed, Oct 9, 2013 at 10:18 AM, Patrick Hunt (JIRA) wrote: > > [ > https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790630#comment-13790630] > > Patrick Hunt commented on ZOOKEEPER-1742: > - > > Should we split these out? How do you want to handle it? The failing test > is a blocker for 3.4.6 IMO. > > > "make check" doesn't work on macos > > -- > > > > Key: ZOOKEEPER-1742 > > URL: > https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > > Project: ZooKeeper > > Issue Type: Bug > >Reporter: Flavio Junqueira > >Assignee: Benjamin Reed > > Fix For: 3.4.6, 3.5.0 > > > > > > There are two problems I have spotted when running "make check" with the > C client. First, it complains that the sleep call is not defined in two > test files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. > > > > -- > This message was sent by Atlassian JIRA > (v6.1#6144) >
[jira] [Commented] (ZOOKEEPER-1558) Leader should not snapshot uncommitted state
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791169#comment-13791169 ] Thawan Kooburat commented on ZOOKEEPER-1558: Again, my concern is that the current solution would cause leader to be blocked taking the snapshot before starting to send ping to quorum members. If the snapshot taking time is larger than syncLimit, the quorum will tear down. You can simply simulate this situation by adding sleep which is longer that syncLimit into the new code where takeSnaphot() is called. If we agree that this is any issue, a simple fix is to create a method that take snapshot asynchronously (spin up a thread on demand similar to SyncRequestProcessor). Some refactoring and additional locking may be needed as well in order to do this cleanly. > Leader should not snapshot uncommitted state > > > Key: ZOOKEEPER-1558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1558 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum >Affects Versions: 3.4.6 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, > ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch > > > Leader currently takes a snapshot when it calls loadData in the beginning of > the lead() method. The loaded data, however, may contain uncommitted state. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1558) Leader should not snapshot uncommitted state
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thawan Kooburat updated ZOOKEEPER-1558: --- Attachment: ZOOKEEPER-1558.patch Update a patch to make it apply cleanly with 3.4 branch > Leader should not snapshot uncommitted state > > > Key: ZOOKEEPER-1558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1558 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum >Affects Versions: 3.4.6 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, > ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch > > > Leader currently takes a snapshot when it calls loadData in the beginning of > the lead() method. The loaded data, however, may contain uncommitted state. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1499: Attachment: ZOOKEEPER-1499-ver3.patch > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java, ZOOKEEPER-1499-ver3.patch > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1499 PreCommit Build #1672
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1672/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 292728 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607742/ZOOKEEPER-1499-ver3.patch [exec] against trunk revision 1530809. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified 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 1.3.9) 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 failed 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-Build/1672//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1672//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1672//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 1ca0cec850509652d2d011624203fe9804b27bf7 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 29 minutes 37 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1499 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. REGRESSION: org.apache.zookeeper.test.ReconfigTest.testQuorumSystemChange Error Message: client could not connect to reestablished quorum: giving up after 30+ seconds. Stack Trace: junit.framework.AssertionFailedError: client could not connect to reestablished quorum: giving up after 30+ seconds. at org.apache.zookeeper.test.ReconfigTest.reconfig(ReconfigTest.java:83) at org.apache.zookeeper.test.ReconfigTest.testQuorumSystemChange(ReconfigTest.java:665) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Commented] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791230#comment-13791230 ] Hadoop QA commented on ZOOKEEPER-1499: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607742/ZOOKEEPER-1499-ver3.patch against trunk revision 1530809. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1672//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1672//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1672//console This message is automatically generated. > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java, ZOOKEEPER-1499-ver3.patch > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791232#comment-13791232 ] Germán Blanco commented on ZOOKEEPER-1742: -- I think I could fix the "ld -wrap" option issue in Mac OSX. There is a proposal here: https://discussions.apple.com/thread/617779?start=0&tstart=0 I have already tried this in Utils.h, and it works for external functions (those that are not defined in the zookeeper library): {noformat} #define DECLARE_WRAPPER(ret,sym,sig) \ typedef ret (*fptr_##sym) sig; extern "C" ret sym sig #define CALL_REAL(sym,params) \ (*((fptr_##sym)dlsym(RTLD_NEXT, "sym"))) params {noformat} For the functions in the zookeeper library that are wrapped, the easiest solution for me would be to use a different version of the zookeeper library for the tests, changing the name of these functions. > "make check" doesn't work on macos > -- > > Key: ZOOKEEPER-1742 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > Project: ZooKeeper > Issue Type: Bug >Reporter: Flavio Junqueira >Assignee: Benjamin Reed > Fix For: 3.4.6, 3.5.0 > > > There are two problems I have spotted when running "make check" with the C > client. First, it complains that the sleep call is not defined in two test > files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1499: Attachment: (was: ZOOKEEPER-1499-ver3.patch) > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java, ZOOKEEPER-1499-ver3.patch > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1499: Attachment: ZOOKEEPER-1499-ver3.patch > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java, ZOOKEEPER-1499-ver3.patch > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)