date:20140211

See https://builds.apache.org/job/ZooKeeper-trunk-solaris/817/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 214895 lines...]
[junit] 2014-02-11 09:03:10,140 [myid:] - INFO  
[main:SyncRequestProcessor@190] - Shutting down
[junit] 2014-02-11 09:03:10,140 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop!
[junit] 2014-02-11 09:03:10,140 [myid:] - INFO  
[SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited!
[junit] 2014-02-11 09:03:10,141 [myid:] - INFO  
[main:FinalRequestProcessor@454] - shutdown of request processor complete
[junit] 2014-02-11 09:03:10,141 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-02-11 09:03:10,141 [myid:] - INFO  [main:JMXEnv@142] - 
ensureOnly:[]
[junit] 2014-02-11 09:03:10,142 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2014-02-11 09:03:10,143 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2014-02-11 09:03:10,143 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 
kB direct buffers.
[junit] 2014-02-11 09:03:10,143 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2014-02-11 09:03:10,144 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2014-02-11 09:03:10,144 [myid:] - INFO  [main:ZooKeeperServer@149] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9058145919309150998.junit.dir/version-2
 snapdir 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9058145919309150998.junit.dir/version-2
[junit] 2014-02-11 09:03:10,145 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9058145919309150998.junit.dir/version-2/snapshot.b
[junit] 2014-02-11 09:03:10,148 [myid:] - INFO  [main:FileTxnSnapLog@292] - 
Snapshotting: 0xb to 
/zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test9058145919309150998.junit.dir/version-2/snapshot.b
[junit] 2014-02-11 09:03:10,149 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-02-11 09:03:10,150 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:50045
[junit] 2014-02-11 09:03:10,150 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from 
/127.0.0.1:50045
[junit] 2014-02-11 09:03:10,151 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output
[junit] 2014-02-11 09:03:10,151 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client 
/127.0.0.1:50045 (no session established for client)
[junit] 2014-02-11 09:03:10,151 [myid:] - INFO  [main:JMXEnv@224] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2014-02-11 09:03:10,153 [myid:] - INFO  [main:JMXEnv@241] - 
expect:InMemoryDataTree
[junit] 2014-02-11 09:03:10,153 [myid:] - INFO  [main:JMXEnv@245] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2014-02-11 09:03:10,153 [myid:] - INFO  [main:JMXEnv@241] - 
expect:StandaloneServer_port
[junit] 2014-02-11 09:03:10,153 [myid:] - INFO  [main:JMXEnv@245] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-02-11 09:03:10,154 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 13366
[junit] 2014-02-11 09:03:10,154 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24
[junit] 2014-02-11 09:03:10,154 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota
[junit] 2014-02-11 09:03:10,154 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2014-02-11 09:03:10,231 [myid:] - INFO  [main:ZooKeeper@954] - 
Session: 0x144202f8863 closed
[junit] 2014-02-11 09:03:10,231 [myid:] - INFO  
[main-EventThread:ClientCnxn$EventThread@536] - EventThread shut down
[junit] 2014-02-11 09:03:10,231 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2014-02-11 09:03:10,232 [myid:] - INFO

ZooKeeper-3.4-WinVS2008_java - Build # 434 - Still Failing

See https://builds.apache.org/job/ZooKeeper-3.4-WinVS2008_java/434/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 190453 lines...]
[junit] 2014-02-11 09:31:30,126 [myid:] - INFO  
[main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@975] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2014-02-11 09:31:30,151 [myid:] - INFO  [main:JMXEnv@146] - 
ensureOnly:[]
[junit] 2014-02-11 09:31:30,152 [myid:] - INFO  [main:ClientBase@443] - 
STARTING server
[junit] 2014-02-11 09:31:30,152 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2014-02-11 09:31:30,153 [myid:] - INFO  
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2014-02-11 09:31:30,153 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2014-02-11 09:31:30,154 [myid:] - INFO  [main:ZooKeeperServer@162] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test7360451707731100522.junit.dir\version-2
 snapdir 
f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test7360451707731100522.junit.dir\version-2
[junit] 2014-02-11 09:31:30,157 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-02-11 09:31:30,157 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - 
Accepted socket connection from /127.0.0.1:64406
[junit] 2014-02-11 09:31:30,158 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing 
stat command from /127.0.0.1:64406
[junit] 2014-02-11 09:31:30,158 [myid:] - INFO  
[Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output
[junit] 2014-02-11 09:31:30,158 [myid:] - INFO  
[Thread-4:NIOServerCnxn@1007] - Closed socket connection for client 
/127.0.0.1:64406 (no session established for client)
[junit] 2014-02-11 09:31:30,159 [myid:] - INFO  [main:JMXEnv@229] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2014-02-11 09:31:30,160 [myid:] - INFO  [main:JMXEnv@246] - 
expect:InMemoryDataTree
[junit] 2014-02-11 09:31:30,161 [myid:] - INFO  [main:JMXEnv@250] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2014-02-11 09:31:30,161 [myid:] - INFO  [main:JMXEnv@246] - 
expect:StandaloneServer_port
[junit] 2014-02-11 09:31:30,161 [myid:] - INFO  [main:JMXEnv@250] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-02-11 09:31:30,161 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 9525
[junit] 2014-02-11 09:31:30,161 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 19
[junit] 2014-02-11 09:31:30,162 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota
[junit] 2014-02-11 09:31:30,162 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2014-02-11 09:31:30,631 [myid:] - INFO  
[main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@852] - Socket 
connection established to 127.0.0.1/127.0.0.1:11221, initiating session
[junit] 2014-02-11 09:31:30,631 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - 
Accepted socket connection from /127.0.0.1:64403
[junit] 2014-02-11 09:31:30,631 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@861] - Client 
attempting to renew session 0x144204970e9 at /127.0.0.1:64403
[junit] 2014-02-11 09:31:30,632 [myid:] - INFO  
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@617] - Established 
session 0x144204970e9 with negotiated timeout 3 for client 
/127.0.0.1:64403
[junit] 2014-02-11 09:31:30,632 [myid:] - INFO  
[main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1235] - Session 
establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 
0x144204970e9, negotiated timeout = 3
[junit] 2014-02-11 09:31:30,633 [myid:] - INFO  [ProcessThread(sid:0 
cport:-1)::PrepRequestProcessor@494] - Processed session termination for 
sessionid: 0x144204970e9
[junit] 2014-02-11 09:31:30,633 [myid:] - INFO  
[SyncThread:0:FileTxnLog@199] - Creating new log file: log.c
[junit] 2014-02-11 09:31:30,659 [myid:] - INFO  [main:ZooKeeper@684] - 
Session: 0x144204970e9 closed
[junit] 2014-02-11 09:31:30,659 [myid:] - INFO  [main:ClientBase@490] - 
STOPPING server
[junit] 2014-02-11 09:31:30,659 [myid:] - WARN

