date:20140916

See https://builds.apache.org/job/ZooKeeper-trunk-ibm6/617/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 352738 lines...]
[junit] 2014-09-16 09:32:50,322 [myid:] - INFO  [main:JMXEnv@142] - 
ensureOnly:[]
[junit] 2014-09-16 09:32:50,324 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2014-09-16 09:32:50,325 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2014-09-16 09:32:50,325 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 32 worker threads, and 64 
kB direct buffers.
[junit] 2014-09-16 09:32:50,326 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2014-09-16 09:32:50,327 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2014-09-16 09:32:50,327 [myid:] - INFO  [main:ZooKeeperServer@781] 
- minSessionTimeout set to 6000
[junit] 2014-09-16 09:32:50,327 [myid:] - INFO  [main:ZooKeeperServer@790] 
- maxSessionTimeout set to 6
[junit] 2014-09-16 09:32:50,328 [myid:] - INFO  [main:ZooKeeperServer@152] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7800476914686786272.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7800476914686786272.junit.dir/version-2
[junit] 2014-09-16 09:32:50,329 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7800476914686786272.junit.dir/version-2/snapshot.b
[junit] 2014-09-16 09:32:50,332 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test7800476914686786272.junit.dir/version-2/snapshot.b
[junit] 2014-09-16 09:32:50,335 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-09-16 09:32:50,335 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:43693
[junit] 2014-09-16 09:32:50,336 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from 
/127.0.0.1:43693
[junit] 2014-09-16 09:32:50,337 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output
[junit] 2014-09-16 09:32:50,337 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client 
/127.0.0.1:43693 (no session established for client)
[junit] 2014-09-16 09:32:50,338 [myid:] - INFO  [main:JMXEnv@224] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2014-09-16 09:32:50,341 [myid:] - INFO  [main:JMXEnv@241] - 
expect:InMemoryDataTree
[junit] 2014-09-16 09:32:50,341 [myid:] - INFO  [main:JMXEnv@245] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2014-09-16 09:32:50,341 [myid:] - INFO  [main:JMXEnv@241] - 
expect:StandaloneServer_port
[junit] 2014-09-16 09:32:50,342 [myid:] - INFO  [main:JMXEnv@245] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-09-16 09:32:50,342 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 4995
[junit] 2014-09-16 09:32:50,342 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 40
[junit] 2014-09-16 09:32:50,343 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota
[junit] 2014-09-16 09:32:50,343 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2014-09-16 09:32:50,372 [myid:] - INFO  [main:ZooKeeper@968] - 
Session: 0x1487dceadef closed
[junit] 2014-09-16 09:32:50,372 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down
[junit] 2014-09-16 09:32:50,373 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2014-09-16 09:32:50,373 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2014-09-16 09:32:50,373 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2014-09-16 09:32:50,373 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2014-09-16 09:32:50,373 [myid:] - INFO

[jira] [Commented] (ZOOKEEPER-2026) Startup order in ServerCnxnFactory-ies is wrong


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135203#comment-14135203
 ] 

Rakesh R commented on ZOOKEEPER-2026:
-

Can someone help to review this changes and get a +1 for the proposed 
patch/fix. Thanks!. I feel this will give improvement in build testcases.

 Startup order in ServerCnxnFactory-ies is wrong
 ---

 Key: ZOOKEEPER-2026
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2026
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.6, 3.5.0
Reporter: Stevo Slavic
Priority: Minor
 Fix For: 3.4.7, 3.5.1

 Attachments: ZOOKEEPER-2026.patch, ZOOKEEPER-2026.patch


 {{NIOServerCnxnFactory}} and {{NettyServerCnxnFactory}} {{startup}} method 
 implementations are binding {{ZooKeeperServer}} too late, so in 
 {{ZooKeeperServer}} in its startup can fail to register appropriate JMX MBean.
 See 
 [this|http://mail-archives.apache.org/mod_mbox/zookeeper-user/201409.mbox/%3CCAAUywg9-ad3oWfqRWahB9PyBEbg6%2Bd%3DDyj5PAUU7A%3Dm9wRncaw%40mail.gmail.com%3E]
  post on ZK user mailing list for more details.



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

[jira] [Commented] (ZOOKEEPER-2026) Startup order in ServerCnxnFactory-ies is wrong

2014-09-16 Thread Stevo Slavic (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135218#comment-14135218
 ] 

Stevo Slavic commented on ZOOKEEPER-2026:
-

+1 (non-binding)

Is there a ticket to resolve failing tests, to make the build stable?

 Startup order in ServerCnxnFactory-ies is wrong
 ---

 Key: ZOOKEEPER-2026
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2026
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.6, 3.5.0
Reporter: Stevo Slavic
Priority: Minor
 Fix For: 3.4.7, 3.5.1

 Attachments: ZOOKEEPER-2026.patch, ZOOKEEPER-2026.patch


 {{NIOServerCnxnFactory}} and {{NettyServerCnxnFactory}} {{startup}} method 
 implementations are binding {{ZooKeeperServer}} too late, so in 
 {{ZooKeeperServer}} in its startup can fail to register appropriate JMX MBean.
 See 
 [this|http://mail-archives.apache.org/mod_mbox/zookeeper-user/201409.mbox/%3CCAAUywg9-ad3oWfqRWahB9PyBEbg6%2Bd%3DDyj5PAUU7A%3Dm9wRncaw%40mail.gmail.com%3E]
  post on ZK user mailing list for more details.



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

ZooKeeper_branch34_jdk7 - Build # 646 - Still Failing

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 183111 lines...]
[junit] 2014-09-16 10:04:59,259 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2014-09-16 10:04:59,260 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - 
NIOServerCnxn factory exited run method
[junit] 2014-09-16 10:04:59,264 [myid:] - INFO  [main:ZooKeeperServer@441] 
- shutting down
[junit] 2014-09-16 10:04:59,264 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down
[junit] 2014-09-16 10:04:59,264 [myid:] - INFO  
[main:PrepRequestProcessor@761] - Shutting down
[junit] 2014-09-16 10:04:59,265 [myid:] - INFO  
[main:SyncRequestProcessor@209] - Shutting down
[junit] 2014-09-16 10:04:59,265 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@187] - SyncRequestProcessor exited!
[junit] 2014-09-16 10:04:59,265 [myid:] - INFO  
[main:FinalRequestProcessor@415] - shutdown of request processor complete
[junit] 2014-09-16 10:04:59,266 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-09-16 10:04:59,266 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2014-09-16 10:04:59,267 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2014-09-16 10:04:59,268 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2014-09-16 10:04:59,268 [myid:] - INFO  
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2014-09-16 10:04:59,268 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2014-09-16 10:04:59,269 [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/test6513075663421522129.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper_branch34_jdk7/branch-3.4/build/test/tmp/test6513075663421522129.junit.dir/version-2
[junit] 2014-09-16 10:04:59,269 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop!
[junit] 2014-09-16 10:04:59,288 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-09-16 10:04:59,292 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - 
Accepted socket connection from /127.0.0.1:37827
[junit] 2014-09-16 10:04:59,292 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:37827
[junit] 2014-09-16 10:04:59,300 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2014-09-16 10:04:59,300 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1007] - Closed socket connection for client 
/127.0.0.1:37827 (no session established for client)
[junit] 2014-09-16 10:04:59,304 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2014-09-16 10:04:59,306 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2014-09-16 10:04:59,306 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2014-09-16 10:04:59,306 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2014-09-16 10:04:59,307 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-09-16 10:04:59,307 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 10483
[junit] 2014-09-16 10:04:59,307 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 20
[junit] 2014-09-16 10:04:59,307 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota
[junit] 2014-09-16 10:04:59,308 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2014-09-16 10:04:59,321 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x1487dec1c24 closed
[junit] 2014-09-16 10:04:59,321 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2014-09-16 10:04:59,321 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@512] - EventThread shut down
[junit] 2014-09-16 10:04:59,322 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - 
NIOServerCnxn factory exited run method
[junit] 2014-09-16 10:04:59,324 [myid:] - INFO  [main:ZooKeeperServer@441] 
- shutting down
[junit] 2014-09-16 10:04:59,324 [myid:] - INFO  
[main:SessionTrackerImpl@225] - Shutting down

[jira] [Commented] (ZOOKEEPER-2026) Startup order in ServerCnxnFactory-ies is wrong


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135241#comment-14135241
 ] 

Rakesh R commented on ZOOKEEPER-2026:
-

AFAIK, there are few JMX bean related issues observed when analysing 
ZOOKEEPER-1833 (its an umbrella JIRA used for fixing build issues).

 Startup order in ServerCnxnFactory-ies is wrong
 ---

 Key: ZOOKEEPER-2026
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2026
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.6, 3.5.0
Reporter: Stevo Slavic
Priority: Minor
 Fix For: 3.4.7, 3.5.1

 Attachments: ZOOKEEPER-2026.patch, ZOOKEEPER-2026.patch


 {{NIOServerCnxnFactory}} and {{NettyServerCnxnFactory}} {{startup}} method 
 implementations are binding {{ZooKeeperServer}} too late, so in 
 {{ZooKeeperServer}} in its startup can fail to register appropriate JMX MBean.
 See 
 [this|http://mail-archives.apache.org/mod_mbox/zookeeper-user/201409.mbox/%3CCAAUywg9-ad3oWfqRWahB9PyBEbg6%2Bd%3DDyj5PAUU7A%3Dm9wRncaw%40mail.gmail.com%3E]
  post on ZK user mailing list for more details.



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

[jira] [Commented] (ZOOKEEPER-1833) fix windows build

2014-09-16 Thread Stevo Slavic (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135268#comment-14135268
 ] 

Stevo Slavic commented on ZOOKEEPER-1833:
-

Is story summary/title still correct? It seems to me that some of the test 
issues/fixes were not Windows platform specific.

 fix windows build
 -

 Key: ZOOKEEPER-1833
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1833
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.5
Reporter: Michi Mutsuzaki
Assignee: Michi Mutsuzaki
Priority: Blocker
 Fix For: 3.4.7

 Attachments: LeaderSessionTrackerTest-output.txt, 
 TEST-org.apache.zookeeper.test.QuorumTest.zip, ZOOKEEPER-1833-b3.4.patch, 
 ZOOKEEPER-1833.patch, ZOOKEEPER-1833.patch


 A bunch of 3.4 tests are failing on windows.
 {noformat}
 [junit] 2013-12-06 08:40:59,692 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testEarlyLeaderAbandonment
 [junit] 2013-12-06 08:41:10,472 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testHighestZxidJoinLate
 [junit] 2013-12-06 08:45:31,085 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testUpdatingEpoch
 [junit] 2013-12-06 08:55:34,630 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testObserversHammer
 [junit] 2013-12-06 08:55:59,889 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncExistsFailure_NoNode
 [junit] 2013-12-06 08:56:00,571 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetACL
 [junit] 2013-12-06 08:56:02,626 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenEmpty
 [junit] 2013-12-06 08:56:03,491 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenSingle
 [junit] 2013-12-06 08:56:11,276 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenTwo
 [junit] 2013-12-06 08:56:13,878 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenFailure_NoNode
 [junit] 2013-12-06 08:56:16,294 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Empty
 [junit] 2013-12-06 08:56:18,622 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Single
 [junit] 2013-12-06 08:56:21,224 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Two
 [junit] 2013-12-06 08:56:23,738 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Failure_NoNode
 [junit] 2013-12-06 08:56:26,058 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetData
 [junit] 2013-12-06 08:56:28,482 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetDataFailure_NoNode
 [junit] 2013-12-06 08:57:35,527 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testStartupFailureCreate
 [junit] 2013-12-06 08:57:38,645 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testStartupFailureSet
 [junit] 2013-12-06 08:57:41,261 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testStartupFailureSnapshot
 [junit] 2013-12-06 08:59:22,222 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientWithWatcherObj
 [junit] 2013-12-06 09:00:05,592 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientCleanup
 [junit] 2013-12-06 09:01:24,113 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testBindByAddress
 [junit] 2013-12-06 09:02:14,123 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientwithoutWatcherObj
 [junit] 2013-12-06 09:05:56,461 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testZeroWeightQuorum
 [junit] 2013-12-06 09:08:18,747 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testResyncByDiffAfterFollowerCrashes
 [junit] 2013-12-06 09:09:42,271 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testFourLetterWords
 [junit] 2013-12-06 09:14:03,770 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testLE
 [junit] 2013-12-06 09:46:30,002 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testHierarchicalQuorum
 [junit] 2013-12-06 09:50:26,912 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testHammerBasic
 [junit] 2013-12-06 09:51:07,604 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testQuotaWithQuorum
 [junit] 2013-12-06 09:52:41,515 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testNull
 [junit] 2013-12-06 09:53:22,648 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testDeleteWithChildren
 [junit] 2013-12-06 09:56:49,061 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientwithoutWatcherObj
 [junit] 2013-12-06 09:58:27,705 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testGetView
 [junit] 2013-12-06 09:59:07,856 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testViewContains
 [junit] 2013-12-06 10:01:31,418 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testSessionMoved
 [junit] 2013-12-06 10:04:50,542

[jira] [Commented] (ZOOKEEPER-1833) fix windows build


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135277#comment-14135277
 ] 

