ZooKeeper-trunk-solaris - Build # 792 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/792/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 211804 lines...] [junit] 2014-01-15 09:04:05,641 [myid:] - INFO [main:SyncRequestProcessor@190] - Shutting down [junit] 2014-01-15 09:04:05,641 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop! [junit] 2014-01-15 09:04:05,641 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2014-01-15 09:04:05,641 [myid:] - INFO [main:FinalRequestProcessor@442] - shutdown of request processor complete [junit] 2014-01-15 09:04:05,642 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-01-15 09:04:05,642 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2014-01-15 09:04:05,643 [myid:] - INFO [main:ClientBase@439] - STARTING server [junit] 2014-01-15 09:04:05,644 [myid:] - INFO [main:ClientBase@360] - CREATING server instance 127.0.0.1:11221 [junit] 2014-01-15 09:04:05,644 [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-01-15 09:04:05,645 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-01-15 09:04:05,645 [myid:] - INFO [main:ClientBase@335] - STARTING server instance 127.0.0.1:11221 [junit] 2014-01-15 09:04:05,645 [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/test7263810898997207538.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test7263810898997207538.junit.dir/version-2 [junit] 2014-01-15 09:04:05,646 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test7263810898997207538.junit.dir/version-2/snapshot.b [junit] 2014-01-15 09:04:05,649 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test7263810898997207538.junit.dir/version-2/snapshot.b [junit] 2014-01-15 09:04:05,650 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-01-15 09:04:05,651 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:37975 [junit] 2014-01-15 09:04:05,651 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:37975 [junit] 2014-01-15 09:04:05,651 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-01-15 09:04:05,652 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:37975 (no session established for client) [junit] 2014-01-15 09:04:05,652 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-01-15 09:04:05,653 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2014-01-15 09:04:05,654 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-01-15 09:04:05,654 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2014-01-15 09:04:05,654 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-01-15 09:04:05,654 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 13351 [junit] 2014-01-15 09:04:05,654 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-01-15 09:04:05,654 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-01-15 09:04:05,655 [myid:] - INFO [main:ClientBase@478] - tearDown starting [junit] 2014-01-15 09:04:05,729 [myid:] - INFO [main:ZooKeeper@777] - Session: 0x1439524acb5 closed [junit] 2014-01-15 09:04:05,729 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down [junit] 2014-01-15 09:04:05,729 [myid:] - INFO [main:ClientBase@448] - STOPPING server [junit] 2014-01-15 09:04:05,729 [myid:] - INFO
ZooKeeper-3.4-WinVS2008_java - Build # 409 - Still Failing
See https://builds.apache.org/job/ZooKeeper-3.4-WinVS2008_java/409/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 178792 lines...] [junit] 2014-01-15 09:17:18,966 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@968] - Opening socket connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to authenticate using SASL (unknown error) [junit] 2014-01-15 09:17:19,043 [myid:] - INFO [main:JMXEnv@135] - ensureOnly:[] [junit] 2014-01-15 09:17:19,045 [myid:] - INFO [main:ClientBase@438] - STARTING server [junit] 2014-01-15 09:17:19,045 [myid:] - INFO [main:ClientBase@359] - CREATING server instance 127.0.0.1:11221 [junit] 2014-01-15 09:17:19,046 [myid:] - INFO [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-01-15 09:17:19,046 [myid:] - INFO [main:ClientBase@334] - STARTING server instance 127.0.0.1:11221 [junit] 2014-01-15 09:17:19,046 [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\test515066032627397127.junit.dir\version-2 snapdir f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test515066032627397127.junit.dir\version-2 [junit] 2014-01-15 09:17:19,049 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-01-15 09:17:19,050 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:53578 [junit] 2014-01-15 09:17:19,050 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing stat command from /127.0.0.1:53578 [junit] 2014-01-15 09:17:19,051 [myid:] - INFO [Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output [junit] 2014-01-15 09:17:19,051 [myid:] - INFO [Thread-4:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:53578 (no session established for client) [junit] 2014-01-15 09:17:19,051 [myid:] - INFO [main:JMXEnv@135] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-01-15 09:17:19,053 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2014-01-15 09:17:19,053 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-01-15 09:17:19,053 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2014-01-15 09:17:19,053 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-01-15 09:17:19,053 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 10708 [junit] 2014-01-15 09:17:19,054 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 20 [junit] 2014-01-15 09:17:19,054 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-01-15 09:17:19,054 [myid:] - INFO [main:ClientBase@477] - tearDown starting [junit] 2014-01-15 09:17:19,463 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@849] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2014-01-15 09:17:19,463 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:53575 [junit] 2014-01-15 09:17:19,463 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@861] - Client attempting to renew session 0x1439530c098 at /127.0.0.1:53575 [junit] 2014-01-15 09:17:19,464 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@617] - Established session 0x1439530c098 with negotiated timeout 3 for client /127.0.0.1:53575 [junit] 2014-01-15 09:17:19,464 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1228] - Session establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 0x1439530c098, negotiated timeout = 3 [junit] 2014-01-15 09:17:19,465 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@494] - Processed session termination for sessionid: 0x1439530c098 [junit] 2014-01-15 09:17:19,465 [myid:] - INFO [SyncThread:0:FileTxnLog@199] - Creating new log file: log.c [junit] 2014-01-15 09:17:19,503 [myid:] - INFO [main:ZooKeeper@684] - Session: 0x1439530c098 closed [junit] 2014-01-15 09:17:19,504 [myid:] - INFO [main:ClientBase@447] - STOPPING server [junit] 2014-01-15 09:17:19,504 [myid:] - WARN
[jira] [Updated] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Germán Blanco updated ZOOKEEPER-1837: - Attachment: ZOOKEEPER-1837-b3.4.patch Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Germán Blanco updated ZOOKEEPER-1837: - Attachment: ZOOKEEPER-1837.patch Thank you for the review and the comments. I believe they are covered in this last revision of the patches. Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
ZooKeeper-trunk-WinVS2008_java - Build # 655 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/655/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 245651 lines...] [junit] 2014-01-15 09:42:48,000 [myid:] - INFO [SessionTracker:SessionTrackerImpl@134] - SessionTrackerImpl exited loop! [junit] 2014-01-15 09:42:48,558 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2014-01-15 09:42:48,560 [myid:] - INFO [main:ClientBase@439] - STARTING server [junit] 2014-01-15 09:42:48,560 [myid:] - INFO [main:ClientBase@360] - CREATING server instance 127.0.0.1:11221 [junit] 2014-01-15 09:42:48,560 [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-01-15 09:42:48,561 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-01-15 09:42:48,562 [myid:] - INFO [main:ClientBase@335] - STARTING server instance 127.0.0.1:11221 [junit] 2014-01-15 09:42:48,563 [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\test788057280377651669.junit.dir\version-2 snapdir f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test788057280377651669.junit.dir\version-2 [junit] 2014-01-15 09:42:48,563 [myid:] - INFO [main:FileSnap@83] - Reading snapshot f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test788057280377651669.junit.dir\version-2\snapshot.b [junit] 2014-01-15 09:42:48,564 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test788057280377651669.junit.dir\version-2\snapshot.b [junit] 2014-01-15 09:42:48,566 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-01-15 09:42:48,567 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:56577 [junit] 2014-01-15 09:42:48,567 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:56577 [junit] 2014-01-15 09:42:48,568 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-01-15 09:42:48,568 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:56577 (no session established for client) [junit] 2014-01-15 09:42:48,568 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-01-15 09:42:48,570 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2014-01-15 09:42:48,570 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-01-15 09:42:48,571 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2014-01-15 09:42:48,571 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-01-15 09:42:48,571 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 13418 [junit] 2014-01-15 09:42:48,571 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 22 [junit] 2014-01-15 09:42:48,571 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-01-15 09:42:48,572 [myid:] - INFO [main:ClientBase@478] - tearDown starting [junit] 2014-01-15 09:42:48,710 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@882] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2014-01-15 09:42:48,711 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:56572 [junit] 2014-01-15 09:42:48,712 [myid:] - INFO [NIOWorkerThread-2:ZooKeeperServer@858] - Client attempting to renew session 0x1439548164c at /127.0.0.1:56572 [junit] 2014-01-15 09:42:48,713 [myid:] - INFO [NIOWorkerThread-2:ZooKeeperServer@604] - Established session 0x1439548164c with negotiated timeout 3 for client /127.0.0.1:56572 [junit] 2014-01-15 09:42:48,713 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1261] - Session establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 0x1439548164c, negotiated timeout = 3 [junit]
Failed: ZOOKEEPER-1837 PreCommit Build #1885
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1885/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by remote host 127.0.0.1 Building remotely on hadoop9 in workspace /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build Reverting /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk to depth infinity with ignoreExternals: false Updating http://svn.apache.org/repos/asf/zookeeper/trunk at revision '2014-01-15T09:50:51.944 +' At revision 1558326 no change for http://svn.apache.org/repos/asf/zookeeper/trunk since the previous build No emails were triggered. [PreCommit-ZOOKEEPER-Build] $ /bin/bash /tmp/hudson8690960817330539275.sh /home/jenkins/tools/java/latest/bin/java Buildfile: build.xml check-for-findbugs: findbugs.check: forrest.check: hudson-test-patch: [exec] [exec] [exec] == [exec] == [exec] Testing patch for ZOOKEEPER-1837. [exec] == [exec] == [exec] [exec] [exec] At revision 1558327. [exec] ZOOKEEPER-1837 is not Patch Available. Exiting. [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 19 seconds Archiving artifacts ERROR: No artifacts found that match the file pattern trunk/build/test/findbugs/newPatchFindbugsWarnings.html,trunk/patchprocess/*.txt,trunk/patchprocess/*Warnings.xml,trunk/build/test/test-cppunit/*.txt,trunk/build/tmp/zk.log. Configuration error? ERROR: ?trunk/build/test/findbugs/newPatchFindbugsWarnings.html? doesn?t match anything: ?trunk? exists but not ?trunk/build/test/findbugs/newPatchFindbugsWarnings.html? Build step 'Archive the artifacts' changed build result to FAILURE Recording test results Description set: ZOOKEEPER-1837 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Updated] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh R updated ZOOKEEPER-442: --- Attachment: ZOOKEEPER-442.patch need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871913#comment-13871913 ] Rakesh R commented on ZOOKEEPER-442: Hi [~phunt], could you please look at the latest patch. I ran the same test case in my env and seems ok till now. need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Failed: ZOOKEEPER-442 PreCommit Build #1886
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 291627 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12623108/ZOOKEEPER-442.patch [exec] against trunk revision 1557875. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886//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] 2d3fe142ac508f3875e24ef986edf995182ceb56 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: 39 minutes 46 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-442 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871942#comment-13871942 ] Hadoop QA commented on ZOOKEEPER-442: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12623108/ZOOKEEPER-442.patch against trunk revision 1557875. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1886//console This message is automatically generated. need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Germán Blanco updated ZOOKEEPER-1837: - Attachment: ZOOKEEPER-1837-b3.4.patch Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Germán Blanco updated ZOOKEEPER-1837: - Attachment: ZOOKEEPER-1837.patch Yeah, it was *very* unreachable. Firstly because of my mistake to put TestCase.fail before the log, and on top of that because as far as I can see ensureNone is not used at all. But now it is corrected, and if it is used in the future it will hopefully work better. Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at
[jira] [Updated] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh R updated ZOOKEEPER-442: --- Attachment: ZOOKEEPER-442.patch need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872033#comment-13872033
]
Rakesh R commented on ZOOKEEPER-442:
I couldn't see failures in the previous build.
{code}
0 failures (±0)
{code}
Attached new patch where I reduced timeout to improve test execution time.
need a way to remove watches that are no longer of interest
---
Key: ZOOKEEPER-442
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442
Project: ZooKeeper
Issue Type: Sub-task
Components: java client, server
Reporter: Benjamin Reed
Assignee: Rakesh R
Priority: Critical
Fix For: 3.5.0
Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch
currently the only way a watch cleared is to trigger it. we need a way to
enumerate the outstanding watch objects, find watch events the objects are
watching for, and remove interests in an event.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Success: ZOOKEEPER-1837 PreCommit Build #1887
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 291535 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12623133/ZOOKEEPER-1837.patch [exec] against trunk revision 1557875. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 9 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887//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] 03f34447a70ab0d7293d950ec61a324b08b1b154 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 33 minutes 45 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1837 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872062#comment-13872062 ] Hadoop QA commented on ZOOKEEPER-1837: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12623133/ZOOKEEPER-1837.patch against trunk revision 1557875. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 9 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1887//console This message is automatically generated. Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at
Success: ZOOKEEPER-442 PreCommit Build #1888
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 286044 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12623135/ZOOKEEPER-442.patch [exec] against trunk revision 1557875. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888//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] 6ed2ae26a30f758b9626ebf484bb63d9b8a719f9 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 34 minutes 9 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-442 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872084#comment-13872084 ] Hadoop QA commented on ZOOKEEPER-442: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12623135/ZOOKEEPER-442.patch against trunk revision 1557875. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1888//console This message is automatically generated. need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872188#comment-13872188 ] Flavio Junqueira commented on ZOOKEEPER-1837: - In ensureNone, it looks like we don't fail when nTry goes over 50. Shouldn't we fail the test case after too many attempts? Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) -- This message was sent by
[jira] [Commented] (ZOOKEEPER-1858) JMX checks - potential race conditions while stopping and starting server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872217#comment-13872217
]
Flavio Junqueira commented on ZOOKEEPER-1858:
-
It looks better now, thanks, [~rakeshr]. I'm still a bit hesitant in checking
in this patch as is. Tracing back the change, the JMX stuff apparently got in
with ZOOKEEPER-94. I was wondering if [~phunt] can chime in to make sure that
we are not breaking anything.
JMX checks - potential race conditions while stopping and starting server
-
Key: ZOOKEEPER-1858
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1858
Project: ZooKeeper
Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
Labels: test
Fix For: 3.4.6, 3.5.0
Attachments: ZOOKEEPER-1858-br3.4.patch, ZOOKEEPER-1858.patch,
ZOOKEEPER-1858.patch, ZOOKEEPER-1858.patch
I've noticed one potential case, where previously created zkclient session
immediately reconnected and publishing those beans while starting back the
zkserver and affecting zk#startup jmx checks.
Say, before stopping the server, there is a zk client session
0x143576544c5 exists. While starting back the server, there could be
possibility of seeing the client sessions in jmx. Following is one such case.
Please see below logs which has taken from build
https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/642/
{code}[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[main-SendThread(127.0.0.1:11222):ClientCnxn$SendThread@1228] - Session
establishment complete on server 127.0.0.1/127.0.0.1:11222, sessionid =
0x143576544c5, negotiated timeout = 3
[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11222:ZooKeeperServer@617] -
Established session 0x143576544c5 with negotiated timeout 3 for
client /127.0.0.1:55377{code}
{code} [junit] 2014-01-03 09:18:12,391 [myid:] - INFO [main:JMXEnv@135] -
ensureOnly:[]
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@438] -
STARTING server
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@359] -
CREATING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@334] -
STARTING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=Connections,name2=127.0.0.1,name3=0x143576544c5
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED
testDefaultWatcherAutoResetWithChroot
[junit] junit.framework.AssertionFailedError: expected:0 but was:2
[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 junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:144)
[junit] at
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:443)
[junit] at
org.apache.zookeeper.test.DisconnectedWatcherTest.testDefaultWatcherAutoResetWithChroot(DisconnectedWatcherTest.java:123)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872243#comment-13872243
]
Germán Blanco commented on ZOOKEEPER-1837:
--
It fails outside the loop (at least that is the intention).
In the check after the loop:
{noformat}
+if (foundUnexpected) {
+LOG.info(List of all beans follows:);
+for (ObjectName bean : beans) {
+LOG.info(bean: + bean.toString());
+}
+TestCase.fail(unexpectedName);
}
{noformat}
If anything unexpected is found after the 50th try, then TestCase.fail will
cause the test case to fail.
If there is nothing unexpected in one of the loop runs it will exit before
reaching the 50th try and not enter that if block.
Fix JMXEnv checks (potential race conditions)
-
Key: ZOOKEEPER-1837
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837
Project: ZooKeeper
Issue Type: Sub-task
Components: tests
Affects Versions: 3.4.5, 3.5.0
Environment: Windows 8
Reporter: Germán Blanco
Assignee: Germán Blanco
Fix For: 3.4.6, 3.5.0
Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch,
ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch,
ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch,
ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch
The following failures in ZooKeeper-3.4-WinVS2008_java and
ZooKeeper-trunk-WinVS2008_java require fixing:
[junit] junit.framework.AssertionFailedError: expected:0 but was:1
[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 junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138)
[junit] at
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417)
[junit] at
org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] junit.framework.AssertionFailedError: expected:0 but was:1
[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 junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138)
[junit] at
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417)
[junit] at
org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[
junit.framework.AssertionFailedError: expected [0x142e5f027b50001]
expected:1 but was:0
at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115)
at
org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197)
at
Re: Possible bug - xid mismatch, out of order responses, unexpected server response: expected 0x..., but recieved 0x...
Just to close the loop here - this is a race in upstream zookeeper. I'll
open a jira ticket today.
In the commit processor, if we are at the primary request handler on line
167:
while (!stopped !isWaitingForCommit()
!isProcessingCommit()
(request = queuedRequests.poll()) != null) {
if (needCommit(request)) {
nextPending.set(request);
} else {
sendToNextProcessor(request);
}
}
A request can be handled in this block and be quickly processed and
completed on another thread. If queuedRequests is empty, we then exit the
block. Next, before this thread makes any more progress, we can get 2 more
requests, one get_children(say), and a sync placed on queuedRequests for
the processor. Then, if we are very unlucky, the sync request can complete
and this object's commit() routine is called (from
FollowerZookeeperServer), which places the sync request on the previously
empty committedRequests queue. At that point, this thread continues.
We reach line 182, which is a check on sync requests.
if (!stopped !isProcessingRequest()
(request = committedRequests.poll()) != null) {
Here we are not processing any requests, because the original request above
has completed. We haven't dequeued either the read or the sync request in
this processor. Next, the poll above will pull the sync request off the
queue, and in the following block, the sync will get forwarded to the next
processor.
This is a problem because the read request hasn't been forwarded yet, so
requests are now out of order.
--Dutch
On Mon, Jan 13, 2014 at 3:16 PM, Dutch Meyer hot...@gmail.com wrote:
I have another instance of this issue while running at DEBUG trace level.
2014-01-01 12:55:12,278 - WARN [NIOWorkerThread-4:NIOServerCnxn@362][] -
Unable to read additional data from client sessionid 0x20209eb0002,
likely client has closed socket
2014-01-01 12:55:12,278 - INFO [NIOWorkerThread-4:NIOServerCnxn@1000][]
- Closed socket connection for client /10.11.19.2:54313 which had
sessionid 0x20209eb0002
2014-01-01 12:55:12,279 - DEBUG [NIOWorkerThread-4:NIOServerCnxn@1036][]
- ignoring exception during input shutdown
java.net.SocketException: Transport endpoint is not connected
at sun.nio.ch.SocketChannelImpl.shutdown(Native Method)
at
sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:658)
at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:378)
at
org.apache.zookeeper.server.NIOServerCnxn.closeSock(NIOServerCnxn.java:1032)
at
org.apache.zookeeper.server.NIOServerCnxn.closeSock(NIOServerCnxn.java:1005)
at
org.apache.zookeeper.server.NIOServerCnxn.close(NIOServerCnxn.java:989)
at
org.apache.zookeeper.server.NIOServerCnxn.doIO(NIOServerCnxn.java:364)
at
org.apache.zookeeper.server.NIOServerCnxnFactory$IOWorkRequest.doWork(NIOServerCnxnFactory.java:530)
at
org.apache.zookeeper.server.WorkerService$ScheduledWorkRequest.run(WorkerService.java:152)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
2014-01-01 12:55:12,799 - INFO
[NIOServerCxnFactory.AcceptThread:/10.11.19.2:2181
:NIOServerCnxnFactory$AcceptThread@296][] - Accepted socket connection
from /10.11.19.2:54326
2014-01-01 12:55:12,799 - DEBUG [NIOWorkerThread-1:ZooKeeperServer@761][]
- Session establishment request from client /10.11.19.2:54326 client's
lastZxid is 0x203b3
2014-01-01 12:55:12,800 - INFO [NIOWorkerThread-1:ZooKeeperServer@816][]
- Client attempting to renew session 0x20209eb0002 at /
10.11.19.2:54326
2014-01-01 12:55:12,800 - INFO [NIOWorkerThread-1:Learner@114][] -
Revalidating client: 0x20209eb0002
2014-01-01 12:55:12,802 - INFO
[QuorumPeer[myid=3175620633077743617]/10.11.19.2:2181:ZooKeeperServer@567][]
- Established session 0x20209eb0002 with negotiated timeout 1 for
client /10.11.19.2:54326
...
2014-01-01 12:55:14,291 - DEBUG
[FollowerRequestProcessor:3175620633077743617:CommitProcessor@315][] -
Processing request:: sessionid:0x20209eb0002 type:getChildren cxid:0x1
zxid:0xfffe txntype:unknown reqpath:/j/l/m
2014-01-01 12:55:14,298 - DEBUG
[FollowerRequestProcessor:3175620633077743617:CommitProcessor@315][] -
Processing request:: sessionid:0x20209eb0002 type:sync: cxid:0x2
zxid:0xfffe txntype:unknown reqpath:/j/k
2014-01-01 12:55:14,299 - DEBUG
[FollowerRequestProcessor:3175620633077743617:CommitProcessor@315][] -
Processing request::
[jira] [Commented] (BOOKKEEPER-661) Turn readonly back to writable if spaces are reclaimed.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872266#comment-13872266 ] Rakesh R commented on BOOKKEEPER-661: - bq.On any unrelated note, why do we register readonly bookies in zookeeper. I don't see it used anywhere on the client? Rakesh R, perhaps you remember? Hi Ivan, As I recollect, readonly bookie information is used in the following cases: # Rereplication : Auditor will be using all the bookies(available + r-o bookies) to see failures. # There is a logic to close channels to dead bookies. This readonly bookieId is used to make it alive and excluding from deadbookie list. # Also, exposed shell command to know the r-o bookies Turn readonly back to writable if spaces are reclaimed. --- Key: BOOKKEEPER-661 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-661 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Reporter: Sijie Guo Assignee: Sijie Guo Fix For: 4.3.0 Attachments: BOOKKEEPER-661.diff, BOOKKEEPER-661.diff, BOOKKEEPER-661_662.diff should be able to turn a bookie from readonly back to writable if the spaces are reclaimed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1861) ConcurrentHashMap isn't used properly in QuorumCnxManager
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872288#comment-13872288
]
Ted Yu commented on ZOOKEEPER-1861:
---
The above suggestion would involve more complex logic.
Maybe the first two hunks in patch v2 can be integrated first ?
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
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-442) need a way to remove watches that are no longer of interest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872308#comment-13872308
]
Patrick Hunt commented on ZOOKEEPER-442:
Looks like the failure was on the c tests (see the console, unfortunately
jenkins doesn't know how to report this in the test report page)
{noformat}
[exec] [exec] Zookeeper_watchers::testChildWatcher1 : elapsed 105 : OK
[exec] [exec] Zookeeper_watchers::testChildWatcher2 : elapsed 54 : OK
[exec] [exec]
/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/src/c/tests/TestReconfig.cc:183:
Assertion: equality assertion failed [Expected: 1, Actual : 0]
[exec] [exec] Failures !!!
{noformat}
I don't think it's related to this though.
need a way to remove watches that are no longer of interest
---
Key: ZOOKEEPER-442
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442
Project: ZooKeeper
Issue Type: Sub-task
Components: java client, server
Reporter: Benjamin Reed
Assignee: Rakesh R
Priority: Critical
Fix For: 3.5.0
Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch
currently the only way a watch cleared is to trigger it. we need a way to
enumerate the outstanding watch objects, find watch events the objects are
watching for, and remove interests in an event.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872334#comment-13872334
]
Raul Gutierrez Segales commented on ZOOKEEPER-442:
--
Sorry guys to distract you from fixing the leak and the tests but there's one
small code smell (imho) in the last version of the patch:
{noformat}
+if (watchers.size() = 0) {
+pathVsWatcher.remove(path);
+}
{noformat}
watchers.size() == 0 should suffice, *if* (as pointed out by Patrick) all our
access around watchers is synchronized. We don't see to be enforcing that so we
might have some races around that.
need a way to remove watches that are no longer of interest
---
Key: ZOOKEEPER-442
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442
Project: ZooKeeper
Issue Type: Sub-task
Components: java client, server
Reporter: Benjamin Reed
Assignee: Rakesh R
Priority: Critical
Fix For: 3.5.0
Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch
currently the only way a watch cleared is to trigger it. we need a way to
enumerate the outstanding watch objects, find watch events the objects are
watching for, and remove interests in an event.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872354#comment-13872354 ] Patrick Hunt commented on ZOOKEEPER-442: Please feel free to update the patch. Can you both (Rakesh/Raul) also code review the synchronization around that code? need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (ZOOKEEPER-1863) Race condition in commit processor leading to out of order request completion, xid mismatch on client.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Camille Fournier updated ZOOKEEPER-1863:
Priority: Blocker (was: Critical)
Race condition in commit processor leading to out of order request
completion, xid mismatch on client.
--
Key: ZOOKEEPER-1863
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1863
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.5.0
Reporter: Dutch T. Meyer
Priority: Blocker
In CommitProcessor.java processor, if we are at the primary request handler
on line 167:
{noformat}
while (!stopped !isWaitingForCommit()
!isProcessingCommit()
(request = queuedRequests.poll()) != null) {
if (needCommit(request)) {
nextPending.set(request);
} else {
sendToNextProcessor(request);
}
}
{noformat}
A request can be handled in this block and be quickly processed and completed
on another thread. If queuedRequests is empty, we then exit the block. Next,
before this thread makes any more progress, we can get 2 more requests, one
get_children(say), and a sync placed on queuedRequests for the processor.
Then, if we are very unlucky, the sync request can complete and this object's
commit() routine is called (from FollowerZookeeperServer), which places the
sync request on the previously empty committedRequests queue. At that point,
this thread continues.
We reach line 182, which is a check on sync requests.
{noformat}
if (!stopped !isProcessingRequest()
(request = committedRequests.poll()) != null) {
{noformat}
Here we are not processing any requests, because the original request has
completed. We haven't dequeued either the read or the sync request in this
processor. Next, the poll above will pull the sync request off the queue, and
in the following block, the sync will get forwarded to the next processor.
This is a problem because the read request hasn't been forwarded yet, so
requests are now out of order.
I've been able to reproduce this bug reliably by injecting a
Thread.sleep(5000) between the two blocks above to make the race condition
far more likely, then in a client program.
{noformat}
zoo_aget_children(zh, /, 0, getchildren_cb, NULL);
//Wait long enough for queuedRequests to drain
sleep(1);
zoo_aget_children(zh, /, 0, getchildren_cb, th_ctx[0]);
zoo_async(zh, /, sync_cb, th_ctx[0]);
{noformat}
When this bug is triggered, 3 things can happen:
1) Clients will see requests complete out of order and fail on xid mismatches.
2) Kazoo in particular doesn't handle this runtime exception well, and can
orphan outstanding requests.
3) I've seen zookeeper servers deadlock, likely because the commit cannot be
completed, which can wedge the commit processor.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1863) Race condition in commit processor leading to out of order request completion, xid mismatch on client.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872376#comment-13872376
]
Camille Fournier commented on ZOOKEEPER-1863:
-
Good catch. Do you want to attempt a patch?
Race condition in commit processor leading to out of order request
completion, xid mismatch on client.
--
Key: ZOOKEEPER-1863
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1863
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.5.0
Reporter: Dutch T. Meyer
Priority: Blocker
In CommitProcessor.java processor, if we are at the primary request handler
on line 167:
{noformat}
while (!stopped !isWaitingForCommit()
!isProcessingCommit()
(request = queuedRequests.poll()) != null) {
if (needCommit(request)) {
nextPending.set(request);
} else {
sendToNextProcessor(request);
}
}
{noformat}
A request can be handled in this block and be quickly processed and completed
on another thread. If queuedRequests is empty, we then exit the block. Next,
before this thread makes any more progress, we can get 2 more requests, one
get_children(say), and a sync placed on queuedRequests for the processor.
Then, if we are very unlucky, the sync request can complete and this object's
commit() routine is called (from FollowerZookeeperServer), which places the
sync request on the previously empty committedRequests queue. At that point,
this thread continues.
We reach line 182, which is a check on sync requests.
{noformat}
if (!stopped !isProcessingRequest()
(request = committedRequests.poll()) != null) {
{noformat}
Here we are not processing any requests, because the original request has
completed. We haven't dequeued either the read or the sync request in this
processor. Next, the poll above will pull the sync request off the queue, and
in the following block, the sync will get forwarded to the next processor.
This is a problem because the read request hasn't been forwarded yet, so
requests are now out of order.
I've been able to reproduce this bug reliably by injecting a
Thread.sleep(5000) between the two blocks above to make the race condition
far more likely, then in a client program.
{noformat}
zoo_aget_children(zh, /, 0, getchildren_cb, NULL);
//Wait long enough for queuedRequests to drain
sleep(1);
zoo_aget_children(zh, /, 0, getchildren_cb, th_ctx[0]);
zoo_async(zh, /, sync_cb, th_ctx[0]);
{noformat}
When this bug is triggered, 3 things can happen:
1) Clients will see requests complete out of order and fail on xid mismatches.
2) Kazoo in particular doesn't handle this runtime exception well, and can
orphan outstanding requests.
3) I've seen zookeeper servers deadlock, likely because the commit cannot be
completed, which can wedge the commit processor.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1863) Race condition in commit processor leading to out of order request completion, xid mismatch on client.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872397#comment-13872397
]
Dutch T. Meyer commented on ZOOKEEPER-1863:
---
I'd be happy to, but it may take me quite some time to get to it - I have many
commitments right now.
I think I'd first look at whether that second block can be protected with a
short circuit check on isWaitingForCommit(). If that's not true then I don't
think we can grab a sync off the committedRequests before it has been pulled
off queuedRequests, which seems to be the core problem. We should probably
think about whether there are any other orderings that would get you to a
similar state though.
Race condition in commit processor leading to out of order request
completion, xid mismatch on client.
--
Key: ZOOKEEPER-1863
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1863
Project: ZooKeeper
Issue Type: Bug
Components: server
Affects Versions: 3.5.0
Reporter: Dutch T. Meyer
Priority: Blocker
In CommitProcessor.java processor, if we are at the primary request handler
on line 167:
{noformat}
while (!stopped !isWaitingForCommit()
!isProcessingCommit()
(request = queuedRequests.poll()) != null) {
if (needCommit(request)) {
nextPending.set(request);
} else {
sendToNextProcessor(request);
}
}
{noformat}
A request can be handled in this block and be quickly processed and completed
on another thread. If queuedRequests is empty, we then exit the block. Next,
before this thread makes any more progress, we can get 2 more requests, one
get_children(say), and a sync placed on queuedRequests for the processor.
Then, if we are very unlucky, the sync request can complete and this object's
commit() routine is called (from FollowerZookeeperServer), which places the
sync request on the previously empty committedRequests queue. At that point,
this thread continues.
We reach line 182, which is a check on sync requests.
{noformat}
if (!stopped !isProcessingRequest()
(request = committedRequests.poll()) != null) {
{noformat}
Here we are not processing any requests, because the original request has
completed. We haven't dequeued either the read or the sync request in this
processor. Next, the poll above will pull the sync request off the queue, and
in the following block, the sync will get forwarded to the next processor.
This is a problem because the read request hasn't been forwarded yet, so
requests are now out of order.
I've been able to reproduce this bug reliably by injecting a
Thread.sleep(5000) between the two blocks above to make the race condition
far more likely, then in a client program.
{noformat}
zoo_aget_children(zh, /, 0, getchildren_cb, NULL);
//Wait long enough for queuedRequests to drain
sleep(1);
zoo_aget_children(zh, /, 0, getchildren_cb, th_ctx[0]);
zoo_async(zh, /, sync_cb, th_ctx[0]);
{noformat}
When this bug is triggered, 3 things can happen:
1) Clients will see requests complete out of order and fail on xid mismatches.
2) Kazoo in particular doesn't handle this runtime exception well, and can
orphan outstanding requests.
3) I've seen zookeeper servers deadlock, likely because the commit cannot be
completed, which can wedge the commit processor.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1858) JMX checks - potential race conditions while stopping and starting server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872444#comment-13872444
]
Patrick Hunt commented on ZOOKEEPER-1858:
-
I see why this is necessary, the patch seems reasonable to me.
One thing caught my eye in the patch
bq. waits in a loop up to 5 seconds
why are we waiting 5 seconds?
JMX checks - potential race conditions while stopping and starting server
-
Key: ZOOKEEPER-1858
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1858
Project: ZooKeeper
Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
Labels: test
Fix For: 3.4.6, 3.5.0
Attachments: ZOOKEEPER-1858-br3.4.patch, ZOOKEEPER-1858.patch,
ZOOKEEPER-1858.patch, ZOOKEEPER-1858.patch
I've noticed one potential case, where previously created zkclient session
immediately reconnected and publishing those beans while starting back the
zkserver and affecting zk#startup jmx checks.
Say, before stopping the server, there is a zk client session
0x143576544c5 exists. While starting back the server, there could be
possibility of seeing the client sessions in jmx. Following is one such case.
Please see below logs which has taken from build
https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/642/
{code}[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[main-SendThread(127.0.0.1:11222):ClientCnxn$SendThread@1228] - Session
establishment complete on server 127.0.0.1/127.0.0.1:11222, sessionid =
0x143576544c5, negotiated timeout = 3
[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11222:ZooKeeperServer@617] -
Established session 0x143576544c5 with negotiated timeout 3 for
client /127.0.0.1:55377{code}
{code} [junit] 2014-01-03 09:18:12,391 [myid:] - INFO [main:JMXEnv@135] -
ensureOnly:[]
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@438] -
STARTING server
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@359] -
CREATING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@334] -
STARTING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=Connections,name2=127.0.0.1,name3=0x143576544c5
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED
testDefaultWatcherAutoResetWithChroot
[junit] junit.framework.AssertionFailedError: expected:0 but was:2
[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 junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:144)
[junit] at
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:443)
[junit] at
org.apache.zookeeper.test.DisconnectedWatcherTest.testDefaultWatcherAutoResetWithChroot(DisconnectedWatcherTest.java:123)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872483#comment-13872483 ] Patrick Hunt commented on ZOOKEEPER-442: I also tried running the same experiment while monitoring the free memory of the ZK Server. I started a standalone zk server with 15m max/initial memory and used jconsole to monitor heap usage while running the zookeeper-removewatches-ex client. With the remove watch call the heap stayed flat over time, 30 minutes or so, after an initial warm up period. (w/o the remove call the server quickly fails with oom exception) Today I plan to add a few more types of remove call scenarios to my simple client and verify things are handled properly, however things look good at the moment. I'll try and see if I can dig up my copy of yourkit as well. Only other thing I see left is to finalize the code review feedback (I hope to do additional code review later today). Anyone else that can help with this would be appreciated. need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-153) add api support for subscribe method
[ https://issues.apache.org/jira/browse/ZOOKEEPER-153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872493#comment-13872493 ] Patrick Hunt commented on ZOOKEEPER-153: See also: ZOOKEEPER-1416 add api support for subscribe method -- Key: ZOOKEEPER-153 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-153 Project: ZooKeeper Issue Type: New Feature Components: c client, documentation, java client, server, tests Reporter: Patrick Hunt Priority: Minor Subscribe Method (note, this was moved from http://zookeeper.wiki.sourceforge.net/SubscribeMethod) Outline of the semantics and the requirements of a yet-to-be-implemented subscribe() method. Background ZooKeeper uses a very light weight one-time notification method for notifying interested clients of changes to ZooKeeper data nodes (znode). Clients can set a watch on a node when they request information about a znode. The watch is atomically set and the data returned, so that any subsequent changes to the znode that affect the data returned will trigger a watch event. The watch stays in place until triggered or the client is disconnected from a ZooKeeper server. A disconnect watch event implicitly triggers all watches. ZooKeeper users have wondered if they can set permanent watches rather than one time watches. In reality such permanent watches do not provide any extra benefit over one time watches. Specifically, no data is included in a watch event, so the client still needs to do a query operation to get the data corresponding to a change; even then, the znode can change yet again after the event is received and before the client sends the query operation. Even the number of of changes to a znode can be found using one time watches and checking the mzxid in the stat structure of the znode. And the client will still miss events that happen when the client switches ZooKeeper servers. There are use cases that require clients to see every change to a ZooKeeper node. The most general case is when a client behaves like a state machine and each change to the znode changes the state of the client. In these cases ZooKeeper is much more like a publish/subscribe system than a distributed register. To support this case we need not only reliable permanent watches (we even get the events that happen while switching servers) but also the data that caused the change, so that the client doesn't miss data that occurs between rapid fire changes. Semantics The subscribe(String path) causes ZooKeeper to register a subscription for a znode. The initial value of the znode and any subsequent changes to that znode will cause a watch event with the data to be sent to the client. The client will see all changes in order. If a client switches servers, any missed events with the corresponding data will be sent to the client when the client reconnects to a server. There are three ways to cancel a subscription: 1. Calling unsubscribe(String path) 2. Closing the ZooKeeper session or letting it expire 3. Falling too far behind. If the server decides that a client is not processing the watch events fast enough, it will cancel the subscription and send a SUBSCRIPTION_CANCELLED watch event. Requirements There are a couple of things that make it hard to implement the subscribe() method: 1. Servers must have complete transaction logs - Currently ZooKeeper servers just need to have their data trees and in flight transaction logs in sync. When a follower syncs to a leader, the leader can just blast down a new snapshot of its data tree; it does not need to send past transactions that the follower might have missed. However in order to send changes that might have been missed by a client, the ZooKeeper server must be able to look into the past to send missed changes. 2. Servers must be able to send clients information about past changes - Currenly ZooKeeper servers just send clients information about the current state of the system. However, to implement subscribe clients must be able to go back into the log and send watches for past changes. Implementation Hints There are things that work in our favor. ZooKeeper does have a bound on the amount of time it needs to look into the past. A ZooKeeper server bounds the session expiration time. The server does not need to keep a record of transactions older than this bound. ZooKeeper also keeps a log of transactions. As long as the log is complete enough (as all the transaction back to the longest expiration time) the server has the information it needs and it isn't hard to process. We do not want to cause the log disk to seek while looking at past transactions. There are two complimentary approaches to
[jira] [Commented] (BOOKKEEPER-661) Turn readonly back to writable if spaces are reclaimed.
[
https://issues.apache.org/jira/browse/BOOKKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872498#comment-13872498
]
Sijie Guo commented on BOOKKEEPER-661:
--
{quote}
It would be better to modify registerBookie() to get check if the
Stat.getEphemeralOwner == current zk session id. In this case, registerBookie
can just return. I think this is safer.
{quote}
checking session id is the safer way. will do that.
{quote}
Do we need diskWritable() diskJustWritable()? They seem to be handled the
same.
{quote}
they are related to DiskWarnThreshold and DiskSpaceThreshold. we handle
different action in gc. when disk is just writable, we need to force gc.
Turn readonly back to writable if spaces are reclaimed.
---
Key: BOOKKEEPER-661
URL: https://issues.apache.org/jira/browse/BOOKKEEPER-661
Project: Bookkeeper
Issue Type: Improvement
Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Sijie Guo
Fix For: 4.3.0
Attachments: BOOKKEEPER-661.diff, BOOKKEEPER-661.diff,
BOOKKEEPER-661_662.diff
should be able to turn a bookie from readonly back to writable if the spaces
are reclaimed.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
ZooKeeper-trunk-openjdk7 - Build # 362 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk-openjdk7/362/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 262415 lines...] [junit] 2014-01-15 20:31:48,143 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop! [junit] 2014-01-15 20:31:48,143 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2014-01-15 20:31:48,143 [myid:] - INFO [main:FinalRequestProcessor@442] - shutdown of request processor complete [junit] 2014-01-15 20:31:48,144 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-01-15 20:31:48,145 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2014-01-15 20:31:48,146 [myid:] - INFO [main:ClientBase@439] - STARTING server [junit] 2014-01-15 20:31:48,146 [myid:] - INFO [main:ClientBase@360] - CREATING server instance 127.0.0.1:11221 [junit] 2014-01-15 20:31:48,146 [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-01-15 20:31:48,147 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-01-15 20:31:48,147 [myid:] - INFO [main:ClientBase@335] - STARTING server instance 127.0.0.1:11221 [junit] 2014-01-15 20:31:48,148 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test9080564673360512317.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test9080564673360512317.junit.dir/version-2 [junit] 2014-01-15 20:31:48,149 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test9080564673360512317.junit.dir/version-2/snapshot.b [junit] 2014-01-15 20:31:48,151 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-openjdk7/trunk/build/test/tmp/test9080564673360512317.junit.dir/version-2/snapshot.b [junit] 2014-01-15 20:31:48,153 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-01-15 20:31:48,153 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:56853 [junit] 2014-01-15 20:31:48,154 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:56853 [junit] 2014-01-15 20:31:48,154 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-01-15 20:31:48,155 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:56853 (no session established for client) [junit] 2014-01-15 20:31:48,155 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-01-15 20:31:48,157 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2014-01-15 20:31:48,157 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-01-15 20:31:48,157 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2014-01-15 20:31:48,157 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-01-15 20:31:48,157 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 35136 [junit] 2014-01-15 20:31:48,158 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-01-15 20:31:48,158 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-01-15 20:31:48,158 [myid:] - INFO [main:ClientBase@478] - tearDown starting [junit] 2014-01-15 20:31:48,225 [myid:] - INFO [main:ZooKeeper@777] - Session: 0x143979a47fc closed [junit] 2014-01-15 20:31:48,225 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down [junit] 2014-01-15 20:31:48,226 [myid:] - INFO [main:ClientBase@448] - STOPPING server [junit] 2014-01-15 20:31:48,227 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2014-01-15 20:31:48,227 [myid:] - INFO
[jira] [Commented] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872610#comment-13872610 ] Flavio Junqueira commented on ZOOKEEPER-1837: - Can't we have the case that nTry = 50 and foundUnexpected is false? Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1858) JMX checks - potential race conditions while stopping and starting server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872943#comment-13872943
]
Rakesh R commented on ZOOKEEPER-1858:
-
Thanks [~fpj], [~phunt] for the reviews.
bq.why are we waiting 5 seconds?
Please see ZOOKEEPER-1837 issue. There is a pattern we had observed while
analysing the windows jenkins failure, it may take few moments to see the
published beans by the clients and the test cases are failing randomly due to
this. So its giving some more grace period rather than failing immediately.
JMX checks - potential race conditions while stopping and starting server
-
Key: ZOOKEEPER-1858
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1858
Project: ZooKeeper
Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
Labels: test
Fix For: 3.4.6, 3.5.0
Attachments: ZOOKEEPER-1858-br3.4.patch, ZOOKEEPER-1858.patch,
ZOOKEEPER-1858.patch, ZOOKEEPER-1858.patch
I've noticed one potential case, where previously created zkclient session
immediately reconnected and publishing those beans while starting back the
zkserver and affecting zk#startup jmx checks.
Say, before stopping the server, there is a zk client session
0x143576544c5 exists. While starting back the server, there could be
possibility of seeing the client sessions in jmx. Following is one such case.
Please see below logs which has taken from build
https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/642/
{code}[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[main-SendThread(127.0.0.1:11222):ClientCnxn$SendThread@1228] - Session
establishment complete on server 127.0.0.1/127.0.0.1:11222, sessionid =
0x143576544c5, negotiated timeout = 3
[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11222:ZooKeeperServer@617] -
Established session 0x143576544c5 with negotiated timeout 3 for
client /127.0.0.1:55377{code}
{code} [junit] 2014-01-03 09:18:12,391 [myid:] - INFO [main:JMXEnv@135] -
ensureOnly:[]
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@438] -
STARTING server
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@359] -
CREATING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@334] -
STARTING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=Connections,name2=127.0.0.1,name3=0x143576544c5
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED
testDefaultWatcherAutoResetWithChroot
[junit] junit.framework.AssertionFailedError: expected:0 but was:2
[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 junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:144)
[junit] at
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:443)
[junit] at
org.apache.zookeeper.test.DisconnectedWatcherTest.testDefaultWatcherAutoResetWithChroot(DisconnectedWatcherTest.java:123)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-1858) JMX checks - potential race conditions while stopping and starting server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872953#comment-13872953
]
Patrick Hunt commented on ZOOKEEPER-1858:
-
The reason I ask, 5 seconds is pretty short. What typically ends up happening
is that it works fine for you, but on lesser powered (underprovisioned) test
hardware it will fail. We end up with a flakey test. What I'd suggest is either
don't use a timeout, or, if you do need to use a timeout use something crazy
large (60 sec?), typically including polling at a shorter interval. The key is
that the test, in the typical case, should not be affected by the 60sec timeout
(it should not take 60 sec longer for example) but if the h/w is slow we can
handle that case and still give the test a chance to pass.
JMX checks - potential race conditions while stopping and starting server
-
Key: ZOOKEEPER-1858
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1858
Project: ZooKeeper
Issue Type: Sub-task
Reporter: Rakesh R
Assignee: Rakesh R
Labels: test
Fix For: 3.4.6, 3.5.0
Attachments: ZOOKEEPER-1858-br3.4.patch, ZOOKEEPER-1858.patch,
ZOOKEEPER-1858.patch, ZOOKEEPER-1858.patch
I've noticed one potential case, where previously created zkclient session
immediately reconnected and publishing those beans while starting back the
zkserver and affecting zk#startup jmx checks.
Say, before stopping the server, there is a zk client session
0x143576544c5 exists. While starting back the server, there could be
possibility of seeing the client sessions in jmx. Following is one such case.
Please see below logs which has taken from build
https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/642/
{code}[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[main-SendThread(127.0.0.1:11222):ClientCnxn$SendThread@1228] - Session
establishment complete on server 127.0.0.1/127.0.0.1:11222, sessionid =
0x143576544c5, negotiated timeout = 3
[junit] 2014-01-03 09:18:12,809 [myid:] - INFO
[NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11222:ZooKeeperServer@617] -
Established session 0x143576544c5 with negotiated timeout 3 for
client /127.0.0.1:55377{code}
{code} [junit] 2014-01-03 09:18:12,391 [myid:] - INFO [main:JMXEnv@135] -
ensureOnly:[]
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@438] -
STARTING server
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@359] -
CREATING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO
[main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11222
[junit] 2014-01-03 09:18:12,395 [myid:] - INFO [main:ClientBase@334] -
STARTING server instance 127.0.0.1:11222
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=Connections,name2=127.0.0.1,name3=0x143576544c5
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO [main:JMXEnv@142] -
unexpected:org.apache.ZooKeeperService:name0=StandaloneServer_port-1
[junit] 2014-01-03 09:18:19,030 [myid:] - INFO
[main:JUnit4ZKTestRunner$LoggedInvokeMethod@62] - TEST METHOD FAILED
testDefaultWatcherAutoResetWithChroot
[junit] junit.framework.AssertionFailedError: expected:0 but was:2
[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 junit.framework.Assert.assertEquals(Assert.java:201)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:144)
[junit] at
org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:443)
[junit] at
org.apache.zookeeper.test.DisconnectedWatcherTest.testDefaultWatcherAutoResetWithChroot(DisconnectedWatcherTest.java:123)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
{code}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872964#comment-13872964
]
Rakesh R commented on ZOOKEEPER-442:
Thanks again [~phunt], [~rgs] for the great help.
Sure, I'll once again go through the code closely and see the
synchronizations/improvements(if any).
bq.watchers.size() == 0 should suffice, if (as pointed out by Patrick) all our
access around watchers is synchronized. We don't see to be enforcing that so we
might have some races around that.
Hi Raul, Are you pointing me to see the synchronization of the newly added
code.
The new logic included to fix the leak is already inside the synchronization
block as shown below, so this part of the code is safer.
{code}
synchronized (existWatches) {
+boolean removedDataWatcher = removeWatches(existWatches,
+watcher, clientPath, local, rc, dataWatchersToRem);
+removedWatcher |= removedDataWatcher;
+}
{code}
need a way to remove watches that are no longer of interest
---
Key: ZOOKEEPER-442
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442
Project: ZooKeeper
Issue Type: Sub-task
Components: java client, server
Reporter: Benjamin Reed
Assignee: Rakesh R
Priority: Critical
Fix For: 3.5.0
Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch,
ZOOKEEPER-442.patch
currently the only way a watch cleared is to trigger it. we need a way to
enumerate the outstanding watch objects, find watch events the objects are
watching for, and remove interests in an event.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873080#comment-13873080 ] Patrick Hunt commented on ZOOKEEPER-442: [~rakeshr] I think that Raul's point was/is that checking for less than zero is not necessary. My point was just a note for reviewers - that we need to ensure the concurrency is correct. (and I hear that you are saying that it is/should be) FYI my CI environment has been running all day with the latest patch, no issues so far. need a way to remove watches that are no longer of interest --- Key: ZOOKEEPER-442 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 Project: ZooKeeper Issue Type: Sub-task Components: java client, server Reporter: Benjamin Reed Assignee: Rakesh R Priority: Critical Fix For: 3.5.0 Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch currently the only way a watch cleared is to trigger it. we need a way to enumerate the outstanding watch objects, find watch events the objects are watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
ZooKeeper_branch33_solaris - Build # 769 - Still Failing
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/769/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by timer Building remotely on solaris1 in workspace /export/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:722) at hudson.EnvVars.getRemote(EnvVars.java:396) at hudson.model.Computer.getEnvironment(Computer.java:908) at jenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:29) at hudson.model.Run.getEnvironment(Run.java:2191) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:914) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Unexpected termination of the channel at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:782) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69) Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2598) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1318) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:370) at hudson.remoting.Command.readFrom(Command.java:92) at hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:71) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873124#comment-13873124 ] Germán Blanco commented on ZOOKEEPER-1837: -- If the condition (nTry 50) is false, then the loop ends. So nTry will never be above 50. The border case is that nTry reaches 50 and by chance in that last run through the loop there is no unexpected beans found. But that case works just as any other value below 50, it means JMX manage to synchronized to the expected state after 5 seconds and no failure needs to be reported. Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at
[jira] [Commented] (ZOOKEEPER-1837) Fix JMXEnv checks (potential race conditions)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13873126#comment-13873126 ] Germán Blanco commented on ZOOKEEPER-1837: -- I will update the timeouts according to [~phunt]'s comment to ZOOKEEPER-1858. Fix JMXEnv checks (potential race conditions) - Key: ZOOKEEPER-1837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1837 Project: ZooKeeper Issue Type: Sub-task Components: tests Affects Versions: 3.4.5, 3.5.0 Environment: Windows 8 Reporter: Germán Blanco Assignee: Germán Blanco Fix For: 3.4.6, 3.5.0 Attachments: ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837-b3.4.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch, ZOOKEEPER-1837.patch The following failures in ZooKeeper-3.4-WinVS2008_java and ZooKeeper-trunk-WinVS2008_java require fixing: [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] junit.framework.AssertionFailedError: expected:0 but was:1 [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 junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:80) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [ junit.framework.AssertionFailedError: expected [0x142e5f027b50001] expected:1 but was:0 at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:115) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:197) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156) at org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149) at org.apache.zookeeper.ZooKeeperTest.testDeleteRecursive(ZooKeeperTest.java:45) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Resolved] (BOOKKEEPER-519) Ensure all threads in BookKeeper/Hedwig have meaningful names
[ https://issues.apache.org/jira/browse/BOOKKEEPER-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sijie Guo resolved BOOKKEEPER-519. -- Resolution: Won't Fix grep the code base now, it seems that all the threads are already have meaningful now. so close the ticket now. we could re-open it when we found some threads need to add names. Ensure all threads in BookKeeper/Hedwig have meaningful names - Key: BOOKKEEPER-519 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-519 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-auto-recovery, bookkeeper-server, hedwig-server Reporter: Ivan Kelly Fix For: 4.3.0 As summary says, give them all names. They should also be unique within tests so that debugging test failures is easier. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (BOOKKEEPER-661) Turn readonly back to writable if spaces are reclaimed.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sijie Guo updated BOOKKEEPER-661: - Attachment: BOOKKEEPER-661_662.diff attach a patch with BOOKKEEPER-662 changes for precommit job. Turn readonly back to writable if spaces are reclaimed. --- Key: BOOKKEEPER-661 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-661 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Reporter: Sijie Guo Assignee: Sijie Guo Fix For: 4.3.0 Attachments: BOOKKEEPER-661.diff, BOOKKEEPER-661.diff, BOOKKEEPER-661_662.diff should be able to turn a bookie from readonly back to writable if the spaces are reclaimed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (BOOKKEEPER-662) Major GC should kick in immediately if remaining space reaches a warning threshold
[
https://issues.apache.org/jira/browse/BOOKKEEPER-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871807#comment-13871807
]
Hadoop QA commented on BOOKKEEPER-662:
--
Testing JIRA BOOKKEEPER-662
Patch
[BOOKKEEPER-662.diff|https://issues.apache.org/jira/secure/attachment/12623085/BOOKKEEPER-662.diff]
downloaded at Wed Jan 15 08:03:30 UTC 2014
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
120
.{color:green}+1{color} the patch does adds/modifies 4 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 FINDBUGS{color}
.{color:green}+1{color} the patch does not seem to introduce new Findbugs
warnings
{color:green}+1 TESTS{color}
.Tests run: 887
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:green}*+1 Overall result, good!, no -1s*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/bookkeeper-trunk-precommit-build/554/
Major GC should kick in immediately if remaining space reaches a warning
threshold
--
Key: BOOKKEEPER-662
URL: https://issues.apache.org/jira/browse/BOOKKEEPER-662
Project: Bookkeeper
Issue Type: Improvement
Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Aniruddha
Fix For: 4.3.0
Attachments: 0001-WIP.patch, BOOKKEEPER-662.diff,
BOOKKEEPER-662.diff, BOOKKEEPER-662.diff
in a high throughput case, Major GC should kick in immediately if remaining
spaces reaches a warning threshold.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Commented] (BOOKKEEPER-510) LedgerRecoveryOp updates metadata before it needs to
[ https://issues.apache.org/jira/browse/BOOKKEEPER-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871815#comment-13871815 ] Sijie Guo commented on BOOKKEEPER-510: -- [~ikelly] I still don't understand. This issue seems not be a problem anymore. - recovery only updates metadata when close since BOOKKEEPER-355 - recovery op keeps a copy of metadata for recovery reading in BOOKKEEPER-510. Could you clarify what is the ticket for? if not an issue, shall we close it? LedgerRecoveryOp updates metadata before it needs to Key: BOOKKEEPER-510 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-510 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-client Reporter: Ivan Kelly Fix For: 4.3.0 Attachments: 0002-BOOKKEEPER-510-LedgerRecoveryOp-updates-metadata-bef.patch This could lead to an issue if there are a lot of errors in a specific order. You have a ledger with ensemble (B1, B2, B3) # B1 brought down for maintenance # Ledger recovery started # B2 answers read last confirmed. # B1 replaced in ensemble by B4 # Write to B4 fails for some reason # B1 comes back up. # B2 goes down for maintenance. # Ledger recovery starts (ledger is now unavailable) See BOOKKEEPER-355 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Comment Edited] (BOOKKEEPER-510) LedgerRecoveryOp updates metadata before it needs to
[ https://issues.apache.org/jira/browse/BOOKKEEPER-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871815#comment-13871815 ] Sijie Guo edited comment on BOOKKEEPER-510 at 1/15/14 8:48 AM: --- [~ikelly] I still don't understand. This issue seems not be a problem anymore. - recovery only updates metadata when close since BOOKKEEPER-355 - recovery op keeps a copy of metadata for recovery reading in BOOKKEEPER-581. Could you clarify what is the ticket for? if not an issue, shall we close it? was (Author: hustlmsp): [~ikelly] I still don't understand. This issue seems not be a problem anymore. - recovery only updates metadata when close since BOOKKEEPER-355 - recovery op keeps a copy of metadata for recovery reading in BOOKKEEPER-510. Could you clarify what is the ticket for? if not an issue, shall we close it? LedgerRecoveryOp updates metadata before it needs to Key: BOOKKEEPER-510 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-510 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-client Reporter: Ivan Kelly Fix For: 4.3.0 Attachments: 0002-BOOKKEEPER-510-LedgerRecoveryOp-updates-metadata-bef.patch This could lead to an issue if there are a lot of errors in a specific order. You have a ledger with ensemble (B1, B2, B3) # B1 brought down for maintenance # Ledger recovery started # B2 answers read last confirmed. # B1 replaced in ensemble by B4 # Write to B4 fails for some reason # B1 comes back up. # B2 goes down for maintenance. # Ledger recovery starts (ledger is now unavailable) See BOOKKEEPER-355 -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (BOOKKEEPER-710) OpenLedgerNoRecovery should watch ensemble change.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13871950#comment-13871950 ] Ivan Kelly commented on BOOKKEEPER-710: --- How do you communicate the change in LAC to the client. The client will be still be polling by calling readLastAddConfirmed, no? OpenLedgerNoRecovery should watch ensemble change. -- Key: BOOKKEEPER-710 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-710 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-client Reporter: Sijie Guo Assignee: Sijie Guo Priority: Blocker Fix For: 4.3.0, 4.2.3 Attachments: BOOKKEEPER-710.diff LedgerHandle opened by openLedgerNoRecovery should watch ensemble change. otherwise, readLastConfirmed readEntries will stuck if there are ensemble changes in the ledger. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (BOOKKEEPER-708) Shade protobuf library to avoid incompatible versions
[ https://issues.apache.org/jira/browse/BOOKKEEPER-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Kelly updated BOOKKEEPER-708: -- Attachment: 0001-BOOKKEEPER-708-Shade-protobuf-library-to-avoid-incom.patch Shade protobuf library to avoid incompatible versions - Key: BOOKKEEPER-708 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-708 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-server Reporter: Sijie Guo Assignee: Rakesh R Fix For: 4.3.0, 4.2.3 Attachments: 0001-BOOKKEEPER-708-Shade-protobuf-library-to-avoid-incom.patch, 0001-BOOKKEEPER-708.patch, 0002-BOOKKEEPER-708.patch as offline discussion, we need to shade protobuf library for BKJM as hadoop uses protobuf 2.5. this is planned on version 4.2.3 and 4.3.0. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (BOOKKEEPER-708) Shade protobuf library to avoid incompatible versions
[ https://issues.apache.org/jira/browse/BOOKKEEPER-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872082#comment-13872082 ] Ivan Kelly commented on BOOKKEEPER-708: --- I've set createDependencyReducedPom to true in a new patch. Regarding the jar in the dist bin package, I don't think it's easy to exclude it without hacking around it, any having it there does no harm. Shading the deps is only important for the client. The dist bin package is the server. Shade protobuf library to avoid incompatible versions - Key: BOOKKEEPER-708 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-708 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-server Reporter: Sijie Guo Assignee: Rakesh R Fix For: 4.3.0, 4.2.3 Attachments: 0001-BOOKKEEPER-708-Shade-protobuf-library-to-avoid-incom.patch, 0001-BOOKKEEPER-708.patch, 0002-BOOKKEEPER-708.patch as offline discussion, we need to shade protobuf library for BKJM as hadoop uses protobuf 2.5. this is planned on version 4.2.3 and 4.3.0. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (BOOKKEEPER-708) Shade protobuf library to avoid incompatible versions
[
https://issues.apache.org/jira/browse/BOOKKEEPER-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872123#comment-13872123
]
Hadoop QA commented on BOOKKEEPER-708:
--
Testing JIRA BOOKKEEPER-708
Patch
[0001-BOOKKEEPER-708-Shade-protobuf-library-to-avoid-incom.patch|https://issues.apache.org/jira/secure/attachment/12623139/0001-BOOKKEEPER-708-Shade-protobuf-library-to-avoid-incom.patch]
downloaded at Wed Jan 15 14:00:48 UTC 2014
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:red}-1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
120
.{color:red}-1{color} the patch does not add/modify any testcase
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 FINDBUGS{color}
.{color:green}+1{color} the patch does not seem to introduce new Findbugs
warnings
{color:green}+1 TESTS{color}
.Tests run: 885
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:red}*-1 Overall result, please check the reported -1(s)*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/bookkeeper-trunk-precommit-build/556/
Shade protobuf library to avoid incompatible versions
-
Key: BOOKKEEPER-708
URL: https://issues.apache.org/jira/browse/BOOKKEEPER-708
Project: Bookkeeper
Issue Type: Bug
Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Rakesh R
Fix For: 4.3.0, 4.2.3
Attachments:
0001-BOOKKEEPER-708-Shade-protobuf-library-to-avoid-incom.patch,
0001-BOOKKEEPER-708.patch, 0002-BOOKKEEPER-708.patch
as offline discussion, we need to shade protobuf library for BKJM as hadoop
uses protobuf 2.5.
this is planned on version 4.2.3 and 4.3.0.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
Build failed in Jenkins: bookkeeper-trunk #509
See https://builds.apache.org/job/bookkeeper-trunk/509/changes Changes: [ivank] BOOKKEEPER-662: Major GC should kick in immediately if remaining space reaches a warning threshold (sijie via ivank) -- [...truncated 449 lines...] [INFO] Compiling 6 source files to https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/classes [INFO] [INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ hedwig-protocol --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/src/test/resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ hedwig-protocol --- [INFO] No sources to compile [INFO] [INFO] --- maven-surefire-plugin:2.9:test (default-test) @ hedwig-protocol --- [INFO] Surefire report directory: https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/surefire-reports --- T E S T S --- --- T E S T S --- Results : Tests run: 0, Failures: 0, Errors: 0, Skipped: 0 [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ hedwig-protocol --- [INFO] Building jar: https://builds.apache.org/job/bookkeeper-trunk/ws/hedwig-protocol/target/hedwig-protocol-4.3.0-SNAPSHOT.jar [INFO] [INFO] findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol [INFO] [INFO] --- findbugs-maven-plugin:2.5.2:findbugs (findbugs) @ hedwig-protocol --- [INFO] Fork Value is true [INFO] Done FindBugs Analysis [INFO] [INFO] findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol [INFO] [INFO] --- findbugs-maven-plugin:2.5.2:check (default-cli) @ hedwig-protocol --- [INFO] BugInstance size is 0 [INFO] Error size is 0 [INFO] No errors/warnings found [INFO] [INFO] [INFO] Building bookkeeper-server 4.3.0-SNAPSHOT [INFO] [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ bookkeeper-server --- [INFO] [INFO] --- apache-rat-plugin:0.7:check (default-cli) @ bookkeeper-server --- [INFO] Exclude: **/DataFormats.java [INFO] [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ bookkeeper-server --- [INFO] [INFO] --- maven-resources-plugin:2.4.3:resources (default-resources) @ bookkeeper-server --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 3 resources [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.0:compile (default-compile) @ bookkeeper-server --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 159 source files to https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/classes [INFO] [INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ bookkeeper-server --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] Copying 1 resource [INFO] Copying 3 resources [INFO] [INFO] --- maven-compiler-plugin:3.0:testCompile (default-testCompile) @ bookkeeper-server --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 79 source files to https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/test-classes [INFO] [INFO] --- maven-surefire-plugin:2.9:test (default-test) @ bookkeeper-server --- [INFO] Surefire report directory: https://builds.apache.org/job/bookkeeper-trunk/ws/bookkeeper-server/target/surefire-reports --- T E S T S --- --- T E S T S --- Running org.apache.bookkeeper.replication.AutoRecoveryMainTest Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 4.167 sec Running org.apache.bookkeeper.replication.BookieAutoRecoveryTest Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 28.589 sec Running org.apache.bookkeeper.replication.BookieLedgerIndexTest Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 8.883 sec Running org.apache.bookkeeper.replication.AuditorPeriodicCheckTest Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.802 sec Running org.apache.bookkeeper.replication.AuditorLedgerCheckerTest Tests run: 18, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 54.173 sec FAILURE! Running org.apache.bookkeeper.replication.TestLedgerUnderreplicationManager Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.492 sec Running
[jira] [Commented] (BOOKKEEPER-662) Major GC should kick in immediately if remaining space reaches a warning threshold
[ https://issues.apache.org/jira/browse/BOOKKEEPER-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872166#comment-13872166 ] Hudson commented on BOOKKEEPER-662: --- FAILURE: Integrated in bookkeeper-trunk #509 (See [https://builds.apache.org/job/bookkeeper-trunk/509/]) BOOKKEEPER-662: Major GC should kick in immediately if remaining space reaches a warning threshold (sijie via ivank) (ivank: rev 1558410) * /zookeeper/bookkeeper/trunk/CHANGES.txt * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/Bookie.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/EntryLogger.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/GarbageCollectorThread.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/IndexPersistenceMgr.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/InterleavedLedgerStorage.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/LedgerDirsManager.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/conf/ServerConfiguration.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/util/DiskChecker.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/BookieInitializationTest.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/CompactionTest.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/TestSyncThread.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/util/TestDiskChecker.java Major GC should kick in immediately if remaining space reaches a warning threshold -- Key: BOOKKEEPER-662 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-662 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Reporter: Sijie Guo Assignee: Aniruddha Fix For: 4.3.0 Attachments: 0001-WIP.patch, BOOKKEEPER-662.diff, BOOKKEEPER-662.diff, BOOKKEEPER-662.diff in a high throughput case, Major GC should kick in immediately if remaining spaces reaches a warning threshold. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Commented] (BOOKKEEPER-662) Major GC should kick in immediately if remaining space reaches a warning threshold
[ https://issues.apache.org/jira/browse/BOOKKEEPER-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872171#comment-13872171 ] Flavio Junqueira commented on BOOKKEEPER-662: - It is possibly not related to the committed patch, but this test case failed according to build 509: org.apache.bookkeeper.replication.AuditorLedgerCheckerTest.testToggleLedgerReplication[2] Major GC should kick in immediately if remaining space reaches a warning threshold -- Key: BOOKKEEPER-662 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-662 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Reporter: Sijie Guo Assignee: Aniruddha Fix For: 4.3.0 Attachments: 0001-WIP.patch, BOOKKEEPER-662.diff, BOOKKEEPER-662.diff, BOOKKEEPER-662.diff in a high throughput case, Major GC should kick in immediately if remaining spaces reaches a warning threshold. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
Re: hedwig-client-jms build failing
This is the test case failing for me: Failed tests: testSimpleChat(org.apache.hedwig.jms.BasicJMSTest) If you want I can create a jira and post logs. -Flavio Flavio: What's the error? Compilation error? or Test error? Could you send more info? - Sijie On Tue, Jan 14, 2014 at 3:17 PM, Flavio Junqueira fpjunque...@yahoo.com wrote: Does it fail for you people? It is failing for me… -Flavio
[jira] [Commented] (BOOKKEEPER-662) Major GC should kick in immediately if remaining space reaches a warning threshold
[ https://issues.apache.org/jira/browse/BOOKKEEPER-662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13872177#comment-13872177 ] Ivan Kelly commented on BOOKKEEPER-662: --- Probably unrelated. That test has a history of flake. Part of it also failed on build 505. Creating JIRA for it. Major GC should kick in immediately if remaining space reaches a warning threshold -- Key: BOOKKEEPER-662 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-662 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Reporter: Sijie Guo Assignee: Aniruddha Fix For: 4.3.0 Attachments: 0001-WIP.patch, BOOKKEEPER-662.diff, BOOKKEEPER-662.diff, BOOKKEEPER-662.diff in a high throughput case, Major GC should kick in immediately if remaining spaces reaches a warning threshold. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (BOOKKEEPER-718) AuditorLedgerCheckerTest is flakey
Ivan Kelly created BOOKKEEPER-718: - Summary: AuditorLedgerCheckerTest is flakey Key: BOOKKEEPER-718 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-718 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-auto-recovery Reporter: Ivan Kelly Fix For: 4.3.0 Attachments: error505.txt, error509.txt See: https://builds.apache.org/job/bookkeeper-trunk/505/ https://builds.apache.org/job/bookkeeper-trunk/509 Relevant errors attached. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (BOOKKEEPER-718) AuditorLedgerCheckerTest is flakey
[ https://issues.apache.org/jira/browse/BOOKKEEPER-718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Kelly updated BOOKKEEPER-718: -- Attachment: error509.txt error505.txt AuditorLedgerCheckerTest is flakey -- Key: BOOKKEEPER-718 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-718 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-auto-recovery Reporter: Ivan Kelly Fix For: 4.3.0 Attachments: error505.txt, error509.txt See: https://builds.apache.org/job/bookkeeper-trunk/505/ https://builds.apache.org/job/bookkeeper-trunk/509 Relevant errors attached. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Reopened] (BOOKKEEPER-661) Turn readonly back to writable if spaces are reclaimed.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sijie Guo reopened BOOKKEEPER-661: -- not sure why this was resolved. :( Turn readonly back to writable if spaces are reclaimed. --- Key: BOOKKEEPER-661 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-661 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Reporter: Sijie Guo Assignee: Sijie Guo Fix For: 4.3.0 Attachments: BOOKKEEPER-661.diff, BOOKKEEPER-661.diff, BOOKKEEPER-661_662.diff should be able to turn a bookie from readonly back to writable if the spaces are reclaimed. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