ZooKeeper-trunk-WinVS2008_java - Build # 680 - Still Failing

See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/680/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 254943 lines...]
[junit] 2014-02-11 10:00:34,938 [myid:] - INFO  [main:ClientBase@364] - 
CREATING server instance 127.0.0.1:11221
[junit] 2014-02-11 10:00:34,939 [myid:] - INFO  
[main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s 
sessionless connection timeout, 1 selector thread(s), 4 worker threads, and 64 
kB direct buffers.
[junit] 2014-02-11 10:00:34,940 [myid:] - INFO  
[main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221
[junit] 2014-02-11 10:00:34,941 [myid:] - INFO  [main:ClientBase@339] - 
STARTING server instance 127.0.0.1:11221
[junit] 2014-02-11 10:00:34,941 [myid:] - INFO  [main:ZooKeeperServer@149] 
- Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 
6 datadir 
f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test5235580674181574011.junit.dir\version-2
 snapdir 
f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test5235580674181574011.junit.dir\version-2
[junit] 2014-02-11 10:00:34,941 [myid:] - INFO  [main:FileSnap@83] - 
Reading snapshot 
f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test5235580674181574011.junit.dir\version-2\snapshot.b
[junit] 2014-02-11 10:00:34,943 [myid:] - INFO  [main:FileTxnSnapLog@292] - 
Snapshotting: 0xb to 
f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test5235580674181574011.junit.dir\version-2\snapshot.b
[junit] 2014-02-11 10:00:34,945 [myid:] - INFO  
[main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221
[junit] 2014-02-11 10:00:34,945 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:52857
[junit] 2014-02-11 10:00:34,946 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from 
/127.0.0.1:52857
[junit] 2014-02-11 10:00:34,946 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output
[junit] 2014-02-11 10:00:34,947 [myid:] - INFO  
[NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client 
/127.0.0.1:52857 (no session established for client)
[junit] 2014-02-11 10:00:34,947 [myid:] - INFO  [main:JMXEnv@224] - 
ensureParent:[InMemoryDataTree, StandaloneServer_port]
[junit] 2014-02-11 10:00:34,949 [myid:] - INFO  [main:JMXEnv@241] - 
expect:InMemoryDataTree
[junit] 2014-02-11 10:00:34,949 [myid:] - INFO  [main:JMXEnv@245] - 
found:InMemoryDataTree 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree
[junit] 2014-02-11 10:00:34,949 [myid:] - INFO  [main:JMXEnv@241] - 
expect:StandaloneServer_port
[junit] 2014-02-11 10:00:34,949 [myid:] - INFO  [main:JMXEnv@245] - 
found:StandaloneServer_port 
org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-02-11 10:00:34,950 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 13236
[junit] 2014-02-11 10:00:34,950 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 23
[junit] 2014-02-11 10:00:34,950 [myid:] - INFO  
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota
[junit] 2014-02-11 10:00:34,950 [myid:] - INFO  [main:ClientBase@520] - 
tearDown starting
[junit] 2014-02-11 10:00:34,968 [myid:] - INFO  
[main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1101] - Opening socket 
connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to 
authenticate using SASL (unknown error)
[junit] 2014-02-11 10:00:34,968 [myid:] - INFO  
[main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@971] - Socket 
connection established to 127.0.0.1/127.0.0.1:11221, initiating session
[junit] 2014-02-11 10:00:34,968 [myid:] - INFO  
[NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296]
 - Accepted socket connection from /127.0.0.1:52858
[junit] 2014-02-11 10:00:34,969 [myid:] - INFO  
[NIOWorkerThread-2:ZooKeeperServer@858] - Client attempting to renew session 
0x144206410a3 at /127.0.0.1:52858
[junit] 2014-02-11 10:00:34,970 [myid:] - INFO  
[NIOWorkerThread-2:ZooKeeperServer@604] - Established session 0x144206410a3 
with negotiated timeout 3 for client /127.0.0.1:52858
[junit] 2014-02-11 10:00:34,970 [myid:] - INFO  
[main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1354] - Session 
establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 
0x144206410a3, negotiated timeout = 3
[junit] 2014-02-11 10:00:34,971 [myid:] - INFO  [ProcessThread(sid:0

[jira] [Commented] (ZOOKEEPER-1811) The ZooKeeperSaslClient service name principal is hardcoded to zookeeper


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

Hudson commented on ZOOKEEPER-1811:
---

SUCCESS: Integrated in ZooKeeper-trunk #2212 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/2212/])
ZOOKEEPER-1811. The ZooKeeperSaslClient service name principal is hardcoded to 
zookeeper (Harsh J via phunt) (phunt: 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1566748)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/java/main/org/apache/zookeeper/ClientCnxn.java


 The ZooKeeperSaslClient service name principal is hardcoded to zookeeper
 --

 Key: ZOOKEEPER-1811
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1811
 Project: ZooKeeper
  Issue Type: Bug
  Components: java client
Affects Versions: 3.4.5
Reporter: Harsh J
Assignee: Harsh J
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1811.patch


 The ClientCnxn class in ZK instantiates the ZooKeeperSaslClient with a 
 hardcoded service name of zookeeper. This causes all apps to fail in 
 accessing ZK in a secure environment where the administrator has changed the 
 principal name ZooKeeper runs as.
 The service name should be configurable.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1573) Unable to load database due to missing parent node


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

Hudson commented on ZOOKEEPER-1573:
---

SUCCESS: Integrated in ZooKeeper-trunk #2212 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/2212/])
ZOOKEEPER-1573. Unable to load database due to missing parent node (Vinayakumar 
B via phunt, fpj) (phunt: 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1566739)
* /zookeeper/trunk/CHANGES.txt
* 
/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java
* /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/LoadFromLogTest.java


 Unable to load database due to missing parent node
 --

 Key: ZOOKEEPER-1573
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1573
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.4.3, 3.5.0
Reporter: Thawan Kooburat
Assignee: Vinayakumar B
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1573-3.4.patch, ZOOKEEPER-1573.patch, 
 ZOOKEEPER-1573.patch, ZOOKEEPER-1573.patch, ZOOKEEPER-1573.patch


 While replaying txnlog on data tree, the server has a code to detect missing 
 parent node. This code block was last modified as part of ZOOKEEPER-1333. In 
 our production, we found a case where this check is return false positive.
 The sequence of txns is as follows:
 zxid 1:  create /prefix/a
 zxid 2:  create /prefix/a/b
 zxid 3:  delete /prefix/a/b
 zxid 4:  delete /prefix/a
 The server start capturing snapshot at zxid 1. However, by the time it 
 traversing the data tree down to /prefix, txn 4 is already applied and 
 /prefix have no children. 
 When the server restore from snapshot, it process txnlog starting from zxid 
 2. This txn generate missing parent error and the server refuse to start up.
 The same check allow me to discover bug in ZOOKEEPER-1551, but I don't know 
 if we have any option beside removing this check to solve this issue.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1879) improve the correctness checking of txn log replay

2014-02-11 Thread Flavio Junqueira (JIRA)


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

Flavio Junqueira commented on ZOOKEEPER-1879:
-

My comment in ZOOKEEPER-1573 was more along the lines of checking the concrete 
case of a node not existing because it is deleted later in the txn log and the 
snapshot has already incorporated it. I think we can have such a check inlined.

A consistency checker would be nice so that we can do overall checks, but I see 
the goal of a consistency being different than the one of the inline check I'm 
mentioning.

 improve the correctness checking of txn log replay
 --

 Key: ZOOKEEPER-1879
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1879
 Project: ZooKeeper
  Issue Type: Improvement
  Components: server
Affects Versions: 3.4.6, 3.5.0
Reporter: Patrick Hunt
 Fix For: 3.4.7, 3.5.0


 In ZOOKEEPER-1573 we decided to fix an issue by relaxing some of the 
 checking. Specifically when the sequence of txns is as follows:
 * zxid 1: create /prefix/a
 * zxid 2: create /prefix/a/b
 * zxid 3: delete /prefix/a/b
 * zxid 4: delete /prefix/a
 the log may fail to replay.
 We addressed this by relaxing a check, which is essentially invalid for this 
 case, but is important in finding corruptions of the datastore.
 We should add this check back with proper validation of correctness.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1872) QuorumPeer is not shutdown in few cases

2014-02-11 Thread Patrick Hunt (JIRA)


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

Patrick Hunt commented on ZOOKEEPER-1872:
-

Perhaps create a new jira specifically to address this on trunk? That way you 
can close this (easier accounting). I'd suggest fixing it on trunk asap though, 
before we lose track of it.

 QuorumPeer is not shutdown in few cases
 ---

 Key: ZOOKEEPER-1872
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1872
 Project: ZooKeeper
  Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 3.4.6, 3.5.0

 Attachments: LeaderSessionTrackerTest-output.txt, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872_br3_4.patch, ZOOKEEPER-1872_br3_4.patch, 
 stack-trace.txt


 Few cases are leaving quorumpeer running after the test case execution. Needs 
 proper teardown for these.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Created] (ZOOKEEPER-1880) GarbageCollectorIT runs with miniDfs, only not really

2014-02-11 Thread Eric Newton (JIRA)

Eric Newton created ZOOKEEPER-1880:
--

 Summary: GarbageCollectorIT runs with miniDfs, only not really
 Key: ZOOKEEPER-1880
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1880
 Project: ZooKeeper
  Issue Type: Bug
  Components: tests
Reporter: Eric Newton
Assignee: Eric Newton
Priority: Trivial


{{useMiniDfs()}} is a getter, not a setter




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (ZOOKEEPER-1861) ConcurrentHashMap isn't used properly in QuorumCnxManager

2014-02-11 Thread Ted Yu (JIRA)


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

Ted Yu updated ZOOKEEPER-1861:
--

Attachment: zookeeper-1861-v3.txt

How about patch v3 ?

 ConcurrentHashMap isn't used properly in QuorumCnxManager
 -

 Key: ZOOKEEPER-1861
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1861
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: zookeeper-1861-v1.txt, zookeeper-1861-v2.txt, 
 zookeeper-1861-v3.txt


 queueSendMap is a ConcurrentHashMap.
 At line 210:
 {code}
 if (!queueSendMap.containsKey(sid)) {
 queueSendMap.put(sid, new ArrayBlockingQueueByteBuffer(
 SEND_CAPACITY));
 {code}
 By the time control enters if block, there may be another concurrent put with 
 same sid to the ConcurrentHashMap.
 putIfAbsent() should be used.
 Similar issue occurs at line 307 as well.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (ZOOKEEPER-1751) ClientCnxn#run could miss the second ping or connection get dropped before a ping

2014-02-11 Thread Michael Bellomo (JIRA)


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

Michael Bellomo updated ZOOKEEPER-1751:
---

Affects Version/s: 3.3.5

We're currently using version 3.3.5 and are seeing this bug.  

Would it be possible to get a patch for the 3.3.x version for this fix?

 ClientCnxn#run could miss the second ping or connection get dropped before a 
 ping
 -

 Key: ZOOKEEPER-1751
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1751
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.3.5, 3.4.5
Reporter: Jeffrey Zhong
Assignee: Jeffrey Zhong
 Fix For: 3.4.6, 3.5.0

 Attachments: zookeeper-1751.patch


 We could throw SessionTimeoutException exception even when timeToNextPing may 
 also be negative depending on the time when the following line is executed by 
 the thread because we check time out before sending a ping.
 {code}
   to = readTimeout - clientCnxnSocket.getIdleRecv();
 {code}
 In addition, we only ping twice no matter how long the session time out value 
 is. For example, we set session time out = 60mins then we only try ping twice 
 in 40mins window. Therefore, the connection could be dropped by OS after idle 
 time out.
 The issue is causing randomly connection loss or session expired issues 
 in client side which is bad for applications like HBase.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Failed: ZOOKEEPER-1861 PreCommit Build #1923

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

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 275669 lines...]
 [exec] 
 [exec] -1 overall.  Here are the results of testing the latest attachment 
 [exec]   
http://issues.apache.org/jira/secure/attachment/12628301/zookeeper-1861-v3.txt
 [exec]   against trunk revision 1566748.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] -1 tests included.  The patch doesn't appear to include any new 
or modified tests.
 [exec] Please justify why no new tests are needed 
for this patch.
 [exec] Also please list what manual steps were 
performed to verify this patch.
 [exec] 
 [exec] +1 javadoc.  The javadoc tool did not generate any warning 
messages.
 [exec] 
 [exec] +1 javac.  The applied patch does not increase the total number 
of javac compiler warnings.
 [exec] 
 [exec] +1 findbugs.  The patch does not introduce any new Findbugs 
(version 1.3.9) warnings.
 [exec] 
 [exec] +1 release audit.  The applied patch does not increase the 
total number of release audit warnings.
 [exec] 
 [exec] +1 core tests.  The patch passed core unit tests.
 [exec] 
 [exec] +1 contrib tests.  The patch passed contrib unit tests.
 [exec] 
 [exec] Test results: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1923//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1923//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1923//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] df3bb6e97f7f6fdda8a4e6dee66a5c65fced15b9 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:1674:
 exec returned: 1

Total time: 35 minutes 42 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Description set: ZOOKEEPER-1861
Email was triggered for: Failure
Sending email for trigger: Failure



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

[jira] [Commented] (ZOOKEEPER-1861) ConcurrentHashMap isn't used properly in QuorumCnxManager

2014-02-11 Thread Hadoop QA (JIRA)

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

Hadoop QA commented on ZOOKEEPER-1861:
--

-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12628301/zookeeper-1861-v3.txt
against trunk revision 1566748.

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

-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.

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

+1 javac. The applied patch does not increase the total number of javac
compiler warnings.

+1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9)
warnings.