Flavio Junqueira commented on ZOOKEEPER-1833:
-

Sure, they might not be windows specific, but they are manifesting on windows. 
Tests seem to pass on linux fine, otherwise.

 fix windows build
 -

 Key: ZOOKEEPER-1833
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1833
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.5
Reporter: Michi Mutsuzaki
Assignee: Michi Mutsuzaki
Priority: Blocker
 Fix For: 3.4.7

 Attachments: LeaderSessionTrackerTest-output.txt, 
 TEST-org.apache.zookeeper.test.QuorumTest.zip, ZOOKEEPER-1833-b3.4.patch, 
 ZOOKEEPER-1833.patch, ZOOKEEPER-1833.patch


 A bunch of 3.4 tests are failing on windows.
 {noformat}
 [junit] 2013-12-06 08:40:59,692 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testEarlyLeaderAbandonment
 [junit] 2013-12-06 08:41:10,472 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testHighestZxidJoinLate
 [junit] 2013-12-06 08:45:31,085 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testUpdatingEpoch
 [junit] 2013-12-06 08:55:34,630 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testObserversHammer
 [junit] 2013-12-06 08:55:59,889 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncExistsFailure_NoNode
 [junit] 2013-12-06 08:56:00,571 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetACL
 [junit] 2013-12-06 08:56:02,626 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenEmpty
 [junit] 2013-12-06 08:56:03,491 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenSingle
 [junit] 2013-12-06 08:56:11,276 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenTwo
 [junit] 2013-12-06 08:56:13,878 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildrenFailure_NoNode
 [junit] 2013-12-06 08:56:16,294 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Empty
 [junit] 2013-12-06 08:56:18,622 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Single
 [junit] 2013-12-06 08:56:21,224 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Two
 [junit] 2013-12-06 08:56:23,738 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetChildren2Failure_NoNode
 [junit] 2013-12-06 08:56:26,058 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetData
 [junit] 2013-12-06 08:56:28,482 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testAsyncGetDataFailure_NoNode
 [junit] 2013-12-06 08:57:35,527 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testStartupFailureCreate
 [junit] 2013-12-06 08:57:38,645 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testStartupFailureSet
 [junit] 2013-12-06 08:57:41,261 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testStartupFailureSnapshot
 [junit] 2013-12-06 08:59:22,222 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientWithWatcherObj
 [junit] 2013-12-06 09:00:05,592 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientCleanup
 [junit] 2013-12-06 09:01:24,113 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testBindByAddress
 [junit] 2013-12-06 09:02:14,123 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientwithoutWatcherObj
 [junit] 2013-12-06 09:05:56,461 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testZeroWeightQuorum
 [junit] 2013-12-06 09:08:18,747 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testResyncByDiffAfterFollowerCrashes
 [junit] 2013-12-06 09:09:42,271 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testFourLetterWords
 [junit] 2013-12-06 09:14:03,770 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testLE
 [junit] 2013-12-06 09:46:30,002 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testHierarchicalQuorum
 [junit] 2013-12-06 09:50:26,912 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testHammerBasic
 [junit] 2013-12-06 09:51:07,604 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testQuotaWithQuorum
 [junit] 2013-12-06 09:52:41,515 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testNull
 [junit] 2013-12-06 09:53:22,648 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testDeleteWithChildren
 [junit] 2013-12-06 09:56:49,061 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testClientwithoutWatcherObj
 [junit] 2013-12-06 09:58:27,705 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testGetView
 [junit] 2013-12-06 09:59:07,856 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testViewContains
 [junit] 2013-12-06 10:01:31,418 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testSessionMoved
 [junit] 2013-12-06

[jira] [Updated] (ZOOKEEPER-2039) Jute compareBytes incorrect comparison index


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Flavio Junqueira updated ZOOKEEPER-2039:

Assignee: Ian Dimayuga

 Jute compareBytes incorrect comparison index
 

 Key: ZOOKEEPER-2039
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2039
 Project: ZooKeeper
  Issue Type: Bug
  Components: jute
Affects Versions: 3.4.6, 3.5.0
Reporter: Ian Dimayuga
Assignee: Ian Dimayuga
Priority: Minor
 Fix For: 3.4.7, 3.5.1

 Attachments: ZOOKEEPER-2039.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 The Jute utility's naïve byte-array comparison compares b1[off1+i] with 
 b2[off2+1]. (A literal 1, not the variable i)
 It should be off2+i, in parallel with the other operand.



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

[jira] [Updated] (ZOOKEEPER-2039) Jute compareBytes incorrect comparison index


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Flavio Junqueira updated ZOOKEEPER-2039:

Attachment: ZOOKEEPER-2039.patch

Uploading a valid patch, and removed the tabs around the line changing.

 Jute compareBytes incorrect comparison index
 

 Key: ZOOKEEPER-2039
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2039
 Project: ZooKeeper
  Issue Type: Bug
  Components: jute
Affects Versions: 3.4.6, 3.5.0
Reporter: Ian Dimayuga
Assignee: Ian Dimayuga
Priority: Minor
 Fix For: 3.4.7, 3.5.1

 Attachments: ZOOKEEPER-2039.patch, ZOOKEEPER-2039.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 The Jute utility's naïve byte-array comparison compares b1[off1+i] with 
 b2[off2+1]. (A literal 1, not the variable i)
 It should be off2+i, in parallel with the other operand.



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

Failed: ZOOKEEPER-2039 PreCommit Build #2336

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2039
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2336/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 316984 lines...]
 [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 2.0.3) 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/2336//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2336//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2336//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] 41e2d9e54327907d3a8d289cf5796b697af5468f 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:1713:
 exec returned: 2

Total time: 40 minutes 51 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 7 artifacts
Archive block size is 32768
Received 0 blocks and 547196 bytes
Compression is 0.0%
Took 5.7 sec
Recording test results
Description set: ZOOKEEPER-2039
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
3 tests failed.
REGRESSION:  
org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentServersAreObserversInNextConfig

Error Message:
waiting for server 2 being up

Stack Trace:
junit.framework.AssertionFailedError: waiting for server 2 being up
at 
org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentServersAreObserversInNextConfig(ReconfigRecoveryTest.java:217)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)


REGRESSION:  
org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentObserverIsParticipantInNewConfig

Error Message:
waiting for server 2 being up

Stack Trace:
junit.framework.AssertionFailedError: waiting for server 2 being up
at 
org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentObserverIsParticipantInNewConfig(ReconfigRecoveryTest.java:529)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)


FAILED:  org.apache.zookeeper.test.NioNettySuiteHammerTest.testHammer

Error Message:
Forked Java VM exited abnormally. Please note the time in the report does not 
reflect the time until the VM exit.

Stack Trace:
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please 
note the time in the report does not reflect the time until the VM exit.

[jira] [Commented] (ZOOKEEPER-2039) Jute compareBytes incorrect comparison index

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135337#comment-14135337
]

Hadoop QA commented on ZOOKEEPER-2039:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12669031/ZOOKEEPER-2039.patch
against trunk revision 1623916.

+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 2.0.3)
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/2336//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2336//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2336//console

This message is automatically generated.

Jute compareBytes incorrect comparison index

Key: ZOOKEEPER-2039
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2039
Project: ZooKeeper
Issue Type: Bug
Components: jute
Affects Versions: 3.4.6, 3.5.0
Reporter: Ian Dimayuga
Assignee: Ian Dimayuga
Priority: Minor
Fix For: 3.4.7, 3.5.1

Attachments: ZOOKEEPER-2039.patch, ZOOKEEPER-2039.patch

Original Estimate: 24h
Remaining Estimate: 24h

The Jute utility's naïve byte-array comparison compares b1[off1+i] with
b2[off2+1]. (A literal 1, not the variable i)
It should be off2+i, in parallel with the other operand.

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

ZooKeeper-trunk-jdk7 - Build # 979 - Failure

See https://builds.apache.org/job/ZooKeeper-trunk-jdk7/979/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 324340 lines...]
[junit] 2014-09-16 12:07:22,252 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2014-09-16 12:07:22,253 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2014-09-16 12:07:22,253 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 32 worker threads, and 64 
kB direct buffers.
[junit] 2014-09-16 12:07:22,253 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2014-09-16 12:07:22,254 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2014-09-16 12:07:22,254 [myid:] - INFO  [main:ZooKeeperServer@781] 
- minSessionTimeout set to 6000
[junit] 2014-09-16 12:07:22,254 [myid:] - INFO  [main:ZooKeeperServer@790] 
- maxSessionTimeout set to 6
[junit] 2014-09-16 12:07:22,254 [myid:] - INFO  [main:ZooKeeperServer@152] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test571309506994501.junit.dir/version-2
 snapdir 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test571309506994501.junit.dir/version-2
