[jira] [Created] (ZOOKEEPER-2077) Wild-card/Regex Support for Zookeeper client commands
Vivek Madani created ZOOKEEPER-2077: --- Summary: Wild-card/Regex Support for Zookeeper client commands Key: ZOOKEEPER-2077 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2077 Project: ZooKeeper Issue Type: New Feature Components: java client Reporter: Vivek Madani We had an use-case where we had to list nodes matching a particular pattern from a given path. While looking at the ZK client commands, it seems that it does not support wildcard/regex. I did try to overcome this by making some basic changes to the LSCommand.java and adding a -m switch which accepts regex. Since I implemented this using java.util.regex, it supports everything that Java regex supports. I was thinking such functionality can be useful for 'ls' as well as 'delete' (and deleteall). Though I implemented this at the client code for ls - this can be done at the server side code as well and I have a preliminary plan on top of my head to do this for ls, delete, deleteall. Will it be worthwhile addition to make to zookeeper client? If so, I can work on submitting a patch. Points to consider in case such a support can be implemented: 1. Do we support Java regex or Unix Shell wildcards (*)? 2. Right now, create allows creating nodes with characters like * - we need to make sure that such a change does not break or create confusion (Unix too allows creating a directory with * BTW). Any thoughts on whether this will be a worthwhile addition to Zookeeper client? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2077) Wild-card/Regex Support for Zookeeper client commands
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vivek Madani updated ZOOKEEPER-2077: Description: We had an use-case where we had to list nodes matching a particular pattern from a given path. While looking at the ZK client commands, it seems that it does not support wildcard/regex. I did try to overcome this by making some basic changes to the LSCommand.java and adding a -m switch which accepts regex. Since I implemented this using java.util.regex, it supports everything that Java regex supports. I was thinking such functionality can be useful for 'ls' as well as 'delete' (and deleteall). Though I implemented this at the client code for ls - this can be done at the server side code as well and I have a preliminary plan on top of my head to do this for ls, delete, deleteall. Will it be worthwhile addition to make to zookeeper client? If so, I can work on submitting a patch. Points to consider in case such a support can be implemented: 1. Do we support Java regex or Unix Shell wildcards ( * )? 2. Right now, create allows creating nodes with characters like * - we need to make sure that such a change does not break or create confusion (Unix too allows creating a directory with * BTW). Any thoughts on whether this will be a worthwhile addition to Zookeeper client? was: We had an use-case where we had to list nodes matching a particular pattern from a given path. While looking at the ZK client commands, it seems that it does not support wildcard/regex. I did try to overcome this by making some basic changes to the LSCommand.java and adding a -m switch which accepts regex. Since I implemented this using java.util.regex, it supports everything that Java regex supports. I was thinking such functionality can be useful for 'ls' as well as 'delete' (and deleteall). Though I implemented this at the client code for ls - this can be done at the server side code as well and I have a preliminary plan on top of my head to do this for ls, delete, deleteall. Will it be worthwhile addition to make to zookeeper client? If so, I can work on submitting a patch. Points to consider in case such a support can be implemented: 1. Do we support Java regex or Unix Shell wildcards (*)? 2. Right now, create allows creating nodes with characters like * - we need to make sure that such a change does not break or create confusion (Unix too allows creating a directory with * BTW). Any thoughts on whether this will be a worthwhile addition to Zookeeper client? Wild-card/Regex Support for Zookeeper client commands - Key: ZOOKEEPER-2077 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2077 Project: ZooKeeper Issue Type: New Feature Components: java client Reporter: Vivek Madani We had an use-case where we had to list nodes matching a particular pattern from a given path. While looking at the ZK client commands, it seems that it does not support wildcard/regex. I did try to overcome this by making some basic changes to the LSCommand.java and adding a -m switch which accepts regex. Since I implemented this using java.util.regex, it supports everything that Java regex supports. I was thinking such functionality can be useful for 'ls' as well as 'delete' (and deleteall). Though I implemented this at the client code for ls - this can be done at the server side code as well and I have a preliminary plan on top of my head to do this for ls, delete, deleteall. Will it be worthwhile addition to make to zookeeper client? If so, I can work on submitting a patch. Points to consider in case such a support can be implemented: 1. Do we support Java regex or Unix Shell wildcards ( * )? 2. Right now, create allows creating nodes with characters like * - we need to make sure that such a change does not break or create confusion (Unix too allows creating a directory with * BTW). Any thoughts on whether this will be a worthwhile addition to Zookeeper client? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
ZooKeeper-trunk-ibm6 - Build # 674 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-ibm6/674/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 355090 lines...] [junit] 2014-11-12 09:27:22,495 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2014-11-12 09:27:22,497 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2014-11-12 09:27:22,498 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-11-12 09:27:22,498 [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-11-12 09:27:22,499 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-11-12 09:27:22,500 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-11-12 09:27:22,501 [myid:] - INFO [main:ZooKeeperServer@781] - minSessionTimeout set to 6000 [junit] 2014-11-12 09:27:22,501 [myid:] - INFO [main:ZooKeeperServer@790] - maxSessionTimeout set to 6 [junit] 2014-11-12 09:27:22,501 [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/test1494383466703619431.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test1494383466703619431.junit.dir/version-2 [junit] 2014-11-12 09:27:22,502 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test1494383466703619431.junit.dir/version-2/snapshot.b [junit] 2014-11-12 09:27:22,506 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-ibm6/trunk/build/test/tmp/test1494383466703619431.junit.dir/version-2/snapshot.b [junit] 2014-11-12 09:27:22,509 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-11-12 09:27:22,510 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:53004 [junit] 2014-11-12 09:27:22,511 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:53004 [junit] 2014-11-12 09:27:22,512 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-11-12 09:27:22,512 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:53004 (no session established for client) [junit] 2014-11-12 09:27:22,513 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-11-12 09:27:22,516 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-11-12 09:27:22,516 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2014-11-12 09:27:22,517 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-11-12 09:27:22,517 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2014-11-12 09:27:22,518 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 5530 [junit] 2014-11-12 09:27:22,518 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 40 [junit] 2014-11-12 09:27:22,519 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-11-12 09:27:22,519 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-11-12 09:27:22,548 [myid:] - INFO [main:ZooKeeper@968] - Session: 0x149a3542955 closed [junit] 2014-11-12 09:27:22,548 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down [junit] 2014-11-12 09:27:22,548 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-11-12 09:27:22,549 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2014-11-12 09:27:22,549 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 09:27:22,549 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 09:27:22,549 [myid:] - INFO
ZooKeeper_branch35_jdk7 - Build # 109 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch35_jdk7/109/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 328241 lines...] [junit] 2014-11-12 10:48:59,245 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-11-12 10:48:59,246 [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-11-12 10:48:59,246 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-11-12 10:48:59,246 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-11-12 10:48:59,247 [myid:] - INFO [main:ZooKeeperServer@781] - minSessionTimeout set to 6000 [junit] 2014-11-12 10:48:59,247 [myid:] - INFO [main:ZooKeeperServer@790] - maxSessionTimeout set to 6 [junit] 2014-11-12 10:48:59,247 [myid:] - INFO [main:ZooKeeperServer@152] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test4573871378324319956.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test4573871378324319956.junit.dir/version-2 [junit] 2014-11-12 10:48:59,248 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test4573871378324319956.junit.dir/version-2/snapshot.b [junit] 2014-11-12 10:48:59,251 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test4573871378324319956.junit.dir/version-2/snapshot.b [junit] 2014-11-12 10:48:59,253 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-11-12 10:48:59,254 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:51037 [junit] 2014-11-12 10:48:59,255 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:51037 [junit] 2014-11-12 10:48:59,255 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-11-12 10:48:59,256 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:51037 (no session established for client) [junit] 2014-11-12 10:48:59,256 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-11-12 10:48:59,258 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-11-12 10:48:59,259 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2014-11-12 10:48:59,259 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-11-12 10:48:59,259 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2014-11-12 10:48:59,259 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 18089 [junit] 2014-11-12 10:48:59,260 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-11-12 10:48:59,260 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-11-12 10:48:59,260 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [main:ZooKeeper@968] - Session: 0x149a39ee1ad closed [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 10:48:59,320 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 10:48:59,321 [myid:] - INFO
ZooKeeper-trunk - Build # 2499 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk/2499/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 327427 lines...] [junit] 2014-11-12 11:09:27,386 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test7473540163264716853.junit.dir/version-2/snapshot.b [junit] 2014-11-12 11:09:27,389 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-11-12 11:09:27,389 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:42932 [junit] 2014-11-12 11:09:27,391 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:42932 [junit] 2014-11-12 11:09:27,391 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-11-12 11:09:27,392 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:42932 (no session established for client) [junit] 2014-11-12 11:09:27,392 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-11-12 11:09:27,394 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-11-12 11:09:27,394 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2014-11-12 11:09:27,394 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-11-12 11:09:27,395 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2014-11-12 11:09:27,395 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 83951 [junit] 2014-11-12 11:09:27,395 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-11-12 11:09:27,396 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-11-12 11:09:27,396 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-11-12 11:09:27,445 [myid:] - INFO [main:ZooKeeper@968] - Session: 0x149a3b19eb9 closed [junit] 2014-11-12 11:09:27,446 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-11-12 11:09:27,446 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2014-11-12 11:09:27,446 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2014-11-12 11:09:27,446 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down [junit] 2014-11-12 11:09:27,446 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 11:09:27,446 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 11:09:27,448 [myid:] - INFO [main:ZooKeeperServer@443] - shutting down [junit] 2014-11-12 11:09:27,448 [myid:] - INFO [main:SessionTrackerImpl@231] - Shutting down [junit] 2014-11-12 11:09:27,448 [myid:] - INFO [main:PrepRequestProcessor@971] - Shutting down [junit] 2014-11-12 11:09:27,448 [myid:] - INFO [main:SyncRequestProcessor@191] - Shutting down [junit] 2014-11-12 11:09:27,448 [myid:] - INFO [ProcessThread(sid:0 cport:11221)::PrepRequestProcessor@155] - PrepRequestProcessor exited loop! [junit] 2014-11-12 11:09:27,449 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited! [junit] 2014-11-12 11:09:27,449 [myid:] - INFO [main:FinalRequestProcessor@476] - shutdown of request processor complete [junit] 2014-11-12 11:09:27,450 [myid:] - INFO [main:MBeanRegistry@119] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree] [junit] 2014-11-12 11:09:27,450 [myid:] - INFO [main:MBeanRegistry@119] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11221] [junit] 2014-11-12 11:09:27,451 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-11-12 11:09:27,452 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2014-11-12 11:09:27,456 [myid:] - INFO [main:ClientBase@545] - fdcount after test is: 46 at start it was 33 [junit] 2014-11-12 11:09:27,457 [myid:] - INFO [main:ClientBase@547] - sleeping for 20 secs [junit] 2014-11-12
ZooKeeper-trunk-jdk7 - Build # 1036 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk-jdk7/1036/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 328051 lines...] [junit] 2014-11-12 11:26:27,073 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2014-11-12 11:26:27,073 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-11-12 11:26:27,073 [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-11-12 11:26:27,073 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-11-12 11:26:27,074 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-11-12 11:26:27,074 [myid:] - INFO [main:ZooKeeperServer@781] - minSessionTimeout set to 6000 [junit] 2014-11-12 11:26:27,074 [myid:] - INFO [main:ZooKeeperServer@790] - maxSessionTimeout set to 6 [junit] 2014-11-12 11:26:27,074 [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/test8302172333726632107.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test8302172333726632107.junit.dir/version-2 [junit] 2014-11-12 11:26:27,075 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test8302172333726632107.junit.dir/version-2/snapshot.b [junit] 2014-11-12 11:26:27,077 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test8302172333726632107.junit.dir/version-2/snapshot.b [junit] 2014-11-12 11:26:27,079 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-11-12 11:26:27,079 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:35968 [junit] 2014-11-12 11:26:27,080 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:35968 [junit] 2014-11-12 11:26:27,081 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-11-12 11:26:27,081 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:35968 (no session established for client) [junit] 2014-11-12 11:26:27,081 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-11-12 11:26:27,083 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-11-12 11:26:27,083 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2014-11-12 11:26:27,084 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-11-12 11:26:27,084 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2014-11-12 11:26:27,084 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 18107 [junit] 2014-11-12 11:26:27,084 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-11-12 11:26:27,084 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-11-12 11:26:27,085 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [main:ZooKeeper@968] - Session: 0x149a3c12e45 closed [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@529] - EventThread shut down [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-11-12 11:26:27,153 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method
[jira] [Created] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
metatech created ZOOKEEPER-2078:
---
Summary: zkServer.sh uses pattern unsupported by grep on Solaris
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Priority: Minor
The script zkServer.sh contains a pattern which is not supported by grep on
Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value, which
later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
metatech updated ZOOKEEPER-2078:
Description:
The script zkServer.sh contains a pattern which is not supported by grep on
Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value, which
later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read the
clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
was:
The script zkServer.sh contains a pattern which is not supported by grep on
Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value, which
later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
zkServer.sh uses pattern unsupported by grep on Solaris
-
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Priority: Minor
The script zkServer.sh contains a pattern which is not supported by grep
on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value,
which later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read
the clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
metatech updated ZOOKEEPER-2078:
Description:
The script zkServer.sh contains a pattern (POSIX character class syntax)
which is not supported by grep on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value, which
later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read the
clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
was:
The script zkServer.sh contains a pattern which is not supported by grep on
Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value, which
later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read the
clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
zkServer.sh uses pattern unsupported by grep on Solaris
-
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Priority: Minor
The script zkServer.sh contains a pattern (POSIX character class syntax)
which is not supported by grep on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value,
which later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read
the clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208030#comment-14208030
]
metatech commented on ZOOKEEPER-2078:
-
A second problem under Solaris is that the following command
{code}
/bin/echo -n 999 mypid.txt
{code}
will write -n 999 into the mypid.txt file.
When issuing a zkServer.sh stop, the following message is displayed :
{code}
Stopping zookeeper ... bin/zkServer.sh: line 145: kill: 24152: invalid signal
specification
{code}
But fortunately the stop is performed anyway, it is only a warning.
The following code writes only the PID in the file :
{code}
echo -n 999 mypid.txt
{code}
zkServer.sh uses pattern unsupported by grep on Solaris
-
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Priority: Minor
The script zkServer.sh contains a pattern (POSIX character class syntax)
which is not supported by grep on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value,
which later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read
the clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208050#comment-14208050
]
metatech commented on ZOOKEEPER-2078:
-
Sorry, my previous comment was wrong : the error invalid signal specification
really prevents the stop command from being processed, and the Zookeeper
instance is still running (altough its PID file is removed).
Also, a zkServer.sh start while the process is running does not detect that
it is already running.
zkServer.sh uses pattern unsupported by grep on Solaris
-
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Priority: Minor
The script zkServer.sh contains a pattern (POSIX character class syntax)
which is not supported by grep on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value,
which later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read
the clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2079) Stop daemon with kill rather than kill -9
Guillaume ALAUX created ZOOKEEPER-2079: -- Summary: Stop daemon with kill rather than kill -9 Key: ZOOKEEPER-2079 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2079 Project: ZooKeeper Issue Type: Improvement Components: scripts Environment: *nix Reporter: Guillaume ALAUX Priority: Minor Script `zkServer.sh` stops zookeeper by sending the java process a `kill -9` (SIGKILL). As there seems to be no technical reasons to use such a radical signal rather than the default SIGTERM (-15), I would propose to just use `kill` rather than `kill -9`. My use case is for Systemd service files for Zookeeper which always consider Zookeeper java process as failing when a clean `stop` is issued. Systemd output showing this fail: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: failed (Result: signal) since Wed 2014-11-05 11:23:29 CET; 2s ago Process: 656 ExecStop=/usr/bin/zkServer.sh stop (code=exited, status=0/SUCCESS) Process: 406 ExecStart=/usr/bin/zkServer.sh start (code=exited, status=0/SUCCESS) Main PID: 414 (code=killed, signal=KILL) Nov 05 11:23:29 magenta zookeeper[656]: Stopping zookeeper ... STOPPED Nov 05 11:23:29 magenta systemd[1]: zookeeper.service: main process exited, code=killed, status=9/KILL Nov 05 11:23:29 magenta systemd[1]: Unit zookeeper.service entered failed state. ---8--- There is no way to make this `status=9/KILL` to be recognized by Systemd as a regular exit code, even with `SuccessExitStatus=9 KILL SIGKILL`. On the other hand, turning this `kill -9` into a regular `kill` (-15 implied) makes it: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: inactive (dead) Nov 05 11:14:27 magenta zookeeper[30032]: Using config: /usr/share/zookeeper/bin/../conf/zoo.cfg Nov 05 11:14:27 magenta zookeeper[30032]: Stopping zookeeper ... STOPPED ---8--- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2079) Stop daemon with kill rather than kill -9
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume ALAUX updated ZOOKEEPER-2079: --- Attachment: ZOOKEEPER-2079.patch Kill Java process with `SIGTERM` rather than `SIGKILL` Stop daemon with kill rather than kill -9 - Key: ZOOKEEPER-2079 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2079 Project: ZooKeeper Issue Type: Improvement Components: scripts Environment: *nix Reporter: Guillaume ALAUX Priority: Minor Attachments: ZOOKEEPER-2079.patch Script `zkServer.sh` stops zookeeper by sending the java process a `kill -9` (SIGKILL). As there seems to be no technical reasons to use such a radical signal rather than the default SIGTERM (-15), I would propose to just use `kill` rather than `kill -9`. My use case is for Systemd service files for Zookeeper which always consider Zookeeper java process as failing when a clean `stop` is issued. Systemd output showing this fail: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: failed (Result: signal) since Wed 2014-11-05 11:23:29 CET; 2s ago Process: 656 ExecStop=/usr/bin/zkServer.sh stop (code=exited, status=0/SUCCESS) Process: 406 ExecStart=/usr/bin/zkServer.sh start (code=exited, status=0/SUCCESS) Main PID: 414 (code=killed, signal=KILL) Nov 05 11:23:29 magenta zookeeper[656]: Stopping zookeeper ... STOPPED Nov 05 11:23:29 magenta systemd[1]: zookeeper.service: main process exited, code=killed, status=9/KILL Nov 05 11:23:29 magenta systemd[1]: Unit zookeeper.service entered failed state. ---8--- There is no way to make this `status=9/KILL` to be recognized by Systemd as a regular exit code, even with `SuccessExitStatus=9 KILL SIGKILL`. On the other hand, turning this `kill -9` into a regular `kill` (-15 implied) makes it: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: inactive (dead) Nov 05 11:14:27 magenta zookeeper[30032]: Using config: /usr/share/zookeeper/bin/../conf/zoo.cfg Nov 05 11:14:27 magenta zookeeper[30032]: Stopping zookeeper ... STOPPED ---8--- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2079) Stop daemon with kill rather than kill -9
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208274#comment-14208274 ] Guillaume ALAUX commented on ZOOKEEPER-2079: Let me know if you would like a test for this. I saw file `src/java/test/bin/test-scripts.sh` but it already fails in several places even before my patch. Stop daemon with kill rather than kill -9 - Key: ZOOKEEPER-2079 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2079 Project: ZooKeeper Issue Type: Improvement Components: scripts Environment: *nix Reporter: Guillaume ALAUX Priority: Minor Attachments: ZOOKEEPER-2079.patch Script `zkServer.sh` stops zookeeper by sending the java process a `kill -9` (SIGKILL). As there seems to be no technical reasons to use such a radical signal rather than the default SIGTERM (-15), I would propose to just use `kill` rather than `kill -9`. My use case is for Systemd service files for Zookeeper which always consider Zookeeper java process as failing when a clean `stop` is issued. Systemd output showing this fail: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: failed (Result: signal) since Wed 2014-11-05 11:23:29 CET; 2s ago Process: 656 ExecStop=/usr/bin/zkServer.sh stop (code=exited, status=0/SUCCESS) Process: 406 ExecStart=/usr/bin/zkServer.sh start (code=exited, status=0/SUCCESS) Main PID: 414 (code=killed, signal=KILL) Nov 05 11:23:29 magenta zookeeper[656]: Stopping zookeeper ... STOPPED Nov 05 11:23:29 magenta systemd[1]: zookeeper.service: main process exited, code=killed, status=9/KILL Nov 05 11:23:29 magenta systemd[1]: Unit zookeeper.service entered failed state. ---8--- There is no way to make this `status=9/KILL` to be recognized by Systemd as a regular exit code, even with `SuccessExitStatus=9 KILL SIGKILL`. On the other hand, turning this `kill -9` into a regular `kill` (-15 implied) makes it: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: inactive (dead) Nov 05 11:14:27 magenta zookeeper[30032]: Using config: /usr/share/zookeeper/bin/../conf/zoo.cfg Nov 05 11:14:27 magenta zookeeper[30032]: Stopping zookeeper ... STOPPED ---8--- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Shouldn't zkServer.sh use SIGTERM rather than SIGKILL?
Submitted: https://issues.apache.org/jira/browse/ZOOKEEPER-2079 Thanks. On 12 November 2014 08:01, Michi Mutsuzaki mi...@cs.stanford.edu wrote: Hi Guillaume. Sending sigterm instead of sigkill sounds fine to me. Please go ahead and submit a patch. Thanks! --Michi On Tue, Nov 11, 2014 at 11:49 AM, Guillaume Alaux guilla...@alaux.net wrote: Hello, I noticed script zkServer.sh stops zookeeper by sending the java process a `kill -9` (SIGKILL). Is there any technical reason to use such a radical signal rather than SIGTERM (-15) for instance? I am wondering this because I am working on Systemd service files for Zookeeper [0] [1] and this `-9` actually makes Systemd consider the Zookeeper java process fails when stop is called as shown by the following Systemd log: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: failed (Result: signal) since Wed 2014-11-05 11:23:29 CET; 2s ago Process: 656 ExecStop=/usr/bin/zkServer.sh stop (code=exited, status=0/SUCCESS) Process: 406 ExecStart=/usr/bin/zkServer.sh start (code=exited, status=0/SUCCESS) Main PID: 414 (code=killed, signal=KILL) Nov 05 11:23:29 magenta zookeeper[656]: Stopping zookeeper ... STOPPED Nov 05 11:23:29 magenta systemd[1]: zookeeper.service: main process exited, code=killed, status=9/KILL Nov 05 11:23:29 magenta systemd[1]: Unit zookeeper.service entered failed state. ---8--- There is no way to make this `status=9/KILL` to be recognized by Systemd as a regular exit code, even with `SuccessExitStatus=9 KILL SIGKILL`. On the other hand, turning this `kill -9` into a regular `kill` (-15 implied) makes it: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: inactive (dead) Nov 05 11:14:27 magenta zookeeper[30032]: Using config: /usr/share/zookeeper/bin/../conf/zoo.cfg Nov 05 11:14:27 magenta zookeeper[30032]: Stopping zookeeper ... STOPPED ---8--- I would gladly submit a tiny patch for this (and maybe also submit the service file) but would first like to have your opinion on the reasons to use SIGKILL. [0] https://github.com/galaux/aurpkgs/blob/master/zookeeper/systemd_zookeeper.service [1] https://github.com/galaux/aurpkgs/blob/master/zookeeper/systemd_zookeeper%40.service -- Guillaume
[jira] [Commented] (ZOOKEEPER-2079) Stop daemon with kill rather than kill -9
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208353#comment-14208353 ] Hadoop QA commented on ZOOKEEPER-2079: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12681090/ZOOKEEPER-2079.patch against trunk revision 1637293. +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/2439//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2439//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2439//console This message is automatically generated. Stop daemon with kill rather than kill -9 - Key: ZOOKEEPER-2079 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2079 Project: ZooKeeper Issue Type: Improvement Components: scripts Environment: *nix Reporter: Guillaume ALAUX Priority: Minor Attachments: ZOOKEEPER-2079.patch Script `zkServer.sh` stops zookeeper by sending the java process a `kill -9` (SIGKILL). As there seems to be no technical reasons to use such a radical signal rather than the default SIGTERM (-15), I would propose to just use `kill` rather than `kill -9`. My use case is for Systemd service files for Zookeeper which always consider Zookeeper java process as failing when a clean `stop` is issued. Systemd output showing this fail: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: failed (Result: signal) since Wed 2014-11-05 11:23:29 CET; 2s ago Process: 656 ExecStop=/usr/bin/zkServer.sh stop (code=exited, status=0/SUCCESS) Process: 406 ExecStart=/usr/bin/zkServer.sh start (code=exited, status=0/SUCCESS) Main PID: 414 (code=killed, signal=KILL) Nov 05 11:23:29 magenta zookeeper[656]: Stopping zookeeper ... STOPPED Nov 05 11:23:29 magenta systemd[1]: zookeeper.service: main process exited, code=killed, status=9/KILL Nov 05 11:23:29 magenta systemd[1]: Unit zookeeper.service entered failed state. ---8--- There is no way to make this `status=9/KILL` to be recognized by Systemd as a regular exit code, even with `SuccessExitStatus=9 KILL SIGKILL`. On the other hand, turning this `kill -9` into a regular `kill` (-15 implied) makes it: ---8--- # sudo systemctl status zookeeper.service ● zookeeper.service - Highly reliable distributed coordination server Loaded: loaded (/usr/lib/systemd/system/zookeeper.service; disabled) Active: inactive (dead) Nov 05 11:14:27 magenta zookeeper[30032]: Using config: /usr/share/zookeeper/bin/../conf/zoo.cfg Nov 05 11:14:27 magenta zookeeper[30032]: Stopping zookeeper ... STOPPED ---8--- -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: ZOOKEEPER-2079 PreCommit Build #2439
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2079 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2439/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 326617 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/2439//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2439//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2439//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] 8e456da7148de5ae483eba1c23eae6f5c0979c6b 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:1714: exec returned: 2 Total time: 39 minutes 30 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2409 Archived 7 artifacts Archive block size is 32768 Received 5 blocks and 383042 bytes Compression is 30.0% Took 0.88 sec Recording test results Description set: ZOOKEEPER-2079 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. FAILED: 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 org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:151) at org.apache.zookeeper.test.ReconfigTest.testPortChange(ReconfigTest.java:600) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Commented] (ZOOKEEPER-2069) Netty Support for ClientCnxnSocket
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208366#comment-14208366 ] Flavio Junqueira commented on ZOOKEEPER-2069: - Thanks for the updates, [~hdeng], I'll check the RB. Netty Support for ClientCnxnSocket -- Key: ZOOKEEPER-2069 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2069 Project: ZooKeeper Issue Type: Sub-task Reporter: Hongchao Deng Assignee: Hongchao Deng Attachments: QA-run-nettyclient-for-test.patch, ZOOKEEPER-2069-v10-channel.patch, ZOOKEEPER-2069-v11.patch, ZOOKEEPER-2069-v2.patch, ZOOKEEPER-2069-v3.patch, ZOOKEEPER-2069-v4.patch, ZOOKEEPER-2069-v5.patch, ZOOKEEPER-2069-v6.patch, ZOOKEEPER-2069-v7.patch, ZOOKEEPER-2069-v8.patch, ZOOKEEPER-2069-v9.1.patch, ZOOKEEPER-2069-v9.2.patch, ZOOKEEPER-2069-v9.patch, ZOOKEEPER-2069.patch, draft.patch Review Board: https://reviews.apache.org/r/27244/diff/# -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2063) Netty+SSL support for client-server communication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208370#comment-14208370 ] Flavio Junqueira commented on ZOOKEEPER-2063: - I'm still wondering about SSL support for the C client... :-( Netty+SSL support for client-server communication - Key: ZOOKEEPER-2063 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2063 Project: ZooKeeper Issue Type: New Feature Reporter: Hongchao Deng Assignee: Hongchao Deng Attachments: ZOOKEEPER-2063.patch ZooKeeper currently have netty option on server side. We want to support netty on client side too. After that, we could add ssl support based on netty channel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2063) Netty+SSL support for client-server communication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208386#comment-14208386 ] Hongchao Deng commented on ZOOKEEPER-2063: -- [~fpj] Dismissed the point in the conversation.. Honestly, I think the best way to do this might be using HTTP protocol. I wonder if we can improve our REST api and/or might work even further to get a more powerful HTTP proxy: http://engineering.pinterest.com/post/77933733851/zookeeper-resilience-at-pinterest I talked to Patrick about this. Might be a good thing on the road map. Netty+SSL support for client-server communication - Key: ZOOKEEPER-2063 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2063 Project: ZooKeeper Issue Type: New Feature Reporter: Hongchao Deng Assignee: Hongchao Deng Attachments: ZOOKEEPER-2063.patch ZooKeeper currently have netty option on server side. We want to support netty on client side too. After that, we could add ssl support based on netty channel. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
ZooKeeper-trunk-openjdk7 - Build # 628 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/628/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 1484 lines...] [ivy:retrieve] [SUCCESSFUL ] commons-cli#commons-cli;1.2!commons-cli.jar (95ms) [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) (155ms) [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 (270ms) [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 (130ms) [ivy:retrieve] :: resolution report :: resolve 6731ms :: artifacts dl 1751ms - | |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/41ms) 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: 12 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-2064) Prevent resource leak in various classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated ZOOKEEPER-2064: -- Attachment: 2064-v2.txt patch v2 is based on latest trunk. Prevent resource leak in various classes Key: ZOOKEEPER-2064 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2064 Project: ZooKeeper Issue Type: Bug Reporter: Ted Yu Priority: Critical Attachments: 2064-v1.txt, 2064-v2.txt In various classes, there is potential resource leak. e.g. LogIterator / RandomAccessFileReader is not closed upon return from the method. Corresponding close() should be called to prevent resource leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2064) Prevent resource leak in various classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208887#comment-14208887 ] Hadoop QA commented on ZOOKEEPER-2064: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12681166/2064-v2.txt against trunk revision 1637293. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 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/2440//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2440//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2440//console This message is automatically generated. Prevent resource leak in various classes Key: ZOOKEEPER-2064 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2064 Project: ZooKeeper Issue Type: Bug Reporter: Ted Yu Priority: Critical Attachments: 2064-v1.txt, 2064-v2.txt In various classes, there is potential resource leak. e.g. LogIterator / RandomAccessFileReader is not closed upon return from the method. Corresponding close() should be called to prevent resource leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: ZOOKEEPER-2064 PreCommit Build #2440
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2064 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2440/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 288264 lines...] [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 6 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/2440//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2440//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2440//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] 72f6b95b59b7252992b1a3de25a5ba8ca3e6d3bb 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:1714: exec returned: 1 Total time: 41 minutes 43 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2409 Archived 7 artifacts Archive block size is 32768 Received 5 blocks and 383045 bytes Compression is 30.0% Took 2.3 sec Recording test results Description set: ZOOKEEPER-2064 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 2 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) FAILED: org.apache.zookeeper.test.ReconfigTest.testPortChange Error Message: client could not connect to reestablished quorum: giving up after 30+ seconds. Stack Trace: junit.framework.AssertionFailedError: client could not connect to reestablished quorum: giving up after 30+ seconds. at org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:159) at org.apache.zookeeper.test.ReconfigTest.testPortChange(ReconfigTest.java:629) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Commented] (ZOOKEEPER-2064) Prevent resource leak in various classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208924#comment-14208924 ] Ted Yu commented on ZOOKEEPER-2064: --- I ran the failed tests locally. ReconfigRecoveryTest#testCurrentObserverIsParticipantInNewConfig fails with or without my patch. Prevent resource leak in various classes Key: ZOOKEEPER-2064 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2064 Project: ZooKeeper Issue Type: Bug Reporter: Ted Yu Priority: Critical Attachments: 2064-v1.txt, 2064-v2.txt In various classes, there is potential resource leak. e.g. LogIterator / RandomAccessFileReader is not closed upon return from the method. Corresponding close() should be called to prevent resource leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2064) Prevent resource leak in various classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14208931#comment-14208931 ] Ted Yu commented on ZOOKEEPER-2064: --- Correction: ReconfigRecoveryTest#testCurrentServersAreObserversInNextConfig failed with patch ReconfigRecoveryTest#testCurrentObserverIsParticipantInNewConfig failed without patch. Prevent resource leak in various classes Key: ZOOKEEPER-2064 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2064 Project: ZooKeeper Issue Type: Bug Reporter: Ted Yu Priority: Critical Attachments: 2064-v1.txt, 2064-v2.txt In various classes, there is potential resource leak. e.g. LogIterator / RandomAccessFileReader is not closed upon return from the method. Corresponding close() should be called to prevent resource leak. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (ZOOKEEPER-2080) ReconfigRecoveryTest fails intermittently
Ted Yu created ZOOKEEPER-2080:
-
Summary: ReconfigRecoveryTest fails intermittently
Key: ZOOKEEPER-2080
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2080
Project: ZooKeeper
Issue Type: Test
Reporter: Ted Yu
Priority: Minor
I got the following test failure on MacBook with trunk code:
{code}
Testcase: testCurrentObserverIsParticipantInNewConfig took 93.628 sec
FAILED
waiting for server 2 being up
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)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Zookeeper availability coupling in bookkeeper
Ah, I hadn't seen that that had a patch. Could you mark the jira's which have a patch, as patch available. Even if the patch isn't ready to go in, it'll give an idea of what code is available. -Ivan On 11 November 2014 20:23, Sijie Guo guosi...@gmail.com wrote: BOOKKEEPER-705 is what we handled the session expiry event on client server side. - Sijie On Fri, Nov 7, 2014 at 7:11 AM, Ivan Kelly iv...@apache.org wrote: Hi folks, Currently bookie lifetime is dependent on the zookeeper session which the bookie was started with. This is bad, and unnecessary and something that has causes us some downtime here. I have a fix for this available, but before I put up the patch, I'd like to know if anyone has also fixed this (I'm looking in the direction of Twitter here). BOOKKEEPER-704 added a zookeeper client that survived session expiry but this client was never wired into anything. I'm currently writing some tests for this in the bookkeeper client. @Sijie, do you guys already have more changes in this area. I'd like to avoid duplicating work here. Cheers, Ivan