+1 release audit. The applied patch does not increase the total number of
release audit warnings.

+1 core tests. The patch passed core unit tests.

+1 contrib tests. The patch passed contrib unit tests.

Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1923//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1923//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1923//console

This message is automatically generated.

ConcurrentHashMap isn't used properly in QuorumCnxManager
-

Key: ZOOKEEPER-1861
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1861
Project: ZooKeeper
Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
Attachments: zookeeper-1861-v1.txt, zookeeper-1861-v2.txt,
zookeeper-1861-v3.txt

queueSendMap is a ConcurrentHashMap.
At line 210:
{code}
if (!queueSendMap.containsKey(sid)) {
queueSendMap.put(sid, new ArrayBlockingQueueByteBuffer(
SEND_CAPACITY));
{code}
By the time control enters if block, there may be another concurrent put with
same sid to the ConcurrentHashMap.
putIfAbsent() should be used.
Similar issue occurs at line 307 as well.

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (ZOOKEEPER-1077) C client lib doesn't build on Solaris


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

Michi Mutsuzaki updated ZOOKEEPER-1077:
---

Fix Version/s: (was: 3.4.6)
   3.4.7

 C client lib doesn't build on Solaris
 -

 Key: ZOOKEEPER-1077
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1077
 Project: ZooKeeper
  Issue Type: Bug
  Components: build, c client
Affects Versions: 3.3.4
 Environment: uname -a: SunOS [redacted] 5.10 Generic_142910-17 i86pc 
 i386 i86pc
 GNU toolchain (gcc 3.4.3, GNU Make etc.)
Reporter: Tadeusz Andrzej Kadłubowski
Assignee: Justin SB
Priority: Critical
 Fix For: 3.4.7, 3.5.0

 Attachments: zookeeper.patch


 Hello,
 Some minor trouble with building ZooKeeper C client library on 
 Sun^H^H^HOracle Solaris 5.10.
 1. You need to link against -lnsl -lsocket
 2. ctime_r needs a buffer size. The signature is: char *ctime_r(const time_t 
 *clock, char *buf, int buflen)
 3. In zk_log.c you need to manually cast pid_t to int (-Werror can be 
 cumbersome ;) )
 4. getpwuid_r()returns pointer to struct passwd, which works as the last 
 parameter on Linux.
 Solaris signature: struct passwd *getpwuid_r(uid_t  uid,  struct  passwd  
 *pwd, char *buffer, int  buflen); 
 Linux signature: int getpwuid_r(uid_t uid, struct passwd *pwd, char *buf, 
 size_t buflen, struct passwd **result);



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1077) C client lib doesn't build on Solaris


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