[junit] 2014-09-16 12:07:22,256 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test571309506994501.junit.dir/version-2/snapshot.b
[junit] 2014-09-16 12:07:22,258 [myid:] - INFO  [main:FileTxnSnapLog@298] - 
Snapshotting: 0xb to 
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test571309506994501.junit.dir/version-2/snapshot.b
[junit] 2014-09-16 12:07:22,260 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-09-16 12:07:22,261 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:53261
[junit] 2014-09-16 12:07:22,262 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from 
/127.0.0.1:53261
[junit] 2014-09-16 12:07:22,262 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output
[junit] 2014-09-16 12:07:22,262 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client 
/127.0.0.1:53261 (no session established for client)
[junit] 2014-09-16 12:07:22,263 [myid:] - INFO  [main:JMXEnv@224] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2014-09-16 12:07:22,265 [myid:] - INFO  [main:JMXEnv@241] - 
expect:InMemoryDataTree
[junit] 2014-09-16 12:07:22,265 [myid:] - INFO  [main:JMXEnv@245] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2014-09-16 12:07:22,265 [myid:] - INFO  [main:JMXEnv@241] - 
expect:StandaloneServer_port
[junit] 2014-09-16 12:07:22,265 [myid:] - INFO  [main:JMXEnv@245] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-09-16 12:07:22,265 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 18087
[junit] 2014-09-16 12:07:22,266 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24
[junit] 2014-09-16 12:07:22,266 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota
[junit] 2014-09-16 12:07:22,266 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2014-09-16 12:07:22,330 [myid:] - INFO  [main:ZooKeeper@968] - 
Session: 0x1487e5c28c4 closed
[junit] 2014-09-16 12:07:22,330 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2014-09-16 12:07:22,330 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down
[junit] 2014-09-16 12:07:22,331 [myid:] - INFO  
[ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - 
ConnnectionExpirerThread interrupted
[junit] 2014-09-16 12:07:22,331 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit] 2014-09-16 12:07:22,331 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219]
 - accept thread exitted run method
[junit] 2014-09-16 12:07:22,331 [myid:] - INFO  
[NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] 
- selector thread exitted run method
[junit]

[jira] [Updated] (ZOOKEEPER-1952) Default log directory and file name can be changed


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rakesh R updated ZOOKEEPER-1952:

Fix Version/s: 3.5.1

 Default log directory and file name can be changed
 --

 Key: ZOOKEEPER-1952
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1952
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.6
Reporter: nijel
Assignee: nijel
Priority: Minor
 Fix For: 3.5.1

 Attachments: ZOOKEEPER-1952-1.patch


 The log folder and log file name is configurable now.
 The default log folder is . in distribution. So the log file 
 (zookeeper.out) will be placed in bin folder
 Can this be changed to zk_home/logs/zookeeperserver-hostname.log ?



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

[jira] [Commented] (ZOOKEEPER-1952) Default log directory and file name can be changed


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135390#comment-14135390
 ] 

Rakesh R commented on ZOOKEEPER-1952:
-

Thanks [~nijel]. Just one comment. Please use 'ZOO_LOGFILE' instead of 
'ZOOKEEPER_LOGFILE', so that it will be in sync with other variable names.

Also, patch not applying in trunk, could you use rebase the patch.

 Default log directory and file name can be changed
 --

 Key: ZOOKEEPER-1952
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1952
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.6
Reporter: nijel
Assignee: nijel
Priority: Minor
 Fix For: 3.5.1

 Attachments: ZOOKEEPER-1952-1.patch


 The log folder and log file name is configurable now.
 The default log folder is . in distribution. So the log file 
 (zookeeper.out) will be placed in bin folder
 Can this be changed to zk_home/logs/zookeeperserver-hostname.log ?



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

Re: Should maxClientCnxns limit connections peer ip or per process

2014-09-16 Thread Flavio Junqueira

Hi there,

If you want to have a discussion around this, I suggest you create a jira. If 
you can propose a patch even better.

-Flavio


On Tuesday, September 16, 2014 3:56 AM, tobe tobeg3oo...@gmail.com wrote:
 



Recently I learned more about maxClientCnxns configuration and read the
read the code of implement. I know now it's the limitation of the number of
connection from the same ip.

But actually we run multiple process in the same server. And if one process
excesses the limitation of maxClientCnxns, all the ZooKeeper clients will
fail to connect with ZooKeeper cluster. Can we fix that to make this
limitation for each process?

Any suggestion is welcome.

[jira] [Commented] (ZOOKEEPER-1506) Re-try DNS hostname - IP resolution if node connection fails

2014-09-16 Thread Joshua Buss (JIRA)

[
https://issues.apache.org/jira/browse/ZOOKEEPER-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135508#comment-14135508
]

Joshua Buss commented on ZOOKEEPER-1506:

This is very, very annoying. Please get the fix into master as soon as
possible. Thanks from another heavy user of cloud services (this affects any
environment where you use the same hostnames for configuration purposes but
dynamically re-build instances which get new IPs).

Re-try DNS hostname - IP resolution if node connection fails
-

Key: ZOOKEEPER-1506
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1506
Project: ZooKeeper
Issue Type: Improvement
Components: server
Affects Versions: 3.4.5
Environment: Ubuntu 11.04 64-bit
Reporter: Mike Heffner
Assignee: Michael Lasevich
Priority: Critical
Labels: patch
Fix For: 3.5.1

Attachments: ZOOKEEPER-1506.patch, ZOOKEEPER-1506.patch,
ZOOKEEPER-1506.patch, zk-dns-caching-refresh.patch

In our zoo.cfg we use hostnames to identify the ZK servers that are part of
an ensemble. These hostnames are configured with a low (= 60s) TTL and the
IP address they map to can and does change. Our procedure for
replacing/upgrading a ZK node is to boot an entirely new instance and remap
the hostname to the new instance's IP address. Our expectation is that when
the original ZK node is terminated/shutdown, the remaining nodes in the
ensemble would reconnect to the new instance.
However, what we are noticing is that the remaining ZK nodes do not attempt
to re-resolve the hostname-IP mapping for the new server. Once the original
ZK node is terminated, the existing servers continue to attempt contacting it
at the old IP address. It would be great if the ZK servers could try to
re-resolve the hostname when attempting to connect to a lost ZK server,
instead of caching the lookup indefinitely. Currently we must do a rolling
restart of the ZK ensemble after swapping a node -- which at three nodes
means we periodically lose quorum.
The exact method we are following is to boot new instances in EC2 and attach
one, of a set of three, Elastic IP address. External to EC2 this IP address
remains the same and maps to whatever instance it is attached to. Internal to
EC2, the elastic IP hostname has a TTL of about 45-60 seconds and is remapped
to the internal (10.x.y.z) address of the instance it is attached to.
Therefore, in our case we would like ZK to pickup the new 10.x.y.z address
that the elastic IP hostname gets mapped to and reconnect appropriately.

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

[jira] [Commented] (ZOOKEEPER-2025) Single-node ejection caused apparent reconnection storm, leading to cluster unresponsiveness

2014-09-16 Thread Ted Dunning (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135510#comment-14135510
 ] 

Ted Dunning commented on ZOOKEEPER-2025:


Hongchao,

I don't see how that really addresses the problems here.  The throttling code 
is still very naive.  And the complete throttling of clients with no client 
back off is also not a great solution since there is no source quench under 
pretty reasonable scenarios.

It also doesn't address the question of why one server would send an 
unreasonably large packet to another.

Flavio,

Have you had a chance to look at this?



 Single-node ejection caused apparent reconnection storm, leading to cluster 
 unresponsiveness
 

 Key: ZOOKEEPER-2025
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2025
 Project: ZooKeeper
  Issue Type: Bug
  Components: c client, server
Affects Versions: 3.4.5
Reporter: Stephen Tyree
 Attachments: zookeeper_issues.pdf


 Description will be included in an attached PDF.
 The two main questions we have are:
 1: What would be the cause of the Unreasonable Length error in our context, 
 and how might we prevent it from occurring?
 2: What can we do to prevent the reconnection storm that led to the cluster 
 becoming unresponsive?



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

[jira] [Commented] (ZOOKEEPER-1506) Re-try DNS hostname - IP resolution if node connection fails

[
https://issues.apache.org/jira/browse/ZOOKEEPER-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135537#comment-14135537
]

Flavio Junqueira commented on ZOOKEEPER-1506:
-

I think there is a deeper problem here that I'm worried about. If you point a
name to a different server starting from scratch, then it is like the server
state has been wiped out from the perspective of the ZK replication, which can
lead to state loss in some corner cases. One way around this is to use
reconfiguration: remove and re-introduce the server. Is something like this
doable for you?

Re-try DNS hostname - IP resolution if node connection fails
-

Attachments: ZOOKEEPER-1506.patch, ZOOKEEPER-1506.patch,
ZOOKEEPER-1506.patch, zk-dns-caching-refresh.patch

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

Failed: ZOOKEEPER-1506 PreCommit Build #2337

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1506
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2337/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 314087 lines...]
 [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 2.0.3) 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/2337//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2337//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2337//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] cb9cd15f5abea26ec22292f4242fb307fcf95345 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:1713:
 exec returned: 2

Total time: 39 minutes 2 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 7 artifacts
Archive block size is 32768
Received 0 blocks and 547587 bytes
Compression is 0.0%
Took 4.9 sec
Recording test results
Description set: ZOOKEEPER-1506
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
1 tests failed.
FAILED:  org.apache.zookeeper.test.NioNettySuiteHammerTest.testHammer

Error Message:
Forked Java VM exited abnormally. Please note the time in the report does not 
reflect the time until the VM exit.

Stack Trace:
junit.framework.AssertionFailedError: Forked Java VM exited abnormally. Please 
note the time in the report does not reflect the time until the VM exit.

[jira] [Commented] (ZOOKEEPER-1506) Re-try DNS hostname - IP resolution if node connection fails

[
https://issues.apache.org/jira/browse/ZOOKEEPER-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135572#comment-14135572
]

Hadoop QA commented on ZOOKEEPER-1506:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12648826/ZOOKEEPER-1506.patch
against trunk revision 1623916.

+1 @author. The patch does not contain any @author tags.

+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 2.0.3)
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/2337//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2337//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2337//console

This message is automatically generated.

Re-try DNS hostname - IP resolution if node connection fails
-

Attachments: ZOOKEEPER-1506.patch, ZOOKEEPER-1506.patch,
ZOOKEEPER-1506.patch, zk-dns-caching-refresh.patch

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

