ZooKeeper_branch33_solaris - Build # 671 - Failure

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Rakesh R (JIRA)

 [ 
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

2013-10-09 Thread Rakesh R (JIRA)

[ 
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Hadoop QA (JIRA)

[ 
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.

2013-10-09 Thread Hadoop QA (JIRA)

[ 
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Niraj Tolia (JIRA)
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

2013-10-09 Thread Hadoop QA (JIRA)

[ 
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Jacky007 (JIRA)

[ 
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

2013-10-09 Thread Jacky007 (JIRA)

[ 
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

2013-10-09 Thread JIRA

[ 
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

2013-10-09 Thread JIRA

[ 
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

2013-10-09 Thread Flavio Junqueira (JIRA)

[ 
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

2013-10-09 Thread Flavio Junqueira (JIRA)

[ 
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.

2013-10-09 Thread George Neville-Neil (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

[ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

[ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

[ 
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

2013-10-09 Thread Thawan Kooburat (JIRA)
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

2013-10-09 Thread Raul Gutierrez Segales (JIRA)

[ 
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

2013-10-09 Thread Thawan Kooburat (JIRA)

[ 
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

2013-10-09 Thread Raul Gutierrez Segales (JIRA)
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

2013-10-09 Thread Thawan Kooburat (JIRA)

[ 
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

2013-10-09 Thread Flavio Junqueira (JIRA)

[ 
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

2013-10-09 Thread Arnoud Glimmerveen (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

[ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

[ 
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

2013-10-09 Thread Alexander Shraer (JIRA)

 [ 
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

2013-10-09 Thread Alexander Shraer (JIRA)

[ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Flavio Junqueira (JIRA)

[ 
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Flavio Junqueira (JIRA)

[ 
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

2013-10-09 Thread Flavio Junqueira (JIRA)

[ 
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

2013-10-09 Thread Hadoop QA (JIRA)

[ 
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

2013-10-09 Thread Alexander Shraer (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Patrick Hunt (JIRA)

 [ 
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

2013-10-09 Thread Hadoop QA (JIRA)

[ 
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Benjamin Reed (JIRA)

[ 
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

2013-10-09 Thread Benjamin Reed
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

2013-10-09 Thread Thawan Kooburat (JIRA)

[ 
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

2013-10-09 Thread Thawan Kooburat (JIRA)

 [ 
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

2013-10-09 Thread Alexander Shraer (JIRA)

 [ 
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

2013-10-09 Thread Apache Jenkins Server
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

2013-10-09 Thread Hadoop QA (JIRA)

[ 
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

2013-10-09 Thread JIRA

[ 
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

2013-10-09 Thread Alexander Shraer (JIRA)

 [ 
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

2013-10-09 Thread Alexander Shraer (JIRA)

 [ 
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)