Michi Mutsuzaki commented on ZOOKEEPER-1077:


I'm moving this to 3.4.7.

 C client lib doesn't build on Solaris
 -

 Key: ZOOKEEPER-1077
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1077
 Project: ZooKeeper
  Issue Type: Bug
  Components: build, c client
Affects Versions: 3.3.4
 Environment: uname -a: SunOS [redacted] 5.10 Generic_142910-17 i86pc 
 i386 i86pc
 GNU toolchain (gcc 3.4.3, GNU Make etc.)
Reporter: Tadeusz Andrzej Kadłubowski
Assignee: Justin SB
Priority: Critical
 Fix For: 3.4.7, 3.5.0

 Attachments: zookeeper.patch


 Hello,
 Some minor trouble with building ZooKeeper C client library on 
 Sun^H^H^HOracle Solaris 5.10.
 1. You need to link against -lnsl -lsocket
 2. ctime_r needs a buffer size. The signature is: char *ctime_r(const time_t 
 *clock, char *buf, int buflen)
 3. In zk_log.c you need to manually cast pid_t to int (-Werror can be 
 cumbersome ;) )
 4. getpwuid_r()returns pointer to struct passwd, which works as the last 
 parameter on Linux.
 Solaris signature: struct passwd *getpwuid_r(uid_t  uid,  struct  passwd  
 *pwd, char *buffer, int  buflen); 
 Linux signature: int getpwuid_r(uid_t uid, struct passwd *pwd, char *buf, 
 size_t buflen, struct passwd **result);



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