[jira] [Commented] (ZOOKEEPER-1934) Stale data received from sync'd ensemble peer

2014-09-16 Thread Jared Cantwell (JIRA)

[
https://issues.apache.org/jira/browse/ZOOKEEPER-1934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135644#comment-14135644
]

Jared Cantwell commented on ZOOKEEPER-1934:
---

I am working with Marshall on this issue. Upon investigating more, I noticed
that all of our processes that had problems had just re-established a
connection to node2 immediately before getting stale state from that ZK
(through node2). This seems to match with Marshall's observation that dumping
state with zktreeutil on node2 shows a state that is out of date. It was even
stale some time afterward.

So right now I am investigating how node2 could think its local database was at
zxid N+1 (hence why it accepted the connection from the client), but somehow
the state of the database is reflecting zxid = N. Leader election happened
about 15 seconds prior to this, but connections were just getting session
connected events. I'm still digging through the leader election logs, but
nothing stands out as suspicious to me yet.

Any help or ideas for things to look for would be much appreciated.

Stale data received from sync'd ensemble peer
-

Key: ZOOKEEPER-1934
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1934
Project: ZooKeeper
Issue Type: Bug
Affects Versions: 3.5.0
Reporter: Marshall McMullen
Attachments: node1.log, node2.log, node3.log, node4.log, node5.log

In our regression testing we encountered an error wherein we were caching a
value we read from zookeeper and then experienced session loss. We
subsequently got reconnected to a different zookeeper server. When we tried
to read the same path from this new zookeeper server we are getting a stale
value.
Specifically, we are reading /binchanges and originally got back a value of
3 from the first server. After we lost connection and reconnected before
the session timeout, we then read /binchanges from the new server and got
back a value of 2. In our code path we never set this value from 3 to 2. We
throw an assertion if the value ever goes backwards. Which is how we caught
this error.
It's my understanding of the single system image guarantee that this should
never be allowed. I realize that the single system image guarantee is still
quorum based and it's certainly possible that a minority of the ensemble may
have stale data. However, I also believe that each client has to send the
highest zxid it's seen as part of its connection request to the server. And
if the server it's connecting to has a smaller zxid than the value the client
sends, then the connection request should be refused.
Assuming I have all of that correct, then I'm at a loss for how this
happened.
The failure happened around Jun 4 08:13:44. Just before that, at June 4
08:13:30 there was a round of leader election. During that round of leader
election we voted server with id=4 and zxid=0x31c4c. This then led to a
new zxid=0x40001. The new leader sends a diff to all the servers
including the one we will soon read the stale data from (id=2). Server with
ID=2's log files also reflect that as of 08:13:43 it was up to date and
current with an UPTODATE message.
I'm going to attach log files from all 5 ensemble nodes. I also used
zktreeutil to dump the database out for the 5 ensemble nodes. I diff'd those,
and compared them all for correctness. 1 of the nodes (id=2) has a massively
divergent zktreeutil dump than the other 4 nodes even though it received the
diff from the new leader.
In the attachments there are 5 nodes. I will number each log file by it's
zookeeper id, e.g. node4.log.

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

[jira] [Created] (ZOOKEEPER-2040) Server to log underlying cause of SASL connection problems

2014-09-16 Thread Steve Loughran (JIRA)

Steve Loughran created ZOOKEEPER-2040:
-

 Summary: Server to log underlying cause of SASL connection problems
 Key: ZOOKEEPER-2040
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2040
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.6
Reporter: Steve Loughran


When you have SASL connectivity problems, you spend time staring at logs 
—ideally logs with stack traces.

ZK server can help here by including the stack traces when there is a SASL auth 
problem, rather than just giving the text of the exception.



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

[jira] [Updated] (ZOOKEEPER-2040) Server to log underlying cause of SASL connection problems

2014-09-16 Thread Steve Loughran (JIRA)


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Steve Loughran updated ZOOKEEPER-2040:
--
Attachment: ZOOKEEPER-2040-log-SASL-errors-001.patch

adds the underlying exception.

Before
{code}
WARN  server.ZooKeeperServer (ZooKeeperServer.java:processSasl(969)) - Client 
failed to SASL authenticate: javax.security.sasl.SaslException: GSS initiate 
failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism 
level: Checksum failed)]
{code}

After

{code}
 WARN  server.ZooKeeperServer (ZooKeeperServer.java:processSasl(969)) - Client 
failed to SASL authenticate: javax.security.sasl.SaslException: GSS initiate 
failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism 
level: Checksum failed)]
javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: 
Failure unspecified at GSS-API level (Mechanism level: Checksum failed)]
at 
com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:177)
at 
org.apache.zookeeper.server.ZooKeeperSaslServer.evaluateResponse(ZooKeeperSaslServer.java:158)
at 
org.apache.zookeeper.server.ZooKeeperServer.processSasl(ZooKeeperServer.java:961)
at 
org.apache.zookeeper.server.ZooKeeperServer.processPacket(ZooKeeperServer.java:934)
at 
org.apache.zookeeper.server.NIOServerCnxn.readRequest(NIOServerCnxn.java:373)
at 
org.apache.zookeeper.server.NIOServerCnxn.readPayload(NIOServerCnxn.java:200)
at 
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:244)
at 
org.apache.zookeeper.server.NIOServerCnxnFactory.run(NIOServerCnxnFactory.java:208)
at java.lang.Thread.run(Thread.java:745)
Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: 
Checksum failed)
at 
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:788)
at 
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)
at 
sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)
at 
com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:155)
... 8 more
Caused by: KrbException: Checksum failed
at 
sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType.decrypt(Aes128CtsHmacSha1EType.java:102)
at 
sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType.decrypt(Aes128CtsHmacSha1EType.java:94)
at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:177)
at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:278)
at sun.security.krb5.KrbApReq.init(KrbApReq.java:144)
at 
sun.security.jgss.krb5.InitSecContextToken.init(InitSecContextToken.java:108)
at 
sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:771)
... 11 more
Caused by: java.security.GeneralSecurityException: Checksum failed
at 
sun.security.krb5.internal.crypto.dk.AesDkCrypto.decryptCTS(AesDkCrypto.java:451)
at 
sun.security.krb5.internal.crypto.dk.AesDkCrypto.decrypt(AesDkCrypto.java:272)
at sun.security.krb5.internal.crypto.Aes128.decrypt(Aes128.java:76)
at 
sun.security.krb5.internal.crypto.Aes128CtsHmacSha1EType.decrypt(Aes128CtsHmacSha1EType.java:100)
... 17 more
{code}

It may seem noisier, but it's the information needed to actually work out what 
the problem is, here something AES related

 Server to log underlying cause of SASL connection problems
 --

 Key: ZOOKEEPER-2040
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2040
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.6
Reporter: Steve Loughran
 Attachments: ZOOKEEPER-2040-log-SASL-errors-001.patch


 When you have SASL connectivity problems, you spend time staring at logs 
 —ideally logs with stack traces.
 ZK server can help here by including the stack traces when there is a SASL 
 auth problem, rather than just giving the text of the exception.



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

Failed: ZOOKEEPER-2040 PreCommit Build #2338

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2040
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2338/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 99 lines...]
 [exec] Skipping patch.
 [exec] 1 out of 1 hunk ignored
 [exec] PATCH APPLICATION FAILED
 [exec] 
 [exec] 
 [exec] 
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12669084/ZOOKEEPER-2040-log-SASL-errors-001.patch
 [exec]   against trunk revision 1623916.
 [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 patch.  The patch command could not apply the patch.
 [exec] 
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2338//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] 0aa41865267bca7397124b735f30778e7e4755a0 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:1713:
 exec returned: 1

Total time: 41 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 1 artifacts
Archive block size is 32768
Received 0 blocks and 58386 bytes
Compression is 0.0%
Took 1.1 sec
Recording test results
Description set: ZOOKEEPER-2040
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (ZOOKEEPER-2040) Server to log underlying cause of SASL connection problems

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135651#comment-14135651
]

Hadoop QA commented on ZOOKEEPER-2040:
--

-1 overall. Here are the results of testing the latest attachment

http://issues.apache.org/jira/secure/attachment/12669084/ZOOKEEPER-2040-log-SASL-errors-001.patch
against trunk revision 1623916.

+1 @author. The patch does not contain any @author tags.

-1 patch. The patch command could not apply the patch.

Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2338//console

This message is automatically generated.

Server to log underlying cause of SASL connection problems
--

Key: ZOOKEEPER-2040
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2040
Project: ZooKeeper
Issue Type: Improvement
Components: server
Affects Versions: 3.4.6
Reporter: Steve Loughran
Attachments: ZOOKEEPER-2040-log-SASL-errors-001.patch

When you have SASL connectivity problems, you spend time staring at logs
—ideally logs with stack traces.
ZK server can help here by including the stack traces when there is a SASL
auth problem, rather than just giving the text of the exception.

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

[jira] [Commented] (ZOOKEEPER-2040) Server to log underlying cause of SASL connection problems

2014-09-16 Thread Chris Nauroth (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135677#comment-14135677
 ] 

Chris Nauroth commented on ZOOKEEPER-2040:
--

+1 (non-binding) for this change.  Thanks, Steve.

 Server to log underlying cause of SASL connection problems
 --

 Key: ZOOKEEPER-2040
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2040
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.6
Reporter: Steve Loughran
 Attachments: ZOOKEEPER-2040-log-SASL-errors-001.patch


 When you have SASL connectivity problems, you spend time staring at logs 
 —ideally logs with stack traces.
 ZK server can help here by including the stack traces when there is a SASL 
 auth problem, rather than just giving the text of the exception.



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

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: ZOOKEEPER-2016.patch

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

Failed: ZOOKEEPER-2016 PreCommit Build #2339

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2339/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 509 lines...]
 [exec]   against trunk revision 1623916.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 8 new or 
modified tests.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] -1 javac.  The patch appears to cause tar ant target to fail.
 [exec] 
 [exec] -1 findbugs.  The patch appears to cause Findbugs (version 
2.0.3) to fail.
 [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/2339//testReport/
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2339//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] e12a4eb30975c6df152fff9f3b984050f5879f7f 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:1713:
 exec returned: 3

Total time: 1 minute 5 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 4 artifacts
Archive block size is 32768
Received 0 blocks and 77702 bytes
Compression is 0.0%
Took 2.9 sec
Recording test results
Description set: ZOOKEEPER-2016
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135941#comment-14135941
]

Hadoop QA commented on ZOOKEEPER-2016:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12669128/ZOOKEEPER-2016.patch
against trunk revision 1623916.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 8 new or modified tests.

+1 javadoc. The javadoc tool did not generate any warning messages.

-1 javac. The patch appears to cause tar ant target to fail.

-1 findbugs. The patch appears to cause Findbugs (version 2.0.3) to fail.

+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/2339//testReport/
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2339//console

This message is automatically generated.

Automate client-side rebalancing

Key: ZOOKEEPER-2016
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
Project: ZooKeeper
Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch,
draft.patch

ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in
both the C and Java client libraries. However, it requires the client to
detect a configuration change and call updateServerList with the new
connection string (see reconfig manual). It may be better if the client just
indicates that he is interested in this feature when creating a ZK handle and
we'll detect configuration changes and invoke updateServerList for him
underneath the hood.
Reviewboard: https://reviews.apache.org/r/25599/

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

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: ZOOKEEPER-2016.patch

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: (was: ZOOKEEPER-2016.patch)

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135962#comment-14135962
]

Hongchao Deng commented on ZOOKEEPER-2016:
--

I have finished a basic patch that does reconfig balance. This patch doesn't
contain anything regarding the Policy yet.
It would be great if you can summarize what we need for it.

My understanding for what to include in Policy:

1. (min,max) wait time
Client-side backoff is great. But I also realize in
[ClientCnxn|https://github.com/fengjingchao/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1063]
by default it has (0, 1000ms) backoff time. Should we consider how this can
affect our design here?

2. (before, after) updateServerList callback
what is the use case of these?

Automate client-side rebalancing

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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135963#comment-14135963
 ] 

Hongchao Deng commented on ZOOKEEPER-2016:
--

[~shralex] See my above comments. Thanks!

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: (was: ZOOKEEPER-2016.patch)

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: ZOOKEEPER-2016.patch

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

Failed: ZOOKEEPER-2016 PreCommit Build #2340

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 316161 lines...]
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 8 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 2.0.3) warnings.
 [exec] 
 [exec] -1 release audit.  The applied patch generated 2 release audit 
warnings (more than the trunk's current 0 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/2340//testReport/
 [exec] Release audit warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340//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] 2b5dadf1392d259a2cc6cac94afcddf9a673e459 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:1713:
 exec returned: 2

Total time: 38 minutes 19 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 8 artifacts
Archive block size is 32768
Received 0 blocks and 554814 bytes
Compression is 0.0%
Took 2.4 sec
Recording test results
Description set: ZOOKEEPER-2016
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
3 tests failed.
FAILED:  org.apache.zookeeper.test.ReconfigBalanceTest.testAutoBalance

Error Message:
Couldn't instantiate org.apache.zookeeper.ClientCnxnSocketNIO

Stack Trace:
java.io.IOException: Couldn't instantiate 
org.apache.zookeeper.ClientCnxnSocketNIO
at 
org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:2674)
at org.apache.zookeeper.ZooKeeper.init(ZooKeeper.java:933)
at org.apache.zookeeper.ZooKeeper.init(ZooKeeper.java:899)
at 
org.apache.zookeeper.test.ReconfigBalanceTest.testAutoBalance(ReconfigBalanceTest.java:57)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
Caused by: java.io.IOException: Too many open files
at sun.nio.ch.IOUtil.initPipe(Native Method)
at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:49)
at 
sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
at java.nio.channels.Selector.open(Selector.java:209)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.init(ClientCnxnSocketNIO.java:44)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:357)
at java.lang.Class.newInstance(Class.java:310)
at 
org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:2671)


REGRESSION:  org.apache.zookeeper.test.ReconfigTest.testPortChange

Error Message:
expected:test[1] but was:test[0]

Stack Trace:
junit.framework.AssertionFailedError: expected:test[1] but was:test[0]
at

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136045#comment-14136045
]

Hadoop QA commented on ZOOKEEPER-2016:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12669136/ZOOKEEPER-2016.patch
against trunk revision 1623916.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 8 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 2.0.3)
warnings.

-1 release audit. The applied patch generated 2 release audit warnings
(more than the trunk's current 0 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/2340//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2340//console

This message is automatically generated.

Automate client-side rebalancing

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

[jira] [Commented] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect

2014-09-16 Thread Andrew Purtell (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136066#comment-14136066
 ] 

Andrew Purtell commented on ZOOKEEPER-832:
--

If the zxid is not recognized by the server, the client will attempt reconnects 
indefinitely and never succeed. This can contribute gigabytes to service 
logging and bring down the service with the embedded ZK client *and others*. 
The client should error out somehow permanently. Can this be fixed here? 
Perhaps other issues can be addressed in follow up? Unquestionably the 
continuous and perpetual client retries is a bug, they will never succeed, and 
a fleet of clients in such state can impact network services.

If we otherwise recreate application znode state in the reinitialized cluster, 
why should applications be prevented from riding over a loss of transient ZK 
state, if the use case supports it? For example if the ZK client would error 
out with a session expired status under these conditions, HBase would create a 
new ZooKeeper client object, attempt a reconnect using it, and might succeed. 
(I think, haven't tested it.) Understood this is not a normal case but it comes 
up frequently in federated test environments where the ZK cluster is under your 
control but not necessarily the applications.

 Invalid session id causes infinite loop during automatic reconnect
 --

 Key: ZOOKEEPER-832
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.3.1, 3.4.5, 3.5.0
 Environment: All
Reporter: Ryan Holmes
Assignee: Germán Blanco
 Fix For: 3.4.7, 3.5.1

 Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
 ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch


 Steps to reproduce:
 1.) Connect to a standalone server using the Java client.
 2.) Stop the server.
 3.) Delete the contents of the data directory (i.e. the persisted session 
 data).
 4.) Start the server.
 The client now automatically tries to reconnect but the server refuses the 
 connection because the session id is invalid. The client and server are now 
 in an infinite loop of attempted and rejected connections. While this 
 situation represents a catastrophic failure and the current behavior is not 
 incorrect, it appears that there is no way to detect this situation on the 
 client and therefore no way to recover.
 The suggested improvement is to send an event to the default watcher 
 indicating that the current state is session invalid, similar to how the 
 session expired state is handled.
 Server log output (repeats indefinitely):
 2010-08-05 11:48:08,283 - INFO  
 [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - 
 Accepted socket connection from /127.0.0.1:63292
 2010-08-05 11:48:08,284 - INFO  
 [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing 
 session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last 
 zxid is 0x0 client must try another server
 2010-08-05 11:48:08,284 - INFO  
 [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed 
 socket connection for client /127.0.0.1:63292 (no session established for 
 client)
 Client log output (repeats indefinitely):
 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - 
 Opening socket connection to server localhost/127.0.0.1:2181
 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session 
 0x12a3ae4e893000a for server null, unexpected error, closing socket 
 connection and attempting reconnect
 java.net.ConnectException: Connection refused
   at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
   at 
 sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574)
   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring 
 exception during shutdown input
 java.nio.channels.ClosedChannelException
   at 
 sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638)
   at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360)
   at 
 org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164)
   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)
 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring 
 exception during shutdown output
 java.nio.channels.ClosedChannelException
   at 
 sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649)
   at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368)
   at 
 org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171)
   at

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: (was: ZOOKEEPER-2016.patch)

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

ZooKeeper-trunk-openjdk7 - Build # 571 - Still Failing

See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/571/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 1482 lines...]
[ivy:retrieve]  [SUCCESSFUL ] commons-cli#commons-cli;1.2!commons-cli.jar 
(101ms)
[ivy:retrieve] downloading 
http://repo1.maven.org/maven2/log4j/log4j/1.2.16/log4j-1.2.16.jar ...
[ivy:retrieve] . (470kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve]  [SUCCESSFUL ] log4j#log4j;1.2.16!log4j.jar(bundle) (105ms)
[ivy:retrieve] downloading 
http://repo1.maven.org/maven2/io/netty/netty/3.7.0.Final/netty-3.7.0.Final.jar 
...
[ivy:retrieve] ... (1180kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve]  [SUCCESSFUL ] io.netty#netty;3.7.0.Final!netty.jar (140ms)
[ivy:retrieve] downloading 
http://repo1.maven.org/maven2/net/java/dev/javacc/javacc/5.0/javacc-5.0.jar ...
[ivy:retrieve]  (291kB)
[ivy:retrieve] .. (0kB)
[ivy:retrieve]  [SUCCESSFUL ] net.java.dev.javacc#javacc;5.0!javacc.jar (113ms)
[ivy:retrieve] :: resolution report :: resolve 6671ms :: artifacts dl 1502ms
-
|  |modules||   artifacts   |
|   conf   | number| search|dwnlded|evicted|| number|dwnlded|
-
|  default |   12  |   12  |   12  |   0   ||   12  |   12  |
-
[ivy:retrieve] :: retrieving :: org.apache.zookeeper#zookeeper
[ivy:retrieve]  confs: [default]
[ivy:retrieve]  12 artifacts copied, 0 already retrieved (4040kB/27ms)

clover.setup:

clover.info:

clover:

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

jute:

BUILD FAILED
/jenkins/workspace/ZooKeeper-trunk-openjdk7/trunk/build.xml:286: Unable to find 
a javac compiler;
com.sun.tools.javac.Main is not on the classpath.
Perhaps JAVA_HOME does not point to the JDK.
It is currently set to /usr/lib/jvm/java-7-openjdk-amd64/jre

Total time: 10 seconds
Build step 'Invoke Ant' marked build as failure
[locks-and-latches] Releasing all the locks
[locks-and-latches] All the locks released
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Updated] (ZOOKEEPER-2016) Automate client-side rebalancing


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hongchao Deng updated ZOOKEEPER-2016:
-
Attachment: ZOOKEEPER-2016.patch

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

Failed: ZOOKEEPER-2016 PreCommit Build #2341

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 318796 lines...]
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 8 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 2.0.3) warnings.
 [exec] 
 [exec] -1 release audit.  The applied patch generated 2 release audit 
warnings (more than the trunk's current 0 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/2341//testReport/
 [exec] Release audit warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341//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] 9a00c45a583c9e4bffb91f68235ba1f488d944b5 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:1713:
 exec returned: 2

Total time: 38 minutes 53 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 8 artifacts
Archive block size is 32768
Received 0 blocks and 554669 bytes
Compression is 0.0%
Took 2.9 sec
Recording test results
Description set: ZOOKEEPER-2016
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
2 tests failed.
FAILED:  org.apache.zookeeper.test.RebalanceTest.testAutoBalance

Error Message:
Couldn't instantiate org.apache.zookeeper.ClientCnxnSocketNIO

Stack Trace:
java.io.IOException: Couldn't instantiate 
org.apache.zookeeper.ClientCnxnSocketNIO
at 
org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:2674)
at org.apache.zookeeper.ZooKeeper.init(ZooKeeper.java:933)
at org.apache.zookeeper.ZooKeeper.init(ZooKeeper.java:899)
at 
org.apache.zookeeper.test.RebalanceTest.testAutoBalance(RebalanceTest.java:57)
at 
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
Caused by: java.io.IOException: Too many open files
at sun.nio.ch.IOUtil.initPipe(Native Method)
at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:49)
at 
sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
at java.nio.channels.Selector.open(Selector.java:209)
at 
org.apache.zookeeper.ClientCnxnSocketNIO.init(ClientCnxnSocketNIO.java:44)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:357)
at java.lang.Class.newInstance(Class.java:310)
at 
org.apache.zookeeper.ZooKeeper.getClientCnxnSocket(ZooKeeper.java:2671)