Re: Status of 3.4.6

2014-02-11 Thread Michi Mutsuzaki

Should we move ZOOKEEPER-1833 to 3.4.7 now and get 3.4.6 out?

On Sat, Jan 11, 2014 at 3:17 PM, Michi Mutsuzaki mi...@cs.stanford.edu wrote:
 +1

 On Sat, Jan 11, 2014 at 10:18 AM, Patrick Hunt ph...@apache.org wrote:
 +1, great idea re setting a deadline now that we're close (keep in
 mind we an always do further fix releases). Kudos on the windows work,
 love to see it!

 Patrick

 On Sat, Jan 11, 2014 at 9:40 AM, Camille Fournier cami...@apache.org wrote:
 +1
 On Jan 11, 2014 10:18 AM, Flavio Junqueira fpjunque...@yahoo.com wrote:

 We only have one blocker for 3.4.6 now which is ZOOKEEPER-1833. I'd like
 to get the windows build to pass on jenkins, and we have made a lot of
 progress already. Although we have focused on the windows build, most of
 the changes were small bugs that don't manifest as easily in other
 platforms, so it has been a chance to clean up the test cases. Thanks a lot
 for the great community work, Germán, Rakesh, Michi et al.

 To avoid postponing the 3.4.6 release even further, it sounds like a good
 idea to put a deadline on ZOOKEEPER-1833. I would say that if we don't have
 ZOOKEEPER-1833 done by the end of January, we should cut a release and push
 some of the work to 3.4.7. Any concern here?

 -Flavio

Re: Status of 3.4.6

2014-02-11 Thread Camille Fournier

Yeah I think we should put a bullet in this.


On Tue, Feb 11, 2014 at 7:56 PM, Michi Mutsuzaki mi...@cs.stanford.eduwrote:

 Should we move ZOOKEEPER-1833 to 3.4.7 now and get 3.4.6 out?

 On Sat, Jan 11, 2014 at 3:17 PM, Michi Mutsuzaki mi...@cs.stanford.edu
 wrote:
  +1
 
  On Sat, Jan 11, 2014 at 10:18 AM, Patrick Hunt ph...@apache.org wrote:
  +1, great idea re setting a deadline now that we're close (keep in
  mind we an always do further fix releases). Kudos on the windows work,
  love to see it!
 
  Patrick
 
  On Sat, Jan 11, 2014 at 9:40 AM, Camille Fournier cami...@apache.org
 wrote:
  +1
  On Jan 11, 2014 10:18 AM, Flavio Junqueira fpjunque...@yahoo.com
 wrote:
 
  We only have one blocker for 3.4.6 now which is ZOOKEEPER-1833. I'd
 like
  to get the windows build to pass on jenkins, and we have made a lot of
  progress already. Although we have focused on the windows build, most
 of
  the changes were small bugs that don't manifest as easily in other
  platforms, so it has been a chance to clean up the test cases. Thanks
 a lot
  for the great community work, Germán, Rakesh, Michi et al.
 
  To avoid postponing the 3.4.6 release even further, it sounds like a
 good
  idea to put a deadline on ZOOKEEPER-1833. I would say that if we
 don't have
  ZOOKEEPER-1833 done by the end of January, we should cut a release
 and push
  some of the work to 3.4.7. Any concern here?
 
  -Flavio

[jira] [Resolved] (ZOOKEEPER-1179) NettyServerCnxn does not properly close socket on 4 letter word requests


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

Michi Mutsuzaki resolved ZOOKEEPER-1179.


  Resolution: Fixed
Release Note: Thanks Rakesh, you are right, this error is not happening 
anymore. Flavio, I'm closing this.

 NettyServerCnxn does not properly close socket on 4 letter word requests
 

 Key: ZOOKEEPER-1179
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1179
 Project: ZooKeeper
  Issue Type: Bug
  Components: server