FAILED:  org.apache.zookeeper.test.NioNettySuiteHammerTest.testHammer

Error Message:
Forked Java VM exited abnormally. Please note the time in the report does not 
reflect the time until the VM exit.

Stack Trace:

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136114#comment-14136114
]

Hadoop QA commented on ZOOKEEPER-2016:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12669156/ZOOKEEPER-2016.patch
against trunk revision 1623916.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 8 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 2.0.3)
warnings.

-1 release audit. The applied patch generated 2 release audit warnings
(more than the trunk's current 0 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/2341//testReport/
Release audit warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341//artifact/trunk/patchprocess/patchReleaseAuditProblems.txt
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2341//console

This message is automatically generated.

Automate client-side rebalancing

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

Failed: ZOOKEEPER-2016 PreCommit Build #2342

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2342/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 324537 lines...]
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 8 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 2.0.3) 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/2342//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2342//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2342//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] 0809cca3f8d36e8dcceb9682d735e07c0e7d418a 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:1713:
 exec returned: 1

Total time: 54 minutes 50 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2179
Archived 7 artifacts
Archive block size is 32768
Received 0 blocks and 548363 bytes
Compression is 0.0%
Took 1.1 sec
Recording test results
Description set: ZOOKEEPER-2016
Email was triggered for: Failure
Sending email for trigger: Failure



###
## FAILED TESTS (if any) 
##
3 tests failed.
FAILED:  org.apache.zookeeper.test.AsyncHammerTest.testObserversHammer

Error Message:
Couldn't instantiate org.apache.zookeeper.server.NettyServerCnxnFactory

Stack Trace:
java.io.IOException: Couldn't instantiate 
org.apache.zookeeper.server.NettyServerCnxnFactory
at 
org.apache.zookeeper.server.ServerCnxnFactory.createFactory(ServerCnxnFactory.java:116)
at 
org.apache.zookeeper.server.ServerCnxnFactory.createFactory(ServerCnxnFactory.java:132)
at 
org.apache.zookeeper.server.quorum.QuorumPeer.init(QuorumPeer.java:728)
at 
org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:172)
at org.apache.zookeeper.test.QuorumBase.setUp(QuorumBase.java:120)
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)
Caused by: org.jboss.netty.channel.ChannelException: Failed to create a 
selector.
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.openSelector(AbstractNioSelector.java:337)
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.init(AbstractNioSelector.java:95)
at 
org.jboss.netty.channel.socket.nio.AbstractNioWorker.init(AbstractNioWorker.java:53)
at 
org.jboss.netty.channel.socket.nio.NioWorker.init(NioWorker.java:45)
at 
org.jboss.netty.channel.socket.nio.NioWorkerPool.createWorker(NioWorkerPool.java:45)
at 
org.jboss.netty.channel.socket.nio.NioWorkerPool.createWorker(NioWorkerPool.java:28)
at

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136196#comment-14136196
]

Hadoop QA commented on ZOOKEEPER-2016:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12669170/ZOOKEEPER-2016.patch
against trunk revision 1623916.

+1 @author. The patch does not contain any @author tags.

+1 tests included. The patch appears to include 8 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 2.0.3)
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/2342//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2342//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2342//console

This message is automatically generated.

Automate client-side rebalancing

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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

2014-09-16 Thread Alexander Shraer (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136316#comment-14136316
 ] 

Alexander Shraer commented on ZOOKEEPER-2016:
-

do we need both (1) and (2) ? if you allow users to provide a callback they can 
probably implement the backoff easily themselves. You could of course also 
provide a default implementation of the policy with min and max parameters.

I don't remember why we needed the after callback. I remember some discussion 
about it but can't find it now.

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

[
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136328#comment-14136328
]

Hongchao Deng commented on ZOOKEEPER-2016:
--

Cool. callback method seems better and more flexible to me. And we still have
default reconnect backoff at
[ClientCnxn|https://github.com/fengjingchao/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java#L1063].

bq. perhaps your Policy class could have 2 optional user specified functions as
parameters - one for what to do before calling updateServerString (such as
sleep) and the other for filtering connection strings.
That's it!

Automate client-side rebalancing

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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

2014-09-16 Thread Alexander Shraer (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136346#comment-14136346
 ] 

Alexander Shraer commented on ZOOKEEPER-2016:
-

oh right, that's it. So its not a callback that will be executed after - both 
are before the call to updateServerList. One is for what to do before such as 
waiting, the other is for taking a connection string (based on getConfig's 
response) and potentially changing it. The new returned connection string is 
then passed to updateServerList. 
How does that sound ?

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136377#comment-14136377
 ] 

Hongchao Deng commented on ZOOKEEPER-2016:
--

Make sense!

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Commented] (ZOOKEEPER-2031) Support tagging a QuorumServer

2014-09-16 Thread Michi Mutsuzaki (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136487#comment-14136487
 ] 

Michi Mutsuzaki commented on ZOOKEEPER-2031:


+1 I'll wait for Alex to +1 this as well. I think we can get this into 3.5.0.

 Support tagging a QuorumServer
 --

 Key: ZOOKEEPER-2031
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2031
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Reporter: some one
Assignee: some one
 Fix For: 3.5.1, 3.6.0

 Attachments: ZOOKEEPER-2031-Additional.patch, ZOOKEEPER-2031.patch


 Currently ZooKeeper only allows using the server id which is an integer for 
 identifying servers. For my (unavoidable) use case, there may be concurrent 
 dynamic removes and adds of servers which may eventually have id collisions. 
 When this occurs, there is no good way to determine if the server (given an 
 id collision) that we want to remove is the right server.
 To support my use case, I propose that we add a tag field to the server 
 string.
 For my specific use case, this tag field will be used to store a uuid as a 
 string.
 So for example:
 server.1=127.0.0.1:1234:1236:participant;0.0.0.0:1237;743b9d23-85cb-45b1-8949-930fdabb21f0



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

[jira] [Created] (ZOOKEEPER-2041) maxClientCnxns should limit connections for each process rather than ip

2014-09-16 Thread chendihao (JIRA)

chendihao created ZOOKEEPER-2041:


 Summary: maxClientCnxns should limit connections for each process 
rather than ip
 Key: ZOOKEEPER-2041
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2041
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.4
Reporter: chendihao


Recently I learned more about maxClientCnxns configuration and read the read 
the code of implement. I know now it's the limitation of the number of 
connection from the same ip.

But actually we may run multiple process in the same server. And if one process 
excesses the limitation of maxClientCnxns, all the ZooKeeper clients will fail 
to connect with ZooKeeper cluster. Can we fix that to make this limitation for 
each process?

Any suggestion is welcome.



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

Re: Should maxClientCnxns limit connections peer ip or per process

2014-09-16 Thread tobe

Thank @flavio and I create
https://issues.apache.org/jira/browse/ZOOKEEPER-2041.

I would like to know more about your suggestions and the original design of
maxClientCnxns before working on it :-)

On Tue, Sep 16, 2014 at 9:39 PM, Flavio Junqueira 
fpjunque...@yahoo.com.invalid wrote:

 Hi there,

 If you want to have a discussion around this, I suggest you create a jira.
 If you can propose a patch even better.

 -Flavio


 On Tuesday, September 16, 2014 3:56 AM, tobe tobeg3oo...@gmail.com
 wrote:


 
 
 Recently I learned more about maxClientCnxns configuration and read the
 read the code of implement. I know now it's the limitation of the number
 of
 connection from the same ip.
 
 But actually we run multiple process in the same server. And if one
 process
 excesses the limitation of maxClientCnxns, all the ZooKeeper clients will
 fail to connect with ZooKeeper cluster. Can we fix that to make this
 limitation for each process?
 
 Any suggestion is welcome.

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136667#comment-14136667
 ] 

Hongchao Deng commented on ZOOKEEPER-2016:
--

[~shralex]
I think it's better to verify connectString returned from the callback. Do you 
know anything in existing code that does this?

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Commented] (ZOOKEEPER-2016) Automate client-side rebalancing

2014-09-16 Thread Alexander Shraer (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136720#comment-14136720
 ] 

Alexander Shraer commented on ZOOKEEPER-2016:
-

I'd look on how the constructor ZooKeeper( ) does that. It uses some class 
ConnectStringParser perhaps you could use that too.  

 Automate client-side rebalancing
 

 Key: ZOOKEEPER-2016
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2016
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: Hongchao Deng
Assignee: Hongchao Deng
 Attachments: ZOOKEEPER-2016.patch, draft-2.patch, draft-3.patch, 
 draft.patch


 ZOOKEEPER-1355 introduced client-side rebalancing, which is implemented in 
 both the C and Java client libraries. However, it requires the client to 
 detect a configuration change and call updateServerList with the new 
 connection string (see reconfig manual). It may be better if the client just 
 indicates that he is interested in this feature when creating a ZK handle and 
 we'll detect configuration changes and invoke updateServerList for him 
 underneath the hood.
 Reviewboard: https://reviews.apache.org/r/25599/



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

[jira] [Updated] (ZOOKEEPER-2030) dynamicConfigFile should have an absolute path, not a relative path, to the dynamic configuration file

2014-09-16 Thread Michi Mutsuzaki (JIRA)


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michi Mutsuzaki updated ZOOKEEPER-2030:
---
Fix Version/s: 3.6.0
   3.5.1

 dynamicConfigFile should have an absolute path, not a relative path, to the 
 dynamic configuration file
 --

 Key: ZOOKEEPER-2030
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2030
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0
Reporter: Alexander Shraer
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.1, 3.6.0

 Attachments: ZOOKEEPER-2030.patch


 a relative path doesn't seem like a good idea since it will work only if we 
 start the server from the same directory as we did previously.



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

[jira] [Commented] (ZOOKEEPER-2030) dynamicConfigFile should have an absolute path, not a relative path, to the dynamic configuration file

2014-09-16 Thread Michi Mutsuzaki (JIRA)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136801#comment-14136801
 ] 

Michi Mutsuzaki commented on ZOOKEEPER-2030:


+1

 dynamicConfigFile should have an absolute path, not a relative path, to the 
 dynamic configuration file
 --

 Key: ZOOKEEPER-2030
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2030
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.5.0
Reporter: Alexander Shraer
Assignee: Alexander Shraer
Priority: Minor
 Fix For: 3.5.1, 3.6.0

 Attachments: ZOOKEEPER-2030.patch


 a relative path doesn't seem like a good idea since it will work only if we 
 start the server from the same directory as we did previously.



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

[jira] [Updated] (BOOKKEEPER-784) BookKeeperCloseTest#testLedgerCheck is failing intermittently


 [ 
https://issues.apache.org/jira/browse/BOOKKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Kelly updated BOOKKEEPER-784:
--
Fix Version/s: 4.3.0

 BookKeeperCloseTest#testLedgerCheck is failing intermittently
 -

 Key: BOOKKEEPER-784
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-784
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 4.3.0


 *Stacktrace*
 {code}
 java.lang.AssertionError: Should have client closed exception expected:0 
 but was:-19
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:470)
   at 
 org.apache.bookkeeper.client.BookKeeperCloseTest.testLedgerCheck(BookKeeperCloseTest.java:501)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 {code}
 Link: 
 https://builds.apache.org/job/bookkeeper-trunk-precommit-build/722/testReport/junit/org.apache.bookkeeper.client/BookKeeperCloseTest/testLedgerCheck/



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

[jira] [Commented] (BOOKKEEPER-784) BookKeeperCloseTest#testLedgerCheck is failing intermittently


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135262#comment-14135262
 ] 

Ivan Kelly commented on BOOKKEEPER-784:
---

I ran for hours, but no repro :/ it happened on build 732 also though (slightly 
differently), so it's a real problem.

 BookKeeperCloseTest#testLedgerCheck is failing intermittently
 -

 Key: BOOKKEEPER-784
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-784
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 4.3.0


 *Stacktrace*
 {code}
 java.lang.AssertionError: Should have client closed exception expected:0 
 but was:-19
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:470)
   at 
 org.apache.bookkeeper.client.BookKeeperCloseTest.testLedgerCheck(BookKeeperCloseTest.java:501)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 {code}
 Link: 
 https://builds.apache.org/job/bookkeeper-trunk-precommit-build/722/testReport/junit/org.apache.bookkeeper.client/BookKeeperCloseTest/testLedgerCheck/



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

[jira] [Commented] (BOOKKEEPER-784) BookKeeperCloseTest#testLedgerCheck is failing intermittently


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135281#comment-14135281
 ] 

Ivan Kelly commented on BOOKKEEPER-784:
---

Having looked at the code, these tests are bad. They kick off an operation, 
then close the client and expect to get a ClientClosedException. This is very 
time sensitive. If the operation completes before the close call, then the 
return code will be OK [the slowing of the bookie should avoid this, but thats 
relying on timers]. If they get past the initial check, they will fail on some 
other call as the bk client closes resources. So there's nothing that we can 
reliably assert on here. 

 BookKeeperCloseTest#testLedgerCheck is failing intermittently
 -

 Key: BOOKKEEPER-784
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-784
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 4.3.0


 *Stacktrace*
 {code}
 java.lang.AssertionError: Should have client closed exception expected:0 
 but was:-19
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:470)
   at 
 org.apache.bookkeeper.client.BookKeeperCloseTest.testLedgerCheck(BookKeeperCloseTest.java:501)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 {code}
 Link: 
 https://builds.apache.org/job/bookkeeper-trunk-precommit-build/722/testReport/junit/org.apache.bookkeeper.client/BookKeeperCloseTest/testLedgerCheck/



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135287#comment-14135287
 ] 

Ivan Kelly commented on BOOKKEEPER-782:
---

I think it would be better if generateCookie took an instanceId and did the 
null check there. the null check only exists for BC.

 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135333#comment-14135333
 ] 

Rakesh R commented on BOOKKEEPER-782:
-

FYI, BOOKKEEPER-773 also has similar requirement of updating the 
bookieHostId(1). Inorder to do this again it needs to pass another argument 
'bookieHostId'' or another overloaded method by taking BookieAddress. If agrees 
will prepare one more patch.

(1)Below piece of code is taken from [BOOKKEEPER-773 JIRA patch number - 
006-BOOKKEEPER-773-rename-bookieid.patch|https://issues.apache.org/jira/secure/attachment/12668023/006-BOOKKEEPER-773-rename-bookieid.patch].
 This will be modified by using the new builder fashion.
{code}
+Cookie cookie = Cookie.readFromZooKeeper(zk, conf);
+cookie = cookie.setBookieHost(newBookieHost);
+cookie.writeToZooKeeper(zk, conf);
{code}

 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

Build failed in Jenkins: bookkeeper-trunk #781

See https://builds.apache.org/job/bookkeeper-trunk/781/

--
[...truncated 700 lines...]

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] 
[INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ bookkeeper-stats-api ---
[INFO] Building jar: 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-stats/target/bookkeeper-stats-api-4.3.0-SNAPSHOT.jar
[INFO] 
[INFO]  findbugs-maven-plugin:2.5.2:check (default-cli) @ 
bookkeeper-stats-api 
[INFO] 
[INFO] --- findbugs-maven-plugin:2.5.2:findbugs (findbugs) @ 
bookkeeper-stats-api ---
[INFO] Fork Value is true
[INFO] Done FindBugs Analysis
[INFO] 
[INFO]  findbugs-maven-plugin:2.5.2:check (default-cli) @ 
bookkeeper-stats-api 
[INFO] 
[INFO] --- findbugs-maven-plugin:2.5.2:check (default-cli) @ 
bookkeeper-stats-api ---
[INFO] BugInstance size is 0
[INFO] Error size is 0
[INFO] No errors/warnings found
[INFO] 
[INFO] 
[INFO] Building bookkeeper-server 4.3.0-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ bookkeeper-server ---
[INFO] Deleting 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server (includes 
= [dependency-reduced-pom.xml], excludes = [])
[INFO] 
[INFO] --- apache-rat-plugin:0.7:check (default-cli) @ bookkeeper-server ---
[INFO] Exclude: **/DataFormats.java
[INFO] Exclude: **/BookkeeperProtocol.java
[INFO] 
[INFO] --- maven-remote-resources-plugin:1.1:process (default) @ 
bookkeeper-server ---
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ 
bookkeeper-server ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ 
bookkeeper-server ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 192 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ 
bookkeeper-server ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] Copying 3 resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ 
bookkeeper-server ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 86 source files to 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/test-classes
[INFO] 
[INFO] --- maven-surefire-plugin:2.9:test (default-test) @ bookkeeper-server ---
[INFO] Surefire report directory: 
https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/surefire-reports

---
 T E S T S
---

---
 T E S T S
---
Running org.apache.bookkeeper.bookie.TestSyncThread
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.902 sec
Running org.apache.bookkeeper.bookie.EntryLogTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.373 sec
Running org.apache.bookkeeper.bookie.BookieThreadTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.124 sec
Running org.apache.bookkeeper.bookie.BookieShutdownTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.726 sec
Running org.apache.bookkeeper.bookie.LedgerCacheTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.011 sec
Running org.apache.bookkeeper.bookie.IndexCorruptionTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.754 sec
Running org.apache.bookkeeper.bookie.BookieJournalTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.86 sec
Running org.apache.bookkeeper.bookie.TestLedgerDirsManager
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.223 sec
Running org.apache.bookkeeper.bookie.CookieTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.933 sec
Running org.apache.bookkeeper.bookie.CreateNewLogTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.339 sec
Running org.apache.bookkeeper.bookie.UpgradeTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.575 sec
Running org.apache.bookkeeper.bookie.CompactionTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 38.71 sec
Running org.apache.bookkeeper.bookie.BookieInitializationTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.74 sec
Running org.apache.bookkeeper.proto.TestPerChannelBookieClient
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.196 sec
Running

[jira] [Commented] (BOOKKEEPER-784) BookKeeperCloseTest#testLedgerCheck is failing intermittently


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135369#comment-14135369
 ] 

Rakesh R commented on BOOKKEEPER-784:
-

bq.the slowing of the bookie should avoid this, but thats relying on timers
Yeah, its relaying on timers. One common failure pattern I could see is, 
immediately after restarting the bookie server its performing the next 
operation, now its hitting Disconnected event and is returning different return 
code. Do you think the following changes will help:  
# Presently it is delaying the server by 5secs, will increase to a bigger 
value(20 or 30secs). Also, we need to increase the read/add timeouts 
respectively.
# After restarting will perform another operation to ensure that the existing 
bkclient successfully reconnected with the restarted server(during this 
operation will reduce the server delay and after this op will set back the 
bigger value). After this pre-requisite step it can perform the actual testing. 
Is there any better way to see the client reconnection completed?

 BookKeeperCloseTest#testLedgerCheck is failing intermittently
 -

 Key: BOOKKEEPER-784
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-784
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 4.3.0


 *Stacktrace*
 {code}
 java.lang.AssertionError: Should have client closed exception expected:0 
 but was:-19
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:470)
   at 
 org.apache.bookkeeper.client.BookKeeperCloseTest.testLedgerCheck(BookKeeperCloseTest.java:501)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 {code}
 Link: 
 https://builds.apache.org/job/bookkeeper-trunk-precommit-build/722/testReport/junit/org.apache.bookkeeper.client/BookKeeperCloseTest/testLedgerCheck/



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

[jira] [Commented] (BOOKKEEPER-784) BookKeeperCloseTest#testLedgerCheck is failing intermittently


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135409#comment-14135409
 ] 

Ivan Kelly commented on BOOKKEEPER-784:
---

This wouldn't change the fact that what we are asserting is non-deterministic. 
As I said, if the call gets past the check for whether the client is closed 
before the client is actually closed, and this is quite possible, then it will 
be a different error code returned. 

 BookKeeperCloseTest#testLedgerCheck is failing intermittently
 -

 Key: BOOKKEEPER-784
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-784
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 4.3.0


 *Stacktrace*
 {code}
 java.lang.AssertionError: Should have client closed exception expected:0 
 but was:-19
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:470)
   at 
 org.apache.bookkeeper.client.BookKeeperCloseTest.testLedgerCheck(BookKeeperCloseTest.java:501)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 {code}
 Link: 
 https://builds.apache.org/job/bookkeeper-trunk-precommit-build/722/testReport/junit/org.apache.bookkeeper.client/BookKeeperCloseTest/testLedgerCheck/



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