Affects Versions: 3.4.0
Reporter: Camille Fournier
Assignee: Rakesh R
Priority: Critical
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1179.patch, ZOOKEEPER-1179.patch, 
 ZOOKEEPER-1179.patch


 When calling a 4-letter-word to a server configured to use 
 NettyServerCnxnFactory, the factory will not properly cancel all the keys and 
 close the socket after sending the response for the 4lw. The close request 
 will throw this exception, and the thread will not shut down:
 2011-09-13 12:14:17,546 - WARN  [New I/O server worker 
 #1-1:NettyServerCnxnFactory$CnxnChannelHandler@117] - Exception caught [id: 
 0x009300cc, /1.1.1.1:38542 = /139.172.114.138:2181] EXCEPTION: 
 java.io.IOException: A non-blocking socket operation could not be completed 
 immediately
 java.io.IOException: A non-blocking socket operation could not be completed 
 immediately
   at sun.nio.ch.SocketDispatcher.close0(Native Method)
   at sun.nio.ch.SocketDispatcher.preClose(SocketDispatcher.java:44)
   at 
 sun.nio.ch.SocketChannelImpl.implCloseSelectableChannel(SocketChannelImpl.java:684)
   at 
 java.nio.channels.spi.AbstractSelectableChannel.implCloseChannel(AbstractSelectableChannel.java:201)
   at 
 java.nio.channels.spi.AbstractInterruptibleChannel.close(AbstractInterruptibleChannel.java:97)
   at 
 org.jboss.netty.channel.socket.nio.NioWorker.close(NioWorker.java:593)
   at 
 org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.handleAcceptedSocket(NioServerSocketPipelineSink.java:119)
   at 
 org.jboss.netty.channel.socket.nio.NioServerSocketPipelineSink.eventSunk(NioServerSocketPipelineSink.java:76)
   at org.jboss.netty.channel.Channels.close(Channels.java:720)
   at 
 org.jboss.netty.channel.AbstractChannel.close(AbstractChannel.java:208)
   at 
 org.apache.zookeeper.server.NettyServerCnxn.close(NettyServerCnxn.java:116)
   at 
 org.apache.zookeeper.server.NettyServerCnxn.cleanupWriterSocket(NettyServerCnxn.java:241)
   at 
 org.apache.zookeeper.server.NettyServerCnxn.access$0(NettyServerCnxn.java:231)
   at 
 org.apache.zookeeper.server.NettyServerCnxn$CommandThread.run(NettyServerCnxn.java:314)
   at 
 org.apache.zookeeper.server.NettyServerCnxn$CommandThread.start(NettyServerCnxn.java:305)
   at 
 org.apache.zookeeper.server.NettyServerCnxn.checkFourLetterWord(NettyServerCnxn.java:674)
   at 
 org.apache.zookeeper.server.NettyServerCnxn.receiveMessage(NettyServerCnxn.java:791)
   at 
 org.apache.zookeeper.server.NettyServerCnxnFactory$CnxnChannelHandler.processMessage(NettyServerCnxnFactory.java:217)
   at 
 org.apache.zookeeper.server.NettyServerCnxnFactory$CnxnChannelHandler.messageReceived(NettyServerCnxnFactory.java:141)
   at 
 org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)
   at 
 org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)
   at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:350)
   at 
 org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:281)
   at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:201)
   at 
 org.jboss.netty.util.internal.IoWorkerRunnable.run(IoWorkerRunnable.java:46)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   at java.lang.Thread.run(Thread.java:619)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1874) Add proper teardown/cleanups in ReconfigTest to shutdown quorumpeer


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

Michi Mutsuzaki commented on ZOOKEEPER-1874:


+1 Thank you Rakesh and Germán.

 Add proper teardown/cleanups in ReconfigTest to shutdown quorumpeer
 ---

 Key: ZOOKEEPER-1874
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1874
 Project: ZooKeeper
  Issue Type: Sub-task
  Components: tests
Reporter: Rakesh R
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1874.patch, ZOOKEEPER-1874.patch


 This jira to provide proper cleanups in ReconfigTest test cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1861) ConcurrentHashMap isn't used properly in QuorumCnxManager

2014-02-11 Thread Camille Fournier (JIRA)


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

Camille Fournier commented on ZOOKEEPER-1861:
-

Need to fix the formatting on that new method. Other than that, looks ok to me.


 ConcurrentHashMap isn't used properly in QuorumCnxManager
 -

 Key: ZOOKEEPER-1861
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1861
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: zookeeper-1861-v1.txt, zookeeper-1861-v2.txt, 
 zookeeper-1861-v3.txt


 queueSendMap is a ConcurrentHashMap.
 At line 210:
 {code}
 if (!queueSendMap.containsKey(sid)) {
 queueSendMap.put(sid, new ArrayBlockingQueueByteBuffer(
 SEND_CAPACITY));
 {code}
 By the time control enters if block, there may be another concurrent put with 
 same sid to the ConcurrentHashMap.
 putIfAbsent() should be used.
 Similar issue occurs at line 307 as well.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1873) Unnecessarily InstanceNotFoundException is coming when unregister failed jmxbeans


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

Michi Mutsuzaki commented on ZOOKEEPER-1873:


+1 Thanks Rakesh.

 Unnecessarily InstanceNotFoundException is coming when unregister failed 
 jmxbeans
 -

 Key: ZOOKEEPER-1873
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1873
 Project: ZooKeeper
  Issue Type: Sub-task
  Components: server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1873.patch


 MBeanRegistry#register is keeping the beans which are failed to complete the 
 registration. During unregistration time, these failed beans will results in 
 following exception.
 {code}
 [junit] 2014-01-29 08:34:56,667 [myid:] - WARN  [main:MBeanRegistry@134] 
 - Error during unregister
 [junit] javax.management.InstanceNotFoundException: 
 org.apache.ZooKeeperService:name0=StandaloneServer_port-1
 [junit]   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
 [junit]   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
 [junit]   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
 [junit]   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:536)
 [junit]   at 
 org.apache.zookeeper.jmx.MBeanRegistry.unregister(MBeanRegistry.java:115)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1861) ConcurrentHashMap isn't used properly in QuorumCnxManager

2014-02-11 Thread Camille Fournier (JIRA)


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

Camille Fournier commented on ZOOKEEPER-1861:
-

Actually, I'm going to go back on this. The whole point of using a concurrent 
data structure is so we don't synchronize on this operation. Which means we 
have to allocate potentially unnecessarily.
I prefer patch v2. If you really want to try and not worry about allocation, 
check for existence, then create, and put if not absent, but meh. I don't know 
that I care about an (unlikely) extra allocation.

 ConcurrentHashMap isn't used properly in QuorumCnxManager
 -

 Key: ZOOKEEPER-1861
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1861
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: zookeeper-1861-v1.txt, zookeeper-1861-v2.txt, 
 zookeeper-1861-v3.txt


 queueSendMap is a ConcurrentHashMap.
 At line 210:
 {code}
 if (!queueSendMap.containsKey(sid)) {
 queueSendMap.put(sid, new ArrayBlockingQueueByteBuffer(
 SEND_CAPACITY));
 {code}
 By the time control enters if block, there may be another concurrent put with 
 same sid to the ConcurrentHashMap.
 putIfAbsent() should be used.
 Similar issue occurs at line 307 as well.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1874) Add proper teardown/cleanups in ReconfigTest to shutdown quorumpeer


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