[jira] [Updated] (BOOKKEEPER-398) Improving stats collection in bookkeeper


 [ 
https://issues.apache.org/jira/browse/BOOKKEEPER-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ivan Kelly updated BOOKKEEPER-398:
--
Fix Version/s: (was: 4.3.0)

 Improving stats collection in bookkeeper
 

 Key: BOOKKEEPER-398
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-398
 Project: Bookkeeper
  Issue Type: Improvement
  Components: hedwig-server
Affects Versions: 4.2.0
Reporter: Aniruddha
Assignee: Aniruddha
 Attachments: BK-398.patch


 We have been experimenting with using the Twitter stats package 
 (http://twitter.github.com/commons/apidocs/com/twitter/common/stats/package-summary.html)
  for exporting hedwig stats over HTTP. This is open-sourced under the Apache 
 license. The motivation for this was better logging of percentile latencies 
 and requests-per-second (which are difficult to measure with the current 
 implementation of hedwig stats). Is this something the community would be 
 interested in? If so, I could work on a patch. 
 Reviewboard : https://reviews.apache.org/r/7134/



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

[jira] [Commented] (BOOKKEEPER-398) Improving stats collection in bookkeeper


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135416#comment-14135416
 ] 

Ivan Kelly commented on BOOKKEEPER-398:
---

Removed fix version since there are no actual code changes from this jira.

 Improving stats collection in bookkeeper
 

 Key: BOOKKEEPER-398
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-398
 Project: Bookkeeper
  Issue Type: Improvement
  Components: hedwig-server
Affects Versions: 4.2.0
Reporter: Aniruddha
Assignee: Aniruddha
 Attachments: BK-398.patch


 We have been experimenting with using the Twitter stats package 
 (http://twitter.github.com/commons/apidocs/com/twitter/common/stats/package-summary.html)
  for exporting hedwig stats over HTTP. This is open-sourced under the Apache 
 license. The motivation for this was better logging of percentile latencies 
 and requests-per-second (which are difficult to measure with the current 
 implementation of hedwig stats). Is this something the community would be 
 interested in? If so, I could work on a patch. 
 Reviewboard : https://reviews.apache.org/r/7134/



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie

2014-09-16 Thread Sijie Guo (JIRA)


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135833#comment-14135833
 ] 

Sijie Guo commented on BOOKKEEPER-782:
--

I know it doesn't change the object state. but it is so weird and confusing to 
have a set* method in an immutable object.

+1 for Ivan's suggestion, you could have a method generateCookieWithBookieId.



 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

[jira] [Commented] (BOOKKEEPER-783) Avoid running out of fds in MutlipleThreadReadTest

2014-09-16 Thread Sijie Guo (JIRA)


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135836#comment-14135836
 ] 

Sijie Guo commented on BOOKKEEPER-783:
--

ping [~fpj]

 Avoid running out of fds in MutlipleThreadReadTest
 --

 Key: BOOKKEEPER-783
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-783
 Project: Bookkeeper
  Issue Type: Bug
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Sijie Guo
  Labels: test
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-783.patch


 {code}
 org.jboss.netty.channel.ChannelException: Failed to create a selector.
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.openSelector(AbstractNioSelector.java:343)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.init(AbstractNioSelector.java:100)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.init(AbstractNioWorker.java:52)
   at 
 org.jboss.netty.channel.socket.nio.NioWorker.init(NioWorker.java:45)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.createWorker(NioWorkerPool.java:45)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.createWorker(NioWorkerPool.java:28)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorkerPool.newWorker(AbstractNioWorkerPool.java:143)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorkerPool.init(AbstractNioWorkerPool.java:81)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.init(NioWorkerPool.java:39)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.init(NioWorkerPool.java:33)
   at 
 org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.init(NioClientSocketChannelFactory.java:151)
   at 
 org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.init(NioClientSocketChannelFactory.java:116)
   at org.apache.bookkeeper.client.BookKeeper.init(BookKeeper.java:204)
   at 
 org.apache.bookkeeper.client.BookKeeperTestClient.init(BookKeeperTestClient.java:50)
   at 
 org.apache.bookkeeper.test.MultipleThreadReadTest.createClients(MultipleThreadReadTest.java:73)
   at 
 org.apache.bookkeeper.test.MultipleThreadReadTest.multiLedgerMultiThreadRead(MultipleThreadReadTest.java:282)
   at 
 org.apache.bookkeeper.test.MultipleThreadReadTest.test1Ledger50ThreadsRead(MultipleThreadReadTest.java:326)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 Caused by: java.io.IOException: Too many open files
   at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
   at sun.nio.ch.EPollArrayWrapper.init(EPollArrayWrapper.java:69)
   at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:52)
   at 
 sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
   at java.nio.channels.Selector.open(Selector.java:209)
   at 
 org.jboss.netty.channel.socket.nio.SelectorUtil.open(SelectorUtil.java:63)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.openSelector(AbstractNioSelector.java:341)
 {code}



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

[jira] [Commented] (BOOKKEEPER-783) Avoid running out of fds in MutlipleThreadReadTest


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135893#comment-14135893
 ] 

Ivan Kelly commented on BOOKKEEPER-783:
---

change looks good to me. +1

 Avoid running out of fds in MutlipleThreadReadTest
 --

 Key: BOOKKEEPER-783
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-783
 Project: Bookkeeper
  Issue Type: Bug
  Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Sijie Guo
  Labels: test
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-783.patch


 {code}
 org.jboss.netty.channel.ChannelException: Failed to create a selector.
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.openSelector(AbstractNioSelector.java:343)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.init(AbstractNioSelector.java:100)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorker.init(AbstractNioWorker.java:52)
   at 
 org.jboss.netty.channel.socket.nio.NioWorker.init(NioWorker.java:45)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.createWorker(NioWorkerPool.java:45)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.createWorker(NioWorkerPool.java:28)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorkerPool.newWorker(AbstractNioWorkerPool.java:143)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioWorkerPool.init(AbstractNioWorkerPool.java:81)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.init(NioWorkerPool.java:39)
   at 
 org.jboss.netty.channel.socket.nio.NioWorkerPool.init(NioWorkerPool.java:33)
   at 
 org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.init(NioClientSocketChannelFactory.java:151)
   at 
 org.jboss.netty.channel.socket.nio.NioClientSocketChannelFactory.init(NioClientSocketChannelFactory.java:116)
   at org.apache.bookkeeper.client.BookKeeper.init(BookKeeper.java:204)
   at 
 org.apache.bookkeeper.client.BookKeeperTestClient.init(BookKeeperTestClient.java:50)
   at 
 org.apache.bookkeeper.test.MultipleThreadReadTest.createClients(MultipleThreadReadTest.java:73)
   at 
 org.apache.bookkeeper.test.MultipleThreadReadTest.multiLedgerMultiThreadRead(MultipleThreadReadTest.java:282)
   at 
 org.apache.bookkeeper.test.MultipleThreadReadTest.test1Ledger50ThreadsRead(MultipleThreadReadTest.java:326)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 Caused by: java.io.IOException: Too many open files
   at sun.nio.ch.EPollArrayWrapper.epollCreate(Native Method)
   at sun.nio.ch.EPollArrayWrapper.init(EPollArrayWrapper.java:69)
   at sun.nio.ch.EPollSelectorImpl.init(EPollSelectorImpl.java:52)
   at 
 sun.nio.ch.EPollSelectorProvider.openSelector(EPollSelectorProvider.java:18)
   at java.nio.channels.Selector.open(Selector.java:209)
   at 
 org.jboss.netty.channel.socket.nio.SelectorUtil.open(SelectorUtil.java:63)
   at 
 org.jboss.netty.channel.socket.nio.AbstractNioSelector.openSelector(AbstractNioSelector.java:341)
 {code}



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

[jira] [Commented] (BOOKKEEPER-784) BookKeeperCloseTest#testLedgerCheck is failing intermittently


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135897#comment-14135897
 ] 

Ivan Kelly commented on BOOKKEEPER-784:
---

[~hustlmsp] could you have a look at this. My opinion here is that we should 
remove the pre close parts of these tests as they are completely 
undeterministic.

 BookKeeperCloseTest#testLedgerCheck is failing intermittently
 -

 Key: BOOKKEEPER-784
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-784
 Project: Bookkeeper
  Issue Type: Bug
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 4.3.0


 *Stacktrace*
 {code}
 java.lang.AssertionError: Should have client closed exception expected:0 
 but was:-19
   at org.junit.Assert.fail(Assert.java:91)
   at org.junit.Assert.failNotEquals(Assert.java:645)
   at org.junit.Assert.assertEquals(Assert.java:126)
   at org.junit.Assert.assertEquals(Assert.java:470)
   at 
 org.apache.bookkeeper.client.BookKeeperCloseTest.testLedgerCheck(BookKeeperCloseTest.java:501)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
   at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
   at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
   at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
   at 
 org.junit.internal.runners.statements.FailOnTimeout$1.run(FailOnTimeout.java:28)
 {code}
 Link: 
 https://builds.apache.org/job/bookkeeper-trunk-precommit-build/722/testReport/junit/org.apache.bookkeeper.client/BookKeeperCloseTest/testLedgerCheck/



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135942#comment-14135942
 ] 

Ivan Kelly commented on BOOKKEEPER-782:
---

for bookie id, you should just get back the builder somehow, set it on the 
builder, and build(). it's simpler since this is only exercised from the 
conversion tool, not from a bookie itself.

 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

[jira] [Updated] (BOOKKEEPER-782) Use builder pattern for Cookie


 [ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rakesh R updated BOOKKEEPER-782:

Attachment: BOOKKEEPER-782.patch

 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136000#comment-14136000
 ] 

Rakesh R commented on BOOKKEEPER-782:
-

Attached another patch 
- used #generateCookie(String instanceId).
- modified the constructors

bq.for bookie id, you should just get back the builder somehow, set it on the 
builder, and build(). it's simpler since this is only exercised from the 
conversion tool, not from a bookie itself.
I'm thinking to have an overloaded method #generateCookie(BookieSocketAddress 
addr). Does this sounds good to you?

 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie


[ 
https://issues.apache.org/jira/browse/BOOKKEEPER-782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14136072#comment-14136072
 ] 

Hadoop QA commented on BOOKKEEPER-782:
--

Testing JIRA BOOKKEEPER-782


Patch 
[BOOKKEEPER-782.patch|https://issues.apache.org/jira/secure/attachment/12669142/BOOKKEEPER-782.patch]
 downloaded at Tue Sep 16 19:10:50 UTC 2014



{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than 
120
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT 
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc 
warnings
.{color:red}WARNING{color}: the current HEAD has 23 Javadoc warning(s)
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac 
warnings
{color:green}+1 FINDBUGS{color}
.{color:green}+1{color} the patch does not seem to introduce new Findbugs 
warnings
{color:red}-1 TESTS{color}
.Tests run: 921
.Tests failed: 0
.Tests errors: 1

.The patch failed the following testcases:

.  

{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch 


{color:red}*-1 Overall result, please check the reported -1(s)*{color}

{color:red}.   There is at least one warning, please check{color}

The full output of the test-patch run is available at

.   https://builds.apache.org/job/bookkeeper-trunk-precommit-build/734/

 Use builder pattern for Cookie
 --

 Key: BOOKKEEPER-782
 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-782
 Project: Bookkeeper
  Issue Type: Sub-task
  Components: bookkeeper-server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 4.3.0

 Attachments: BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, 
 BOOKKEEPER-782.patch, BOOKKEEPER-782.patch, BOOKKEEPER-782.patch


 It would be good to use builder pattern for Cookie, rather than modifying the 
 fields in place.



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

[jira] [Commented] (BOOKKEEPER-782) Use builder pattern for Cookie