Hudson commented on ZOOKEEPER-1874:
---

SUCCESS: Integrated in ZooKeeper-trunk #2213 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/2213/])
ZOOKEEPER-1874 Add proper teardown/cleanups in ReconfigTest to shutdown 
quorumpeer (Rakesh R and Germán Blanco via michim) (michim: 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1567488)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ReconfigTest.java


 Add proper teardown/cleanups in ReconfigTest to shutdown quorumpeer
 ---

 Key: ZOOKEEPER-1874
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1874
 Project: ZooKeeper
  Issue Type: Sub-task
  Components: tests
Reporter: Rakesh R
 Fix For: 3.5.0

 Attachments: ZOOKEEPER-1874.patch, ZOOKEEPER-1874.patch


 This jira to provide proper cleanups in ReconfigTest test cases.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1869) zk server falling apart from quorum due to connection loss and couldn't connect back

2014-02-11 Thread Deepak Jagtap (JIRA)

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

Deepak Jagtap commented on ZOOKEEPER-1869:
--

Hi German,

I observed another instance where zookeeper cluster is falling apart.
But in this case leader election was happening in loop every couple of minutes.
While in the previous case leader election never completed for almost 3-4 days.
I am using bit older revision of zookeeper 3.5.0 (released some time in March),
any idea if there any fixes related to these bugs.

Please find more description this issue:
I have 3 node zookeeper 3.5.0.1458648 quorum on my setup.
We came across a situation where one of the zk server in the cluster went down
due to bad disk.
We observed that leader election keeps running in loop (starts, completes and
again starts). The loop repeats every couple of minutes. Even restarting
zookeeper server on both nodes doesn't help recovering from this loop.
Network connection looks fine though, as I could telnet leader election port
and ssh from one node to other.
zookeeper client on each node is using 127.0.0.1:2181 as quorum string for
connecting to server, therefore if local zookeeper server is down client app is
dead.

I have uploaded zookeeper.log for both nodes at following link:
https://dl.dropboxusercontent.com/u/36429721/zkSupportLog.tar.gz

Any idea what might be wrong with the quorum? Please note that restarting
zookeeper server on both nodes doesn't help to recover from this situations.

Thanks Regards,
Deepak

zk server falling apart from quorum due to connection loss and couldn't
connect back

Key: ZOOKEEPER-1869
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1869
Project: ZooKeeper
Issue Type: Bug
Components: quorum
Affects Versions: 3.5.0
Environment: Using CentOS6 for running these zookeeper servers
Reporter: Deepak Jagtap
Priority: Critical

We have deployed zookeeper version 3.5.0.1515976, with 3 zk servers in the
quorum.
The problem we are facing is that one zookeeper server in the quorum falls
apart, and never becomes part of the cluster until we restart zookeeper
server on that node.
Our interpretation from zookeeper logs on all nodes is as follows:
(For simplicity assume S1= zk server1, S2 = zk server2, S3 = zk server 3)
Initially S3 is the leader while S1 and S2 are followers.
S2 hits 46 sec latency while fsyncing write ahead log and results in loss of
connection with S3.
S3 in turn prints following error message:
Unexpected exception causing shutdown while sock still open
java.net.SocketTimeoutException: Read timed out
Stack trace
*** GOODBYE /169.254.1.2:47647(S2)
S2 in this case closes connection with S3(leader) and shuts down follower
with following log messages:
Closing connection to leader, exception during packet send
java.net.SocketException: Socket close
Follower@194] - shutdown called
java.lang.Exception: shutdown Follower
After this point S3 could never reestablish connection with S2 and leader
election mechanism keeps failing. S3 now keeps printing following message
repeatedly:
Cannot open channel to 2 at election address /169.254.1.2:3888
java.net.ConnectException: Connection refused.
While S3 is in this state, S2 repeatedly keeps printing following message:
INFO
[NIOServerCxnFactory.AcceptThread:/0.0.0.0:2181:NIOServerCnxnFactory$AcceptThread@296]
- Accepted socket connection from /127.0.0.1:60667
Exception causing close of session 0x0: ZooKeeperServer not running
Closed socket connection for client /127.0.0.1:60667 (no session established
for client)
Leader election never completes successfully and causing S2 to fall apart
from the quorum.
S2 was out of quorum for almost 1 week.
While debugging this issue, we found out that both election and peer
connection ports on S2 can't be telneted from any of the node (S1, S2, S3).
Network connectivity is not the issue. Later, we restarted the ZK server S2
(service zookeeper-server restart) -- now we could telnet to both the ports
and S2 joined the ensemble after a leader election attempt.
Any idea what might be forcing S2 to get into a situation where it won't
accept any connections on the leader election and peer connection ports?

--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (ZOOKEEPER-1872) QuorumPeer is not shutdown in few cases


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

Michi Mutsuzaki updated ZOOKEEPER-1872:
---

Fix Version/s: (was: 3.4.6)
   3.4.7

 QuorumPeer is not shutdown in few cases
 ---

 Key: ZOOKEEPER-1872
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1872
 Project: ZooKeeper
  Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
  Labels: test
 Fix For: 3.4.7, 3.5.0

 Attachments: LeaderSessionTrackerTest-output.txt, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, ZOOKEEPER-1872.patch, 
 ZOOKEEPER-1872.patch, ZOOKEEPER-1872_br3_4.patch, ZOOKEEPER-1872_br3_4.patch, 
 stack-trace.txt


 Few cases are leaving quorumpeer running after the test case execution. Needs 
 proper teardown for these.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Updated] (ZOOKEEPER-1866) ClientBase#createClient is failing frequently


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

Michi Mutsuzaki updated ZOOKEEPER-1866:
---

Fix Version/s: (was: 3.4.6)
   3.4.7

 ClientBase#createClient is failing frequently
 -

 Key: ZOOKEEPER-1866
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1866
 Project: ZooKeeper
  Issue Type: Sub-task
  Components: tests
Affects Versions: 3.4.5
Reporter: Rakesh R
Assignee: Germán Blanco
 Fix For: 3.4.7

 Attachments: ZOOKEEPER-1866.patch


 Following failure pattern has been observed many times in windows build. 
 After creating the zookeeper client, the respective connection bean is not 
 available in the jmx beans and is failing the tests.
 {code}
 [junit] 2014-01-22 08:58:22,625 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testInvalidVersion
 [junit] junit.framework.AssertionFailedError: expected 
 [0x143b92b0333] expected:1 but was:0
 [junit]   at junit.framework.Assert.fail(Assert.java:47)
 [junit]   at junit.framework.Assert.failNotEquals(Assert.java:283)
 [junit]   at junit.framework.Assert.assertEquals(Assert.java:64)
 [junit]   at junit.framework.Assert.assertEquals(Assert.java:195)
 [junit]   at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:124)
 [junit]   at 
 org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:191)
 [junit]   at 
 org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171)
 [junit]   at 
 org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156)
 [junit]   at 
 org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149)
 [junit]   at 
 org.apache.zookeeper.test.MultiTransactionTest.setUp(MultiTransactionTest.java:60)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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


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

Michi Mutsuzaki updated ZOOKEEPER-1833:
---

Fix Version/s: (was: 3.4.6)
   3.4.7

 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 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testMultiToFollower
 [junit] 2013-12-06 10:07:55,361 [myid:] -

[jira] [Updated] (ZOOKEEPER-1868) Server not coming back up in QuorumZxidSyncTest


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

Michi Mutsuzaki updated ZOOKEEPER-1868:
---

Fix Version/s: (was: 3.4.6)
   3.4.7

 Server not coming back up in QuorumZxidSyncTest
 ---

 Key: ZOOKEEPER-1868
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1868
 Project: ZooKeeper
  Issue Type: Sub-task
Reporter: Flavio Junqueira
 Fix For: 3.4.7

 Attachments: QuorumZxidSyncTest-output.txt


 We got this stack trace:
 {noformat}
 [junit] 2014-01-27 09:14:08,481 [myid:] - INFO  [main:ZKTestCase$1@65] - 
 FAILED testLateLogs
 [junit] java.lang.AssertionError: waiting for server up
 [junit]   at org.junit.Assert.fail(Assert.java:91)
 [junit]   at org.junit.Assert.assertTrue(Assert.java:43)
 [junit]   at 
 org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:188)
 [junit]   at 
 org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:113)
 [junit]   at 
 org.apache.zookeeper.test.QuorumZxidSyncTest.testLateLogs(QuorumZxidSyncTest.java:116)
 {noformat}
 which occurs here, when we stop the servers and restart them.
 {noformat}
 qb.shutdownServers();
 qb.startServers();
 {noformat}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1873) Unnecessarily InstanceNotFoundException is coming when unregister failed jmxbeans


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

Hudson commented on ZOOKEEPER-1873:
---

SUCCESS: Integrated in ZooKeeper-trunk #2214 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/2214/])
ZOOKEEPER-1873. Unnecessarily InstanceNotFoundException is coming when 
unregister failed jmxbeans (Rakesh R via michim) (michim: 
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1567489)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/java/main/org/apache/zookeeper/jmx/MBeanRegistry.java


 Unnecessarily InstanceNotFoundException is coming when unregister failed 
 jmxbeans
 -

 Key: ZOOKEEPER-1873
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1873
 Project: ZooKeeper
  Issue Type: Sub-task
  Components: server
Reporter: Rakesh R
Assignee: Rakesh R
 Fix For: 3.4.6, 3.5.0

 Attachments: ZOOKEEPER-1873.patch


 MBeanRegistry#register is keeping the beans which are failed to complete the 
 registration. During unregistration time, these failed beans will results in 
 following exception.
 {code}
 [junit] 2014-01-29 08:34:56,667 [myid:] - WARN  [main:MBeanRegistry@134] 
 - Error during unregister
 [junit] javax.management.InstanceNotFoundException: 
 org.apache.ZooKeeperService:name0=StandaloneServer_port-1
 [junit]   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
 [junit]   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
 [junit]   at 
 com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
 [junit]   at 
 com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:536)
 [junit]   at 
 org.apache.zookeeper.jmx.MBeanRegistry.unregister(MBeanRegistry.java:115)
 {code}



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

[jira] [Commented] (ZOOKEEPER-1861) ConcurrentHashMap isn't used properly in QuorumCnxManager

2014-02-11 Thread Ted Yu (JIRA)


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

Ted Yu commented on ZOOKEEPER-1861:
---

bq. I prefer patch v2

I agree.

Patch v3 basically makes the map a HashMap.

bq. then create, and put if not absent

I guess you meant 'put if absent'

The chance of extra allocation should be low.

 ConcurrentHashMap isn't used properly in QuorumCnxManager
 -

 Key: ZOOKEEPER-1861
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1861
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Ted Yu
Assignee: Ted Yu
Priority: Minor
 Attachments: zookeeper-1861-v1.txt, zookeeper-1861-v2.txt, 
 zookeeper-1861-v3.txt


 queueSendMap is a ConcurrentHashMap.
 At line 210:
 {code}
 if (!queueSendMap.containsKey(sid)) {
 queueSendMap.put(sid, new ArrayBlockingQueueByteBuffer(
 SEND_CAPACITY));
 {code}
 By the time control enters if block, there may be another concurrent put with 
 same sid to the ConcurrentHashMap.
 putIfAbsent() should be used.
 Similar issue occurs at line 307 as well.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

ZooKeeper_branch34_solaris - Build # 795 - Failure