ZooKeeper_branch33_solaris - Build # 822 - Failure
See https://builds.apache.org/job/ZooKeeper_branch33_solaris/822/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 90681 lines...] [junit] 2014-03-12 07:05:31,565 - INFO [main:ZooKeeperServer@154] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test985159284615153425.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test985159284615153425.junit.dir/version-2 [junit] 2014-03-12 07:05:31,566 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-12 07:05:31,567 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test985159284615153425.junit.dir/version-2/snapshot.0 [junit] 2014-03-12 07:05:31,571 - INFO [main:FileTxnSnapLog@256] - Snapshotting: b [junit] 2014-03-12 07:05:31,573 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 07:05:31,574 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:52066 [junit] 2014-03-12 07:05:31,574 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:52066 [junit] 2014-03-12 07:05:31,575 - INFO [Thread-4:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2014-03-12 07:05:31,576 - INFO [Thread-4:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:52066 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-12 07:05:31,578 - INFO [main:ClientBase@408] - STOPPING server [junit] 2014-03-12 07:05:31,580 - INFO [ProcessThread:-1:PrepRequestProcessor@128] - PrepRequestProcessor exited loop! [junit] 2014-03-12 07:05:31,580 - INFO [SyncThread:0:SyncRequestProcessor@151] - SyncRequestProcessor exited! [junit] 2014-03-12 07:05:31,580 - INFO [main:FinalRequestProcessor@370] - shutdown of request processor complete [junit] 2014-03-12 07:05:31,581 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] ensureOnly:[] [junit] 2014-03-12 07:05:31,583 - INFO [main:ClientBase@401] - STARTING server [junit] 2014-03-12 07:05:31,584 - INFO [main:ZooKeeperServer@154] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test985159284615153425.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test985159284615153425.junit.dir/version-2 [junit] 2014-03-12 07:05:31,585 - INFO [main:NIOServerCnxn$Factory@143] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-12 07:05:31,586 - INFO [main:FileSnap@82] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper_branch33_solaris/trunk/build/test/tmp/test985159284615153425.junit.dir/version-2/snapshot.b [junit] 2014-03-12 07:05:31,588 - INFO [main:FileTxnSnapLog@256] - Snapshotting: b [junit] 2014-03-12 07:05:31,590 - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 07:05:31,591 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn$Factory@251] - Accepted socket connection from /127.0.0.1:52068 [junit] 2014-03-12 07:05:31,591 - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@1237] - Processing stat command from /127.0.0.1:52068 [junit] 2014-03-12 07:05:31,592 - INFO [Thread-5:NIOServerCnxn$StatCommand@1153] - Stat command output [junit] 2014-03-12 07:05:31,592 - INFO [Thread-5:NIOServerCnxn@1435] - Closed socket connection for client /127.0.0.1:52068 (no session established for client) [junit] ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] expect:InMemoryDataTree [junit] found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] expect:StandaloneServer_port [junit] found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-12 07:05:31,594 - INFO
[jira] [Commented] (ZOOKEEPER-1665) Support recursive deletion in multi
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931552#comment-13931552
]
Rakesh R commented on ZOOKEEPER-1665:
-
Hi [~yuzhih...@gmail.com],
My bad, previously when I tested multi api it failed. Now its working fine for
me. I don't have a strong point to expose a new utility api for
multiDeleteRecursive(). Because users can still achieve the behavior through
the existing ZKUtil and ZooKeeper exposed apis. If anybody interested, I
would be happy to convert the snippet into a patch.
Please see the below snippet where it shows one pattern to achieve it, here you
can pass String array {acquiredZnode, reachedZnode, abortZnode} or if you dont
want the transaction across pathRoots, simply pass one by one. Hope this will
help you.
{code}
public static ListOpResult multiDeleteRecursive(ZooKeeper zk,
String... pathRoots) throws InterruptedException, KeeperException {
// TODO: handle empty pathRoots and return.
ListOp opList = new ArrayListOp();
for (String eachPath : pathRoots) {
ListOp eachRoot = prepareOpList(zk, eachPath);
opList.addAll(eachRoot);
}
return zk.multi(opList);
}
private static ListOp prepareOpList(ZooKeeper zk, final String pathRoot)
throws InterruptedException, KeeperException {
PathUtils.validatePath(pathRoot);
ListString tree = ZKUtil.listSubTreeBFS(zk, pathRoot);
LOG.debug(Deleting + tree);
LOG.debug(Deleting + tree.size() + subnodes );
ListOp opList = new ArrayListOp(tree.size());
for (int i = tree.size() - 1; i = 0; --i) {
// Delete the leaves first and eventually get rid of the root
opList.add(Op.delete(tree.get(i), -1));
}
return opList;
}
{code}
Thanks,
Rakesh
Support recursive deletion in multi
---
Key: ZOOKEEPER-1665
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1665
Project: ZooKeeper
Issue Type: New Feature
Reporter: Ted Yu
Use case in HBase is that we need to recursively delete multiple subtrees:
{code}
ZKUtil.deleteChildrenRecursively(watcher, acquiredZnode);
ZKUtil.deleteChildrenRecursively(watcher, reachedZnode);
ZKUtil.deleteChildrenRecursively(watcher, abortZnode);
{code}
To achieve high consistency, it is desirable to use multi for the above
operations.
This JIRA adds support for recursive deletion in multi.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
ZooKeeper-trunk-solaris - Build # 846 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/846/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 220958 lines...] [junit] 2014-03-12 09:06:32,950 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2014-03-12 09:06:32,950 [myid:] - INFO [main:FinalRequestProcessor@454] - shutdown of request processor complete [junit] 2014-03-12 09:06:32,950 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 09:06:32,951 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2014-03-12 09:06:32,952 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2014-03-12 09:06:32,952 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-03-12 09:06:32,953 [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-03-12 09:06:32,953 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-12 09:06:32,953 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-03-12 09:06:32,954 [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/test3340662322101548864.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test3340662322101548864.junit.dir/version-2 [junit] 2014-03-12 09:06:32,955 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test3340662322101548864.junit.dir/version-2/snapshot.b [junit] 2014-03-12 09:06:32,957 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test3340662322101548864.junit.dir/version-2/snapshot.b [junit] 2014-03-12 09:06:32,959 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 09:06:32,959 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:40416 [junit] 2014-03-12 09:06:32,960 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:40416 [junit] 2014-03-12 09:06:32,960 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-03-12 09:06:32,961 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:40416 (no session established for client) [junit] 2014-03-12 09:06:32,961 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-03-12 09:06:32,962 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-03-12 09:06:32,962 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-03-12 09:06:32,962 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-03-12 09:06:32,963 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-12 09:06:32,963 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 13366 [junit] 2014-03-12 09:06:32,963 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-03-12 09:06:32,963 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-03-12 09:06:32,963 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-03-12 09:06:33,003 [myid:] - INFO [SessionTracker:SessionTrackerImpl@134] - SessionTrackerImpl exited loop! [junit] 2014-03-12 09:06:33,003 [myid:] - INFO [SessionTracker:SessionTrackerImpl@134] - SessionTrackerImpl exited loop! [junit] 2014-03-12 09:06:33,034 [myid:] - INFO [main:ZooKeeper@954] - Session: 0x144b58b08e0 closed [junit] 2014-03-12 09:06:33,034 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@536] - EventThread shut down [junit] 2014-03-12 09:06:33,034 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-03-12 09:06:33,035 [myid:] - INFO
ZooKeeper-3.4-WinVS2008_java - Build # 459 - Still Failing
See https://builds.apache.org/job/ZooKeeper-3.4-WinVS2008_java/459/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 179053 lines...] [junit] 2014-03-12 09:16:24,855 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@975] - Opening socket connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to authenticate using SASL (unknown error) [junit] 2014-03-12 09:16:25,741 [myid:] - INFO [main:JMXEnv@146] - ensureOnly:[] [junit] 2014-03-12 09:16:25,742 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2014-03-12 09:16:25,743 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-03-12 09:16:25,744 [myid:] - INFO [main:NIOServerCnxnFactory@94] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-12 09:16:25,744 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-03-12 09:16:25,744 [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\test391897355724464.junit.dir\version-2 snapdir f:\hudson\hudson-slave\workspace\ZooKeeper-3.4-WinVS2008_java\branch-3.4\build\test\tmp\test391897355724464.junit.dir\version-2 [junit] 2014-03-12 09:16:25,747 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 09:16:25,748 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:57466 [junit] 2014-03-12 09:16:25,749 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxn@827] - Processing stat command from /127.0.0.1:57466 [junit] 2014-03-12 09:16:25,751 [myid:] - INFO [Thread-4:NIOServerCnxn$StatCommand@663] - Stat command output [junit] 2014-03-12 09:16:25,751 [myid:] - INFO [Thread-4:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:57466 (no session established for client) [junit] 2014-03-12 09:16:25,751 [myid:] - INFO [main:JMXEnv@229] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-03-12 09:16:25,753 [myid:] - INFO [main:JMXEnv@246] - expect:InMemoryDataTree [junit] 2014-03-12 09:16:25,753 [myid:] - INFO [main:JMXEnv@250] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-03-12 09:16:25,754 [myid:] - INFO [main:JMXEnv@246] - expect:StandaloneServer_port [junit] 2014-03-12 09:16:25,754 [myid:] - INFO [main:JMXEnv@250] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-12 09:16:25,754 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 10146 [junit] 2014-03-12 09:16:25,755 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 20 [junit] 2014-03-12 09:16:25,755 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-03-12 09:16:25,755 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-03-12 09:16:25,845 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@852] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2014-03-12 09:16:25,845 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@197] - Accepted socket connection from /127.0.0.1:57457 [junit] 2014-03-12 09:16:25,846 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@861] - Client attempting to renew session 0x144b5940fbd at /127.0.0.1:57457 [junit] 2014-03-12 09:16:25,846 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:ZooKeeperServer@617] - Established session 0x144b5940fbd with negotiated timeout 3 for client /127.0.0.1:57457 [junit] 2014-03-12 09:16:25,847 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1235] - Session establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 0x144b5940fbd, negotiated timeout = 3 [junit] 2014-03-12 09:16:25,847 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@494] - Processed session termination for sessionid: 0x144b5940fbd [junit] 2014-03-12 09:16:25,874 [myid:] - INFO [SyncThread:0:FileTxnLog@199] - Creating new log file: log.c [junit] 2014-03-12 09:16:25,901 [myid:] - INFO [main:ZooKeeper@684] - Session: 0x144b5940fbd closed [junit] 2014-03-12 09:16:25,902 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-03-12 09:16:25,902 [myid:] - INFO [main:NIOServerCnxn@1007] - Closed socket
ZooKeeper-trunk-WinVS2008_java - Build # 705 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/705/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 246340 lines...] [junit] 2014-03-12 09:52:53,599 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-03-12 09:52:53,600 [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-03-12 09:52:53,601 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-12 09:52:53,602 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-03-12 09:52:53,602 [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\test6742098565508420874.junit.dir\version-2 snapdir f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test6742098565508420874.junit.dir\version-2 [junit] 2014-03-12 09:52:53,603 [myid:] - INFO [main:FileSnap@83] - Reading snapshot f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test6742098565508420874.junit.dir\version-2\snapshot.b [junit] 2014-03-12 09:52:53,605 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test6742098565508420874.junit.dir\version-2\snapshot.b [junit] 2014-03-12 09:52:53,611 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 09:52:53,612 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:63918 [junit] 2014-03-12 09:52:53,613 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:63918 [junit] 2014-03-12 09:52:53,613 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-03-12 09:52:53,614 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:63918 (no session established for client) [junit] 2014-03-12 09:52:53,614 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 3853 [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-03-12 09:52:53,615 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-03-12 09:52:53,616 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-03-12 09:52:53,952 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@971] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2014-03-12 09:52:53,952 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:63913 [junit] 2014-03-12 09:52:53,953 [myid:] - INFO [NIOWorkerThread-2:ZooKeeperServer@858] - Client attempting to renew session 0x144b5b5727b at /127.0.0.1:63913 [junit] 2014-03-12 09:52:53,955 [myid:] - INFO [NIOWorkerThread-2:ZooKeeperServer@604] - Established session 0x144b5b5727b with negotiated timeout 3 for client /127.0.0.1:63913 [junit] 2014-03-12 09:52:53,956 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1354] - Session establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 0x144b5b5727b, negotiated timeout = 3 [junit] 2014-03-12 09:52:53,956 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@680] - Processed session termination for sessionid: 0x144b5b5727b [junit] 2014-03-12 09:52:53,957 [myid:] - INFO [SyncThread:0:FileTxnLog@200] - Creating new log file: log.c [junit] 2014-03-12
ZooKeeper-trunk-jdk7 - Build # 811 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk-jdk7/811/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 269270 lines...] [junit] 2014-03-12 11:10:25,318 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2014-03-12 11:10:25,318 [myid:] - INFO [main:FinalRequestProcessor@454] - shutdown of request processor complete [junit] 2014-03-12 11:10:25,319 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 11:10:25,319 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2014-03-12 11:10:25,320 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2014-03-12 11:10:25,320 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-03-12 11:10:25,321 [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-03-12 11:10:25,321 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-12 11:10:25,321 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-03-12 11:10:25,322 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3854423979589256115.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3854423979589256115.junit.dir/version-2 [junit] 2014-03-12 11:10:25,322 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3854423979589256115.junit.dir/version-2/snapshot.b [junit] 2014-03-12 11:10:25,325 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk-jdk7/trunk/build/test/tmp/test3854423979589256115.junit.dir/version-2/snapshot.b [junit] 2014-03-12 11:10:25,326 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-12 11:10:25,327 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:34132 [junit] 2014-03-12 11:10:25,327 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:34132 [junit] 2014-03-12 11:10:25,327 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-03-12 11:10:25,328 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:34132 (no session established for client) [junit] 2014-03-12 11:10:25,328 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-03-12 11:10:25,329 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-03-12 11:10:25,330 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-03-12 11:10:25,330 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-03-12 11:10:25,330 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-12 11:10:25,330 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 14793 [junit] 2014-03-12 11:10:25,330 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-03-12 11:10:25,331 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-03-12 11:10:25,331 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-03-12 11:10:25,401 [myid:] - INFO [main:ZooKeeper@954] - Session: 0x144b5fc74b6 closed [junit] 2014-03-12 11:10:25,401 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@536] - EventThread shut down [junit] 2014-03-12 11:10:25,401 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-03-12 11:10:25,402 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2014-03-12 11:10:25,402 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-03-12 11:10:25,402 [myid:] - INFO
[jira] [Commented] (ZOOKEEPER-1665) Support recursive deletion in multi
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931718#comment-13931718
]
Ted Yu commented on ZOOKEEPER-1665:
---
The snippet looks good.
Patch is welcome.
Thanks
Support recursive deletion in multi
---
Key: ZOOKEEPER-1665
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1665
Project: ZooKeeper
Issue Type: New Feature
Reporter: Ted Yu
Use case in HBase is that we need to recursively delete multiple subtrees:
{code}
ZKUtil.deleteChildrenRecursively(watcher, acquiredZnode);
ZKUtil.deleteChildrenRecursively(watcher, reachedZnode);
ZKUtil.deleteChildrenRecursively(watcher, abortZnode);
{code}
To achieve high consistency, it is desirable to use multi for the above
operations.
This JIRA adds support for recursive deletion in multi.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1422) Support _HOST substitution in JAAS configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931873#comment-13931873 ] Steven Willis commented on ZOOKEEPER-1422: -- [~phunt], I believe the functionality in HADOOP-8381 was what [~thw] was referencing. However, last time I checked, (which was a while ago) this functionality was not available in the zookeeper jaas configuration, only in the hadoop '*-site.xml' configuration files. Did the change introduced in HADOOP-8381 make the _HOST substitution more widely available? Support _HOST substitution in JAAS configuration - Key: ZOOKEEPER-1422 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1422 Project: ZooKeeper Issue Type: Improvement Affects Versions: 3.4.0 Reporter: Thomas Weise At the moment a JAAS configuration file needs to be created with the Kerberos principal specified as user/host. It would be much easier for deployment automation if the host portion could be resolved at startup time, as supported in Hadoop (something like user/_HOST instead of user/hostname). A configuration alternative to global JAAS conf would be even better (via direct properties in zoo.cfg?). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (BOOKKEEPER-716) padding writes for bookie journal
[
https://issues.apache.org/jira/browse/BOOKKEEPER-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932063#comment-13932063
]
Sijie Guo commented on BOOKKEEPER-716:
--
{quote}
That said, I think this change can be made without breaking BC. Instead of
having a [mask][len][bytes...] which is 8bytes min, you could have
[len][ledgerid][entryid] where ledgerid = -1, which is 20bytes min, but which
will be simply discarded when the scanner gets it on recovery, because the
ledger doesn't exist anymore. This would be backwards compat.
{quote}
your solution would introduce a bit problematic, if the ledger id generator
generates a ledger id with -1. and if you read the patch, this change also
extends the journal head size to align with sector size. that's the reason why
bumping the version.
and for the option, I don't mind adding the option if you feel strong on it.
but I still don't understand how could an option help. if there is problem on
this change, you might still hit it when you enable the option and you couldn't
get back, no? I am kind of thinking the right thing is to do bucket testing:
upgrade a few nodes, stabilize it. if anything bad happened, take those few
nodes out and run bookie recover and rollback to 4.2.0.
padding writes for bookie journal
-
Key: BOOKKEEPER-716
URL: https://issues.apache.org/jira/browse/BOOKKEEPER-716
Project: Bookkeeper
Issue Type: Sub-task
Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Sijie Guo
Fix For: 4.3.0
Attachments: BOOKKEEPER-716.diff, BOOKKEEPER-716_715.diff
it would be better to pad journal writes to align sector size, which to avoid
second syncing corrupt an already synced sector/page.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
Re: Review Request 19089: Inconsistent behavior in autocreation of dataDir and dataLogDir
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/#review36945 --- ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java https://reviews.apache.org/r/19089/#comment68132 Can we remove this block? Doesn't the server create the data directory anyways? - michim On March 12, 2014, 4:17 a.m., Rakesh R wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/ --- (Updated March 12, 2014, 4:17 a.m.) Review request for zookeeper, fpj, michim, and Raul Gutierrez Segales. Bugs: ZOOKEEPER-1878 https://issues.apache.org/jira/browse/ZOOKEEPER-1878 Repository: zookeeper Description --- See ZOOKEEPER-1878 Diffs - ./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java 1566210 ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java 1566210 Diff: https://reviews.apache.org/r/19089/diff/ Testing --- Test included Thanks, Rakesh R
Re: Review Request 19089: Inconsistent behavior in autocreation of dataDir and dataLogDir
On March 12, 2014, 5:43 p.m., Raul Gutierrez Segales wrote:
./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java,
line 274
https://reviews.apache.org/r/19089/diff/1/?file=517045#file517045line274
hmm, so at what point do we check if this dir exists then?
There is a check already present inside the constructor of FileTxnSnapLog.
FileTxnSnapLog(File dataDir, File snapDir){
//
if (!this.snapDir.exists()) {
}
Will this be OK?
On March 12, 2014, 5:43 p.m., Raul Gutierrez Segales wrote:
./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java,
line 73
https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line73
no need to create this dir?
I'll rename the 'autocreate' flag to 'preCreateDirs', so I hope it will avoid
confusions. Here the test expectation is, it sets
zookeeper.datadir.autocreate to true and won't precreate the dataDir
dataLogDir, then zk server should create it and shouldn't throw exception.
- Rakesh
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19089/#review36935
---
On March 12, 2014, 4:17 a.m., Rakesh R wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19089/
---
(Updated March 12, 2014, 4:17 a.m.)
Review request for zookeeper, fpj, michim, and Raul Gutierrez Segales.
Bugs: ZOOKEEPER-1878
https://issues.apache.org/jira/browse/ZOOKEEPER-1878
Repository: zookeeper
Description
---
See ZOOKEEPER-1878
Diffs
-
./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java
1566210
./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java
1566210
Diff: https://reviews.apache.org/r/19089/diff/
Testing
---
Test included
Thanks,
Rakesh R
Re: Review Request 19089: Inconsistent behavior in autocreation of dataDir and dataLogDir
On March 12, 2014, 6:13 p.m., michim wrote: ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java, line 68 https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line68 Can we remove this block? Doesn't the server create the data directory anyways? I'll rename the 'autocreate' flag to 'preCreateDirs', so I hope it will avoid confusions. So we can verify tests with both the conditions with false/true. Is that meaningful? - Rakesh --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/#review36945 --- On March 12, 2014, 4:17 a.m., Rakesh R wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/ --- (Updated March 12, 2014, 4:17 a.m.) Review request for zookeeper, fpj, michim, and Raul Gutierrez Segales. Bugs: ZOOKEEPER-1878 https://issues.apache.org/jira/browse/ZOOKEEPER-1878 Repository: zookeeper Description --- See ZOOKEEPER-1878 Diffs - ./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java 1566210 ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java 1566210 Diff: https://reviews.apache.org/r/19089/diff/ Testing --- Test included Thanks, Rakesh R
[jira] [Updated] (ZOOKEEPER-1054) Drop connections from servers not in the cluster configuration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michi Mutsuzaki updated ZOOKEEPER-1054:
---
Summary: Drop connections from servers not in the cluster configuration
(was: Zookeeper logs are filled with INFO messages )
Drop connections from servers not in the cluster configuration
--
Key: ZOOKEEPER-1054
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1054
Project: ZooKeeper
Issue Type: Improvement
Components: leaderElection
Reporter: Bhallamudi Venkata Siva Kamesh
Assignee: Bhallamudi Venkata Siva Kamesh
Priority: Minor
Labels: security
Fix For: 3.5.0
Attachments: ZOOKEEPER-1054-1.patch, ZOOKEEPER-1054-2.patch,
ZOOKEEPER-1054.patch, zookeeper-1054-3.patch, zookeeper-1054-4.patch
Let us suppose zookeeper cluster is running in the following machines
{noformat}
server.1=10.18.52.133:2999:3999
server.2=10.18.52.253:2999:3999
server.3=10.18.52.96:2999:3999
{noformat}
Let us take another zookeeper(10.18.52.109),which is not part of the cluster
configuration, tries to participate in the leader election,then one of the
zookeeper server's log is filled with following INFO messages
{noformat}
2011-04-19 17:42:42,457 - INFO
[/10.18.52.133:3999:QuorumCnxManager$Listener@486] - Received connection
request /10.18.52.109:18324
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (ZOOKEEPER-1167) C api lacks synchronous version of sync() call.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki resolved ZOOKEEPER-1167. Resolution: Not A Problem Sorry for jumping in this late, but this API seems unnecessary based on Ben's comment. I'm closing this. Please reopen it if there is a good use case for this, and then we should add it to both java and c clients. C api lacks synchronous version of sync() call. --- Key: ZOOKEEPER-1167 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1167 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.3.3, 3.4.3, 3.5.0 Reporter: Nicholas Harteau Assignee: Marshall McMullen Fix For: 3.5.0 Attachments: ZOOKEEPER-1167.patch Reading through the source, the C API implements zoo_async() which is the zookeeper sync() method implemented in the multithreaded/asynchronous C API. It doesn't implement anything equivalent in the non-multithreaded API. I'm not sure if this was oversight or intentional, but it means that the non-multithreaded API can't guarantee consistent client views on critical reads. The zkperl bindings depend on the synchronous, non-multithreaded API so also can't call sync() currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
Failed: ZOOKEEPER-1440 PreCommit Build #1952
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1440 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 276411 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12527472/patch.txt [exec] against trunk revision 1576174. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952//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] ac91aca8d2eb78ecb5b6122bee1d62125a5d3003 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: 2 Total time: 32 minutes 32 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1440 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. FAILED: org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest Error Message: client could not connect to reestablished quorum: giving up after 30+ seconds. Stack Trace: junit.framework.AssertionFailedError: client could not connect to reestablished quorum: giving up after 30+ seconds. at org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:153) at org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest(StandaloneDisabledTest.java:75) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Commented] (ZOOKEEPER-1440) Spurious log error messages when QuorumCnxManager is shutting down
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932427#comment-13932427 ] Hadoop QA commented on ZOOKEEPER-1440: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12527472/patch.txt against trunk revision 1576174. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1952//console This message is automatically generated. Spurious log error messages when QuorumCnxManager is shutting down -- Key: ZOOKEEPER-1440 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1440 Project: ZooKeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.4.3 Reporter: Jordan Zimmerman Assignee: Jordan Zimmerman Priority: Minor Fix For: 3.5.0 Attachments: patch.txt, patch.txt When shutting down the QuroumPeer, ZK server logs unnecessary errors. See QuorumCnxManager.Listener.run() - ss.accept() will throw an exception when it is closed. The catch (IOException e) will log errors. It should first check the shutdown field to see if the Listener is being shutdown. If it is, the exception is correct and no errors should be logged. -- This message was sent by Atlassian JIRA (v6.2#6252)
Failed: ZOOKEEPER-1054 PreCommit Build #1953
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1054 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1953/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 467 lines...] [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12507797/zookeeper-1054-4.patch [exec] against trunk revision 1576936. [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 patch appears to cause tar ant target to fail. [exec] [exec] -1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1953//testReport/ [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1953//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] 69d14cb7505102d919da1a763e6667e03e3e48b2 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: 3 Total time: 1 minute 15 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1054 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1054) Drop connections from servers not in the cluster configuration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932434#comment-13932434
]
Hadoop QA commented on ZOOKEEPER-1054:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507797/zookeeper-1054-4.patch
against trunk revision 1576936.
+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 patch appears to cause tar ant target to fail.
-1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1953//testReport/
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1953//console
This message is automatically generated.
Drop connections from servers not in the cluster configuration
--
Key: ZOOKEEPER-1054
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1054
Project: ZooKeeper
Issue Type: Improvement
Components: leaderElection
Reporter: Bhallamudi Venkata Siva Kamesh
Assignee: Bhallamudi Venkata Siva Kamesh
Priority: Minor
Labels: security
Fix For: 3.5.0
Attachments: ZOOKEEPER-1054-1.patch, ZOOKEEPER-1054-2.patch,
ZOOKEEPER-1054.patch, zookeeper-1054-3.patch, zookeeper-1054-4.patch
Let us suppose zookeeper cluster is running in the following machines
{noformat}
server.1=10.18.52.133:2999:3999
server.2=10.18.52.253:2999:3999
server.3=10.18.52.96:2999:3999
{noformat}
Let us take another zookeeper(10.18.52.109),which is not part of the cluster
configuration, tries to participate in the leader election,then one of the
zookeeper server's log is filled with following INFO messages
{noformat}
2011-04-19 17:42:42,457 - INFO
[/10.18.52.133:3999:QuorumCnxManager$Listener@486] - Received connection
request /10.18.52.109:18324
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1883) C client unit test failures
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932450#comment-13932450 ] Michi Mutsuzaki commented on ZOOKEEPER-1883: +1 Thank you for the patch Raul. I'll check this in, but I'd like to keep the zookeeper_close calls. I agree most test cases don't do cleanups, but they really should :) C client unit test failures --- Key: ZOOKEEPER-1883 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1883 Project: ZooKeeper Issue Type: Bug Components: c client, tests Reporter: Abhiraj Butala Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.5.0 Attachments: ZOOKEEPER-1883.patch I am seeing unit test failure for c client after I do 'make check' as shown below. The failure is pretty consistent, but does not happen always. This is on latest check-out of zookeeper trunk. -- Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : elapsed 9640 : OK Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK Zookeeper_simpleSystem::testFirstServerDown : elapsed 1007 : OK Zookeeper_simpleSystem::testNullData : elapsed 1028 : OK Zookeeper_simpleSystem::testIPV6 : elapsed 1008 : OK Zookeeper_simpleSystem::testCreate : elapsed 1016 : OK Zookeeper_simpleSystem::testPath : elapsed 1083 : OK Zookeeper_simpleSystem::testPathValidation : elapsed 1046 : OK Zookeeper_simpleSystem::testPing : elapsed 17301 : OK Zookeeper_simpleSystem::testAcl : elapsed 1018 : OK Zookeeper_simpleSystem::testChroot : elapsed 3057 : OK Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper server started : elapsed 29357 : OK Zookeeper_simpleSystem::testHangingClient : elapsed 1037 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 12983 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 13028 : OK Zookeeper_simpleSystem::testGetChildren2 : elapsed 1031 : OK Zookeeper_simpleSystem::testLastZxid : assertion : elapsed 2514 Zookeeper_watchers::testDefaultSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testDefaultSessionWatcher2 : elapsed 3 : OK Zookeeper_watchers::testObjectSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testObjectSessionWatcher2 : elapsed 54 : OK Zookeeper_watchers::testNodeWatcher1 : elapsed 55 : OK Zookeeper_watchers::testChildWatcher1 : elapsed 3 : OK Zookeeper_watchers::testChildWatcher2 : elapsed 3 : OK tests/TestClient.cc:1281: Assertion: equality assertion failed [Expected: 1239, Actual : 1238] Failures !!! Run: 70 Failure total: 1 Failures: 1 Errors: 0 FAIL: zktest-mt == 1 of 2 tests failed Please report to u...@zookeeper.apache.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/abutala/work/zk/zookeeper-trunk/src/c' make: *** [check-am] Error 2 -- $ uname -a Linux abutala-vBox 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1167) C api lacks synchronous version of sync() call.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932459#comment-13932459 ] Marshall McMullen commented on ZOOKEEPER-1167: -- [~michim] - I'm not sure I agree. Ben's comments specifically state that this is not strictly required for the consistency protocol ZK provides. But if you are communicating through some other mechanism and you want to guarantee those two clients are synchronized, then this would be useful. Granted the application layer can provide it's own wrapper around zoo_async to provide this functionality. So I think the use case is for easier integration into higher level clients. That and consistency since this is the only non-sync API in the C bindings. I'm still happy to add tests around this and also add a java implementation I just lost sight of this case. C api lacks synchronous version of sync() call. --- Key: ZOOKEEPER-1167 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1167 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.3.3, 3.4.3, 3.5.0 Reporter: Nicholas Harteau Assignee: Marshall McMullen Fix For: 3.5.0 Attachments: ZOOKEEPER-1167.patch Reading through the source, the C API implements zoo_async() which is the zookeeper sync() method implemented in the multithreaded/asynchronous C API. It doesn't implement anything equivalent in the non-multithreaded API. I'm not sure if this was oversight or intentional, but it means that the non-multithreaded API can't guarantee consistent client views on critical reads. The zkperl bindings depend on the synchronous, non-multithreaded API so also can't call sync() currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (ZOOKEEPER-1167) C api lacks synchronous version of sync() call.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki reopened ZOOKEEPER-1167: Ok that sounds reasonable. C api lacks synchronous version of sync() call. --- Key: ZOOKEEPER-1167 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1167 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.3.3, 3.4.3, 3.5.0 Reporter: Nicholas Harteau Assignee: Marshall McMullen Fix For: 3.5.0 Attachments: ZOOKEEPER-1167.patch Reading through the source, the C API implements zoo_async() which is the zookeeper sync() method implemented in the multithreaded/asynchronous C API. It doesn't implement anything equivalent in the non-multithreaded API. I'm not sure if this was oversight or intentional, but it means that the non-multithreaded API can't guarantee consistent client views on critical reads. The zkperl bindings depend on the synchronous, non-multithreaded API so also can't call sync() currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1167) C api lacks synchronous version of sync() call.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932475#comment-13932475 ] Marshall McMullen commented on ZOOKEEPER-1167: -- [~michim] - thanks. Plus I've already patched our internal version of zookeeper so our application doesn't have to do this and would hate to have to maintain that forever :). I'll get an updated patch together so we can finish this one off. C api lacks synchronous version of sync() call. --- Key: ZOOKEEPER-1167 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1167 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.3.3, 3.4.3, 3.5.0 Reporter: Nicholas Harteau Assignee: Marshall McMullen Fix For: 3.5.0 Attachments: ZOOKEEPER-1167.patch Reading through the source, the C API implements zoo_async() which is the zookeeper sync() method implemented in the multithreaded/asynchronous C API. It doesn't implement anything equivalent in the non-multithreaded API. I'm not sure if this was oversight or intentional, but it means that the non-multithreaded API can't guarantee consistent client views on critical reads. The zkperl bindings depend on the synchronous, non-multithreaded API so also can't call sync() currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1167) C api lacks synchronous version of sync() call.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932481#comment-13932481 ] Michi Mutsuzaki commented on ZOOKEEPER-1167: It would be good to document when one might choose the sync version over the async version. The nuance might not be very obvious. C api lacks synchronous version of sync() call. --- Key: ZOOKEEPER-1167 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1167 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.3.3, 3.4.3, 3.5.0 Reporter: Nicholas Harteau Assignee: Marshall McMullen Fix For: 3.5.0 Attachments: ZOOKEEPER-1167.patch Reading through the source, the C API implements zoo_async() which is the zookeeper sync() method implemented in the multithreaded/asynchronous C API. It doesn't implement anything equivalent in the non-multithreaded API. I'm not sure if this was oversight or intentional, but it means that the non-multithreaded API can't guarantee consistent client views on critical reads. The zkperl bindings depend on the synchronous, non-multithreaded API so also can't call sync() currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
Failed: ZOOKEEPER-1054 PreCommit Build #1954
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1054 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1954/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 466 lines...] [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12507797/zookeeper-1054-4.patch [exec] against trunk revision 1576936. [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 patch appears to cause tar ant target to fail. [exec] [exec] -1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1954//testReport/ [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1954//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] 3f05b38f5ce1878b9f31b88eac48348c258d4c63 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: 3 Total time: 1 minute 13 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1054 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1054) Drop connections from servers not in the cluster configuration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932495#comment-13932495
]
Hadoop QA commented on ZOOKEEPER-1054:
--
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12507797/zookeeper-1054-4.patch
against trunk revision 1576936.
+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 patch appears to cause tar ant target to fail.
-1 findbugs. The patch appears to cause Findbugs (version 1.3.9) to fail.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
-1 core tests. The patch failed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1954//testReport/
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1954//console
This message is automatically generated.
Drop connections from servers not in the cluster configuration
--
Key: ZOOKEEPER-1054
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1054
Project: ZooKeeper
Issue Type: Improvement
Components: leaderElection
Reporter: Bhallamudi Venkata Siva Kamesh
Assignee: Bhallamudi Venkata Siva Kamesh
Priority: Minor
Labels: security
Fix For: 3.5.0
Attachments: ZOOKEEPER-1054-1.patch, ZOOKEEPER-1054-2.patch,
ZOOKEEPER-1054.patch, zookeeper-1054-3.patch, zookeeper-1054-4.patch
Let us suppose zookeeper cluster is running in the following machines
{noformat}
server.1=10.18.52.133:2999:3999
server.2=10.18.52.253:2999:3999
server.3=10.18.52.96:2999:3999
{noformat}
Let us take another zookeeper(10.18.52.109),which is not part of the cluster
configuration, tries to participate in the leader election,then one of the
zookeeper server's log is filled with following INFO messages
{noformat}
2011-04-19 17:42:42,457 - INFO
[/10.18.52.133:3999:QuorumCnxManager$Listener@486] - Received connection
request /10.18.52.109:18324
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1054) Drop connections from servers not in the cluster configuration
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932531#comment-13932531
]
Alexander Shraer commented on ZOOKEEPER-1054:
-
the way reconfig works currently is that the leader first accepts connections
and then we invoke a reconfig
so without looking at the patch, if the leader or others (during fle) reject
new servers then join won't work.
we did discuss in the past adding an ensemble id / db_id to the config, and
check that everywhere, so perhaps that could be an alternative
Drop connections from servers not in the cluster configuration
--
Key: ZOOKEEPER-1054
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1054
Project: ZooKeeper
Issue Type: Improvement
Components: leaderElection
Reporter: Bhallamudi Venkata Siva Kamesh
Assignee: Bhallamudi Venkata Siva Kamesh
Priority: Minor
Labels: security
Fix For: 3.5.0
Attachments: ZOOKEEPER-1054-1.patch, ZOOKEEPER-1054-2.patch,
ZOOKEEPER-1054.patch, zookeeper-1054-3.patch, zookeeper-1054-4.patch
Let us suppose zookeeper cluster is running in the following machines
{noformat}
server.1=10.18.52.133:2999:3999
server.2=10.18.52.253:2999:3999
server.3=10.18.52.96:2999:3999
{noformat}
Let us take another zookeeper(10.18.52.109),which is not part of the cluster
configuration, tries to participate in the leader election,then one of the
zookeeper server's log is filled with following INFO messages
{noformat}
2011-04-19 17:42:42,457 - INFO
[/10.18.52.133:3999:QuorumCnxManager$Listener@486] - Received connection
request /10.18.52.109:18324
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1167) C api lacks synchronous version of sync() call.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932534#comment-13932534 ] Marshall McMullen commented on ZOOKEEPER-1167: -- Agreed. C api lacks synchronous version of sync() call. --- Key: ZOOKEEPER-1167 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1167 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.3.3, 3.4.3, 3.5.0 Reporter: Nicholas Harteau Assignee: Marshall McMullen Fix For: 3.5.0 Attachments: ZOOKEEPER-1167.patch Reading through the source, the C API implements zoo_async() which is the zookeeper sync() method implemented in the multithreaded/asynchronous C API. It doesn't implement anything equivalent in the non-multithreaded API. I'm not sure if this was oversight or intentional, but it means that the non-multithreaded API can't guarantee consistent client views on critical reads. The zkperl bindings depend on the synchronous, non-multithreaded API so also can't call sync() currently. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1725) Zookeeper Dynamic Conf writes out hostnames when IPs are supplied
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932573#comment-13932573 ] Michi Mutsuzaki commented on ZOOKEEPER-1725: +1 I'm rerunning the precommit build. Zookeeper Dynamic Conf writes out hostnames when IPs are supplied - Key: ZOOKEEPER-1725 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1725 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.5.0 Reporter: Justin SB Assignee: Alexander Shraer Priority: Minor Fix For: 3.5.0 Attachments: ZOOKEEPER-1725-ver1.patch, ZOOKEEPER-1725.patch When writing the dynamic configuration out, Zookeeper writes out hostnames, even if an IP address is supplied. These may not correctly round-trip (e.g. 127.0.0.1 might be written as localhost which may then resolve to 127.0.0.1 and another IP address). This isn't actually causing problems for me right now, but seems very likely to cause hard-to-track-down problems in future. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1638) Redundant zk.getZKDatabase().clear();
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932588#comment-13932588 ] Michi Mutsuzaki commented on ZOOKEEPER-1638: I'm checking this in. Redundant zk.getZKDatabase().clear(); - Key: ZOOKEEPER-1638 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1638 Project: ZooKeeper Issue Type: Improvement Reporter: Alexander Shraer Assignee: neil bhakta Priority: Trivial Labels: newbie Fix For: 3.5.0 Attachments: ZOOKEEPER-1638.patch, ZOOKEEPER-1638.patch Learner.syncWithLeader calls zk.getZKDatabase().clear() right before zk.getZKDatabase().deserializeSnapshot(leaderIs); Then the first thing deserializeSnapshot does is another clear(). Suggest to remove the clear() in syncWithLeader. -- This message was sent by Atlassian JIRA (v6.2#6252)
ZooKeeper-trunk - Build # 2246 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk/2246/
###
## LAST 60 LINES OF THE CONSOLE
###
[...truncated 301994 lines...]
[exec] Log Message Received: [2014-03-12
23:06:20,871:5977(0x2b26e203fda0):ZOO_INFO@testLogCallbackInit@978:
testLogCallbackInit #9]
[exec] Log Message Received: [2014-03-12
23:06:20,871:5977(0x2b26e203fda0):ZOO_INFO@zookeeper_close@2935: Closing
zookeeper sessionId=0x144b88b4c6a000d to [127.0.0.1:22181]
[exec] ]
[exec] : elapsed 1000 : OK
[exec] Zookeeper_simpleSystem::testLogCallbackClearLog Message Received:
[2014-03-12 23:06:20,871:5977(0x2b26e203fda0):ZOO_INFO@log_env@909: Client
environment:zookeeper.version=zookeeper C client 3.4.0]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@913: Client
environment:host.name=asf008.sp2.ygridcore.net]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@920: Client
environment:os.name=Linux]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@921: Client
environment:os.arch=2.6.32-33-server]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@922: Client
environment:os.version=#71-Ubuntu SMP Wed Jul 20 17:42:25 UTC 2011]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@930: Client
environment:user.name=(null)]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@938: Client
environment:user.home=/home/jenkins]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@log_env@950: Client
environment:user.dir=/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/test-cppunit]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e203fda0):ZOO_INFO@zookeeper_init_internal@993:
Initiating client connection, host=127.0.0.1:22181 sessionTimeout=1
watcher=0x4422e0 sessionId=0 sessionPasswd=null context=0x7fff70b6b3a0
flags=0]
[exec] Log Message Received: [2014-03-12
23:06:20,872:5977(0x2b26e349f700):ZOO_INFO@check_events@2090: initiated
connection to server [127.0.0.1:22181]]
[exec] Log Message Received: [2014-03-12
23:06:20,880:5977(0x2b26e349f700):ZOO_INFO@check_events@2138: session
establishment complete on server [127.0.0.1:22181],
sessionId=0x144b88b4c6a000e, negotiated timeout=1]
[exec] : elapsed 1000 : OK
[exec] Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server
started : elapsed 9401 : OK
[exec] Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK
[exec] Zookeeper_simpleSystem::testFirstServerDown : elapsed 1000 : OK
[exec] Zookeeper_simpleSystem::testNullData : elapsed 1022 : OK
[exec] Zookeeper_simpleSystem::testIPV6 : elapsed 1010 : OK
[exec] Zookeeper_simpleSystem::testCreate : elapsed 1010 : OK
[exec] Zookeeper_simpleSystem::testPath : elapsed 1014 : OK
[exec] Zookeeper_simpleSystem::testPathValidation : elapsed 1031 : OK
[exec] Zookeeper_simpleSystem::testPing : elapsed 17368 : OK
[exec] Zookeeper_simpleSystem::testAcl : elapsed 1013 : OK
[exec] Zookeeper_simpleSystem::testChroot : elapsed 3033 : OK
[exec] Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper
server started : elapsed 28892 : OK
[exec] Zookeeper_simpleSystem::testHangingClient : elapsed 1030 : OK
[exec] Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper
server started ZooKeeper server started ZooKeeper server started : elapsed
12332 : OK
[exec] Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper
server started ZooKeeper server started ZooKeeper server started : elapsed
12385 : OK
[exec] Zookeeper_simpleSystem::testGetChildren2 : elapsed 1082 : OK
Build timed out (after 60 minutes). Marking the build as failed.
[exec] /bin/bash: line 5: 5977 Terminated
ZKROOT=/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/src/c/../..
CLASSPATH=$CLASSPATH:$CLOVER_HOME/lib/clover.jar ${dir}$tst
[exec] Zookeeper_simpleSystem::testLastZxidFAIL: zktest-mt
[exec] ==
[exec] 1 of 2 tests failed
[exec] Please report to u...@zookeeper.apache.org
[exec] ==
[exec] make[1]: *** [check-TESTS] Error 1
[exec] make[1]: Leaving directory
`/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/test-cppunit'
[exec] make: *** [check-am] Error 2
BUILD FAILED
/home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build.xml:1404: The
following error occurred while executing this line:
[jira] [Commented] (ZOOKEEPER-1440) Spurious log error messages when QuorumCnxManager is shutting down
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932654#comment-13932654 ] Hudson commented on ZOOKEEPER-1440: --- FAILURE: Integrated in ZooKeeper-trunk #2246 (See [https://builds.apache.org/job/ZooKeeper-trunk/2246/]) ZOOKEEPER-1440. Spurious log error messages when QuorumCnxManager is shutting down (Jordan Zimmerman via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1576936) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumCnxManager.java Spurious log error messages when QuorumCnxManager is shutting down -- Key: ZOOKEEPER-1440 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1440 Project: ZooKeeper Issue Type: Bug Components: quorum, server Affects Versions: 3.4.3 Reporter: Jordan Zimmerman Assignee: Jordan Zimmerman Priority: Minor Fix For: 3.5.0 Attachments: patch.txt, patch.txt When shutting down the QuroumPeer, ZK server logs unnecessary errors. See QuorumCnxManager.Listener.run() - ss.accept() will throw an exception when it is closed. The catch (IOException e) will log errors. It should first check the shutdown field to see if the Listener is being shutdown. If it is, the exception is correct and no errors should be logged. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1883) C client unit test failures
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932653#comment-13932653 ] Hudson commented on ZOOKEEPER-1883: --- FAILURE: Integrated in ZooKeeper-trunk #2246 (See [https://builds.apache.org/job/ZooKeeper-trunk/2246/]) ZOOKEEPER-1883. C client unit test failures (Raul Gutierrez Segales via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1576961) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/c/tests/TestClient.cc C client unit test failures --- Key: ZOOKEEPER-1883 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1883 Project: ZooKeeper Issue Type: Bug Components: c client, tests Reporter: Abhiraj Butala Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.5.0 Attachments: ZOOKEEPER-1883.patch I am seeing unit test failure for c client after I do 'make check' as shown below. The failure is pretty consistent, but does not happen always. This is on latest check-out of zookeeper trunk. -- Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : elapsed 9640 : OK Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK Zookeeper_simpleSystem::testFirstServerDown : elapsed 1007 : OK Zookeeper_simpleSystem::testNullData : elapsed 1028 : OK Zookeeper_simpleSystem::testIPV6 : elapsed 1008 : OK Zookeeper_simpleSystem::testCreate : elapsed 1016 : OK Zookeeper_simpleSystem::testPath : elapsed 1083 : OK Zookeeper_simpleSystem::testPathValidation : elapsed 1046 : OK Zookeeper_simpleSystem::testPing : elapsed 17301 : OK Zookeeper_simpleSystem::testAcl : elapsed 1018 : OK Zookeeper_simpleSystem::testChroot : elapsed 3057 : OK Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper server started : elapsed 29357 : OK Zookeeper_simpleSystem::testHangingClient : elapsed 1037 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 12983 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 13028 : OK Zookeeper_simpleSystem::testGetChildren2 : elapsed 1031 : OK Zookeeper_simpleSystem::testLastZxid : assertion : elapsed 2514 Zookeeper_watchers::testDefaultSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testDefaultSessionWatcher2 : elapsed 3 : OK Zookeeper_watchers::testObjectSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testObjectSessionWatcher2 : elapsed 54 : OK Zookeeper_watchers::testNodeWatcher1 : elapsed 55 : OK Zookeeper_watchers::testChildWatcher1 : elapsed 3 : OK Zookeeper_watchers::testChildWatcher2 : elapsed 3 : OK tests/TestClient.cc:1281: Assertion: equality assertion failed [Expected: 1239, Actual : 1238] Failures !!! Run: 70 Failure total: 1 Failures: 1 Errors: 0 FAIL: zktest-mt == 1 of 2 tests failed Please report to u...@zookeeper.apache.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/abutala/work/zk/zookeeper-trunk/src/c' make: *** [check-am] Error 2 -- $ uname -a Linux abutala-vBox 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [jira] [Commented] (ZOOKEEPER-1883) C client unit test failures
I'm looking into the build failure. On Wed, Mar 12, 2014 at 4:33 PM, Hudson (JIRA) j...@apache.org wrote: [ https://issues.apache.org/jira/browse/ZOOKEEPER-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932653#comment-13932653 ] Hudson commented on ZOOKEEPER-1883: --- FAILURE: Integrated in ZooKeeper-trunk #2246 (See [https://builds.apache.org/job/ZooKeeper-trunk/2246/]) ZOOKEEPER-1883. C client unit test failures (Raul Gutierrez Segales via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1576961) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/c/tests/TestClient.cc C client unit test failures --- Key: ZOOKEEPER-1883 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1883 Project: ZooKeeper Issue Type: Bug Components: c client, tests Reporter: Abhiraj Butala Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.5.0 Attachments: ZOOKEEPER-1883.patch I am seeing unit test failure for c client after I do 'make check' as shown below. The failure is pretty consistent, but does not happen always. This is on latest check-out of zookeeper trunk. -- Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : elapsed 9640 : OK Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK Zookeeper_simpleSystem::testFirstServerDown : elapsed 1007 : OK Zookeeper_simpleSystem::testNullData : elapsed 1028 : OK Zookeeper_simpleSystem::testIPV6 : elapsed 1008 : OK Zookeeper_simpleSystem::testCreate : elapsed 1016 : OK Zookeeper_simpleSystem::testPath : elapsed 1083 : OK Zookeeper_simpleSystem::testPathValidation : elapsed 1046 : OK Zookeeper_simpleSystem::testPing : elapsed 17301 : OK Zookeeper_simpleSystem::testAcl : elapsed 1018 : OK Zookeeper_simpleSystem::testChroot : elapsed 3057 : OK Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper server started : elapsed 29357 : OK Zookeeper_simpleSystem::testHangingClient : elapsed 1037 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 12983 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 13028 : OK Zookeeper_simpleSystem::testGetChildren2 : elapsed 1031 : OK Zookeeper_simpleSystem::testLastZxid : assertion : elapsed 2514 Zookeeper_watchers::testDefaultSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testDefaultSessionWatcher2 : elapsed 3 : OK Zookeeper_watchers::testObjectSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testObjectSessionWatcher2 : elapsed 54 : OK Zookeeper_watchers::testNodeWatcher1 : elapsed 55 : OK Zookeeper_watchers::testChildWatcher1 : elapsed 3 : OK Zookeeper_watchers::testChildWatcher2 : elapsed 3 : OK tests/TestClient.cc:1281: Assertion: equality assertion failed [Expected: 1239, Actual : 1238] Failures !!! Run: 70 Failure total: 1 Failures: 1 Errors: 0 FAIL: zktest-mt == 1 of 2 tests failed Please report to u...@zookeeper.apache.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/abutala/work/zk/zookeeper-trunk/src/c' make: *** [check-am] Error 2 -- $ uname -a Linux abutala-vBox 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1870) flakey test in StandaloneDisabledTest.startSingleServerTest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932696#comment-13932696
]
Deepak Jagtap commented on ZOOKEEPER-1870:
--
Hi Michi,
On my setup StandaloneDisabledTest fails even without 1805 patch.
I checkout revision 1574686 and build shows StandaloneDisabledTest consitently
fails.
It also fails with 1805 patch applied.
Thanks Regards,
Deepak
flakey test in StandaloneDisabledTest.startSingleServerTest
---
Key: ZOOKEEPER-1870
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1870
Project: ZooKeeper
Issue Type: Bug
Components: tests
Affects Versions: 3.5.0
Reporter: Patrick Hunt
Assignee: Michi Mutsuzaki
Priority: Critical
I'm seeing lots of the following failure. Seems like a flakey test (passes
every so often).
{noformat}
junit.framework.AssertionFailedError: client could not connect to
reestablished quorum: giving up after 30+ seconds.
at
org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:143)
at
org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest(StandaloneDisabledTest.java:75)
at
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
ZooKeeper-trunk - Build # 2247 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk/2247/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 308166 lines...] [junit] 2014-03-13 00:39:37,621 [myid:] - INFO [main:ClientBase@443] - STARTING server [junit] 2014-03-13 00:39:37,621 [myid:] - INFO [main:ClientBase@364] - CREATING server instance 127.0.0.1:11221 [junit] 2014-03-13 00:39:37,621 [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-03-13 00:39:37,622 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2014-03-13 00:39:37,622 [myid:] - INFO [main:ClientBase@339] - STARTING server instance 127.0.0.1:11221 [junit] 2014-03-13 00:39:37,622 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test7550386579416739193.junit.dir/version-2 snapdir /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test7550386579416739193.junit.dir/version-2 [junit] 2014-03-13 00:39:37,623 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test7550386579416739193.junit.dir/version-2/snapshot.b [junit] 2014-03-13 00:39:37,626 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test7550386579416739193.junit.dir/version-2/snapshot.b [junit] 2014-03-13 00:39:37,628 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2014-03-13 00:39:37,628 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:43927 [junit] 2014-03-13 00:39:37,629 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@835] - Processing stat command from /127.0.0.1:43927 [junit] 2014-03-13 00:39:37,629 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@684] - Stat command output [junit] 2014-03-13 00:39:37,630 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1006] - Closed socket connection for client /127.0.0.1:43927 (no session established for client) [junit] 2014-03-13 00:39:37,630 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2014-03-13 00:39:37,631 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2014-03-13 00:39:37,631 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2014-03-13 00:39:37,632 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2014-03-13 00:39:37,632 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2014-03-13 00:39:37,632 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 14369 [junit] 2014-03-13 00:39:37,632 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2014-03-13 00:39:37,633 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2014-03-13 00:39:37,633 [myid:] - INFO [main:ClientBase@520] - tearDown starting [junit] 2014-03-13 00:39:37,698 [myid:] - INFO [main:ZooKeeper@954] - Session: 0x144b8e14e2c closed [junit] 2014-03-13 00:39:37,698 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@536] - EventThread shut down [junit] 2014-03-13 00:39:37,699 [myid:] - INFO [main:ClientBase@490] - STOPPING server [junit] 2014-03-13 00:39:37,699 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2014-03-13 00:39:37,699 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-03-13 00:39:37,699 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2014-03-13 00:39:37,699 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2014-03-13 00:39:37,700 [myid:] - INFO [main:ZooKeeperServer@428] - shutting down [junit] 2014-03-13 00:39:37,700 [myid:] - INFO [main:SessionTrackerImpl@183] - Shutting down [junit] 2014-03-13 00:39:37,700 [myid:] - INFO
[jira] [Commented] (ZOOKEEPER-1638) Redundant zk.getZKDatabase().clear();
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932701#comment-13932701 ] Hudson commented on ZOOKEEPER-1638: --- FAILURE: Integrated in ZooKeeper-trunk #2247 (See [https://builds.apache.org/job/ZooKeeper-trunk/2247/]) ZOOKEEPER-1638. Redundant zk.getZKDatabase().clear(); (neil bhakta via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1576982) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/Learner.java Redundant zk.getZKDatabase().clear(); - Key: ZOOKEEPER-1638 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1638 Project: ZooKeeper Issue Type: Improvement Reporter: Alexander Shraer Assignee: neil bhakta Priority: Trivial Labels: newbie Fix For: 3.5.0 Attachments: ZOOKEEPER-1638.patch, ZOOKEEPER-1638.patch Learner.syncWithLeader calls zk.getZKDatabase().clear() right before zk.getZKDatabase().deserializeSnapshot(leaderIs); Then the first thing deserializeSnapshot does is another clear(). Suggest to remove the clear() in syncWithLeader. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1870) flakey test in StandaloneDisabledTest.startSingleServerTest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932702#comment-13932702
]
Michi Mutsuzaki commented on ZOOKEEPER-1870:
Ok thank you for the update Deepak. I was hoping ZOOKEEPER-1805 would fix this
issue. I'm assigning this back to Helen.
flakey test in StandaloneDisabledTest.startSingleServerTest
---
Key: ZOOKEEPER-1870
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1870
Project: ZooKeeper
Issue Type: Bug
Components: tests
Affects Versions: 3.5.0
Reporter: Patrick Hunt
Assignee: Michi Mutsuzaki
Priority: Critical
I'm seeing lots of the following failure. Seems like a flakey test (passes
every so often).
{noformat}
junit.framework.AssertionFailedError: client could not connect to
reestablished quorum: giving up after 30+ seconds.
at
org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:143)
at
org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest(StandaloneDisabledTest.java:75)
at
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1870) flakey test in StandaloneDisabledTest.startSingleServerTest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michi Mutsuzaki updated ZOOKEEPER-1870:
---
Assignee: Helen Hastings (was: Michi Mutsuzaki)
flakey test in StandaloneDisabledTest.startSingleServerTest
---
Key: ZOOKEEPER-1870
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1870
Project: ZooKeeper
Issue Type: Bug
Components: tests
Affects Versions: 3.5.0
Reporter: Patrick Hunt
Assignee: Helen Hastings
Priority: Critical
I'm seeing lots of the following failure. Seems like a flakey test (passes
every so often).
{noformat}
junit.framework.AssertionFailedError: client could not connect to
reestablished quorum: giving up after 30+ seconds.
at
org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:143)
at
org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest(StandaloneDisabledTest.java:75)
at
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Reopened] (ZOOKEEPER-1883) C client unit test failures
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki reopened ZOOKEEPER-1883: Ok so zookeeper_close is hanging. I'll revert the commit. C client unit test failures --- Key: ZOOKEEPER-1883 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1883 Project: ZooKeeper Issue Type: Bug Components: c client, tests Reporter: Abhiraj Butala Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.5.0 Attachments: ZOOKEEPER-1883.patch I am seeing unit test failure for c client after I do 'make check' as shown below. The failure is pretty consistent, but does not happen always. This is on latest check-out of zookeeper trunk. -- Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : elapsed 9640 : OK Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK Zookeeper_simpleSystem::testFirstServerDown : elapsed 1007 : OK Zookeeper_simpleSystem::testNullData : elapsed 1028 : OK Zookeeper_simpleSystem::testIPV6 : elapsed 1008 : OK Zookeeper_simpleSystem::testCreate : elapsed 1016 : OK Zookeeper_simpleSystem::testPath : elapsed 1083 : OK Zookeeper_simpleSystem::testPathValidation : elapsed 1046 : OK Zookeeper_simpleSystem::testPing : elapsed 17301 : OK Zookeeper_simpleSystem::testAcl : elapsed 1018 : OK Zookeeper_simpleSystem::testChroot : elapsed 3057 : OK Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper server started : elapsed 29357 : OK Zookeeper_simpleSystem::testHangingClient : elapsed 1037 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 12983 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 13028 : OK Zookeeper_simpleSystem::testGetChildren2 : elapsed 1031 : OK Zookeeper_simpleSystem::testLastZxid : assertion : elapsed 2514 Zookeeper_watchers::testDefaultSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testDefaultSessionWatcher2 : elapsed 3 : OK Zookeeper_watchers::testObjectSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testObjectSessionWatcher2 : elapsed 54 : OK Zookeeper_watchers::testNodeWatcher1 : elapsed 55 : OK Zookeeper_watchers::testChildWatcher1 : elapsed 3 : OK Zookeeper_watchers::testChildWatcher2 : elapsed 3 : OK tests/TestClient.cc:1281: Assertion: equality assertion failed [Expected: 1239, Actual : 1238] Failures !!! Run: 70 Failure total: 1 Failures: 1 Errors: 0 FAIL: zktest-mt == 1 of 2 tests failed Please report to u...@zookeeper.apache.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/abutala/work/zk/zookeeper-trunk/src/c' make: *** [check-am] Error 2 -- $ uname -a Linux abutala-vBox 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (ZOOKEEPER-1892) addrvec_next gets called twice when failing over to the next server
Michi Mutsuzaki created ZOOKEEPER-1892: -- Summary: addrvec_next gets called twice when failing over to the next server Key: ZOOKEEPER-1892 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki zookeeper_interest() already calls zoo_cycle_next_server() when the socket is set to -1, so we shouldn't call addrvec_next in handle_error. This causes the next server to get skipped. Zookeeper_simpleSystem::testFirstServerDown fails unless the client gets connected to the server during the first round because the client keeps skipping the second server after the first round. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1892) addrvec_next gets called twice when failing over to the next server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki updated ZOOKEEPER-1892: --- Fix Version/s: 3.5.0 addrvec_next gets called twice when failing over to the next server --- Key: ZOOKEEPER-1892 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Fix For: 3.5.0 zookeeper_interest() already calls zoo_cycle_next_server() when the socket is set to -1, so we shouldn't call addrvec_next in handle_error. This causes the next server to get skipped. Zookeeper_simpleSystem::testFirstServerDown fails unless the client gets connected to the server during the first round because the client keeps skipping the second server after the first round. -- This message was sent by Atlassian JIRA (v6.2#6252)
Failed: ZOOKEEPER-1892 PreCommit Build #1956
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 301050 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12634331/ZOOKEEPER-1892.patch [exec] against trunk revision 1577019. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956//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] 74dbe7dcea747fcf314809d9d79ed321fec6cacf 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: 2 Total time: 33 minutes 50 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1892 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. REGRESSION: org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest Error Message: client could not connect to reestablished quorum: giving up after 30+ seconds. Stack Trace: junit.framework.AssertionFailedError: client could not connect to reestablished quorum: giving up after 30+ seconds. at org.apache.zookeeper.test.ReconfigTest.testNormalOperation(ReconfigTest.java:153) at org.apache.zookeeper.server.quorum.StandaloneDisabledTest.startSingleServerTest(StandaloneDisabledTest.java:75) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
[jira] [Commented] (ZOOKEEPER-1892) addrvec_next gets called twice when failing over to the next server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932813#comment-13932813 ] Hadoop QA commented on ZOOKEEPER-1892: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12634331/ZOOKEEPER-1892.patch against trunk revision 1577019. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1956//console This message is automatically generated. addrvec_next gets called twice when failing over to the next server --- Key: ZOOKEEPER-1892 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Fix For: 3.5.0 Attachments: ZOOKEEPER-1892.patch zookeeper_interest() already calls zoo_cycle_next_server() when the socket is set to -1, so we shouldn't call addrvec_next in handle_error. This causes the next server to get skipped. Zookeeper_simpleSystem::testFirstServerDown fails unless the client gets connected to the server during the first round because the client keeps skipping the second server after the first round. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1892) addrvec_next gets called twice when failing over to the next server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932824#comment-13932824 ] Dutch T. Meyer commented on ZOOKEEPER-1892: --- I opened what I think is the same issue a while back as ZOOKEEPER-1856 (https://issues.apache.org/jira/browse/ZOOKEEPER-1856.) Since you've got a patch here, we should probably resolve that one as a duplicate. addrvec_next gets called twice when failing over to the next server --- Key: ZOOKEEPER-1892 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Fix For: 3.5.0 Attachments: ZOOKEEPER-1892.patch zookeeper_interest() already calls zoo_cycle_next_server() when the socket is set to -1, so we shouldn't call addrvec_next in handle_error. This causes the next server to get skipped. Zookeeper_simpleSystem::testFirstServerDown fails unless the client gets connected to the server during the first round because the client keeps skipping the second server after the first round. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1883) C client unit test failures
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932823#comment-13932823 ] Hudson commented on ZOOKEEPER-1883: --- SUCCESS: Integrated in ZooKeeper-trunk #2249 (See [https://builds.apache.org/job/ZooKeeper-trunk/2249/]) Revert ZOOKEEPER-1883. C client unit test failures (Raul Gutierrez Segales via michim) (michim: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVNview=revrev=1577019) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/c/tests/TestClient.cc C client unit test failures --- Key: ZOOKEEPER-1883 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1883 Project: ZooKeeper Issue Type: Bug Components: c client, tests Reporter: Abhiraj Butala Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.5.0 Attachments: ZOOKEEPER-1883.patch I am seeing unit test failure for c client after I do 'make check' as shown below. The failure is pretty consistent, but does not happen always. This is on latest check-out of zookeeper trunk. -- Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : elapsed 9640 : OK Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK Zookeeper_simpleSystem::testFirstServerDown : elapsed 1007 : OK Zookeeper_simpleSystem::testNullData : elapsed 1028 : OK Zookeeper_simpleSystem::testIPV6 : elapsed 1008 : OK Zookeeper_simpleSystem::testCreate : elapsed 1016 : OK Zookeeper_simpleSystem::testPath : elapsed 1083 : OK Zookeeper_simpleSystem::testPathValidation : elapsed 1046 : OK Zookeeper_simpleSystem::testPing : elapsed 17301 : OK Zookeeper_simpleSystem::testAcl : elapsed 1018 : OK Zookeeper_simpleSystem::testChroot : elapsed 3057 : OK Zookeeper_simpleSystem::testAuth ZooKeeper server started ZooKeeper server started : elapsed 29357 : OK Zookeeper_simpleSystem::testHangingClient : elapsed 1037 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 12983 : OK Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server started ZooKeeper server started ZooKeeper server started : elapsed 13028 : OK Zookeeper_simpleSystem::testGetChildren2 : elapsed 1031 : OK Zookeeper_simpleSystem::testLastZxid : assertion : elapsed 2514 Zookeeper_watchers::testDefaultSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testDefaultSessionWatcher2 : elapsed 3 : OK Zookeeper_watchers::testObjectSessionWatcher1 : elapsed 52 : OK Zookeeper_watchers::testObjectSessionWatcher2 : elapsed 54 : OK Zookeeper_watchers::testNodeWatcher1 : elapsed 55 : OK Zookeeper_watchers::testChildWatcher1 : elapsed 3 : OK Zookeeper_watchers::testChildWatcher2 : elapsed 3 : OK tests/TestClient.cc:1281: Assertion: equality assertion failed [Expected: 1239, Actual : 1238] Failures !!! Run: 70 Failure total: 1 Failures: 1 Errors: 0 FAIL: zktest-mt == 1 of 2 tests failed Please report to u...@zookeeper.apache.org == make[1]: *** [check-TESTS] Error 1 make[1]: Leaving directory `/home/abutala/work/zk/zookeeper-trunk/src/c' make: *** [check-am] Error 2 -- $ uname -a Linux abutala-vBox 3.8.0-35-generic #50~precise1-Ubuntu SMP Wed Dec 4 17:25:51 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux -- This message was sent by Atlassian JIRA (v6.2#6252)
Failed: ZOOKEEPER-1892 PreCommit Build #1957
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 302990 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12634331/ZOOKEEPER-1892.patch [exec] against trunk revision 1577019. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957//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] 9a8dc38108c548d23ea1c134d3e873bde6e61dcc 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: 37 minutes 18 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1892 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1892) addrvec_next gets called twice when failing over to the next server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932838#comment-13932838 ] Hadoop QA commented on ZOOKEEPER-1892: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12634331/ZOOKEEPER-1892.patch against trunk revision 1577019. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1957//console This message is automatically generated. addrvec_next gets called twice when failing over to the next server --- Key: ZOOKEEPER-1892 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Fix For: 3.5.0 Attachments: ZOOKEEPER-1892.patch zookeeper_interest() already calls zoo_cycle_next_server() when the socket is set to -1, so we shouldn't call addrvec_next in handle_error. This causes the next server to get skipped. Zookeeper_simpleSystem::testFirstServerDown fails unless the client gets connected to the server during the first round because the client keeps skipping the second server after the first round. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (ZOOKEEPER-1856) zookeeper C-client can fail to switch from a dead server in a 3+ server ensemble if the client only has a 2 server list.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki reassigned ZOOKEEPER-1856: -- Assignee: Michi Mutsuzaki zookeeper C-client can fail to switch from a dead server in a 3+ server ensemble if the client only has a 2 server list. Key: ZOOKEEPER-1856 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1856 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Dutch T. Meyer Assignee: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-1856.patch If a client has a 2 server list, and is currently connected to the last server in that list, and that server then goes offline, the addrvec_next() call handle_error() will push the client to the start of the list and terminate the connection. Then, the zoo_cycle_next_server() call in zookeeper_interest will be called in response to the connection failure, and the client will cycle back to the failed server. In this way, a client who has a list of only 2 servers can get stuck on the one failed server. This would only be an issue in an ensemble larger than 2 of course, because failing 1 out of 2 would lead to quorum loss anyway. There are other harmonics possible if every other server in the list is failed, but this is simplest to reproduce in a 3 server ensemble where the client only knows about 2 servers, one of which then fails. There are probably some elegant fixes here, but I think the simplest is to add a flag to track whether a server has been accessed before, and if it hasn't, don't call zoo_cycle_next_server() at the top of the zookeeper_interest() function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1856) zookeeper C-client can fail to switch from a dead server in a 3+ server ensemble if the client only has a 2 server list.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki updated ZOOKEEPER-1856: --- Attachment: ZOOKEEPER-1856.patch zookeeper C-client can fail to switch from a dead server in a 3+ server ensemble if the client only has a 2 server list. Key: ZOOKEEPER-1856 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1856 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Dutch T. Meyer Assignee: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-1856.patch If a client has a 2 server list, and is currently connected to the last server in that list, and that server then goes offline, the addrvec_next() call handle_error() will push the client to the start of the list and terminate the connection. Then, the zoo_cycle_next_server() call in zookeeper_interest will be called in response to the connection failure, and the client will cycle back to the failed server. In this way, a client who has a list of only 2 servers can get stuck on the one failed server. This would only be an issue in an ensemble larger than 2 of course, because failing 1 out of 2 would lead to quorum loss anyway. There are other harmonics possible if every other server in the list is failed, but this is simplest to reproduce in a 3 server ensemble where the client only knows about 2 servers, one of which then fails. There are probably some elegant fixes here, but I think the simplest is to add a flag to track whether a server has been accessed before, and if it hasn't, don't call zoo_cycle_next_server() at the top of the zookeeper_interest() function. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1892) addrvec_next gets called twice when failing over to the next server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932849#comment-13932849 ] Michi Mutsuzaki commented on ZOOKEEPER-1892: Thank you for letting me know Dutch. I didn't realize there was an existing issue. I'll close this as a dup and upload the patch in ZOOKEEPER-1856. addrvec_next gets called twice when failing over to the next server --- Key: ZOOKEEPER-1892 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1892 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Fix For: 3.5.0 Attachments: ZOOKEEPER-1892.patch zookeeper_interest() already calls zoo_cycle_next_server() when the socket is set to -1, so we shouldn't call addrvec_next in handle_error. This causes the next server to get skipped. Zookeeper_simpleSystem::testFirstServerDown fails unless the client gets connected to the server during the first round because the client keeps skipping the second server after the first round. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (ZOOKEEPER-1893) automake: use serial-tests option
Michi Mutsuzaki created ZOOKEEPER-1893: -- Summary: automake: use serial-tests option Key: ZOOKEEPER-1893 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1893 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Priority: Minor automake switched to run tests in parallel by default in 1.13, but zktest-st and zktest-mt can't run in parallel. We can use the serial-tests option to run tests serially but this option was introduced in automake 1.12. I don't know which version of automake buidbot has. I'll upload the patch and see. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (ZOOKEEPER-1893) automake: use serial-tests option
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michi Mutsuzaki updated ZOOKEEPER-1893: --- Attachment: ZOOKEEPER-1893.patch automake: use serial-tests option - Key: ZOOKEEPER-1893 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1893 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-1893.patch automake switched to run tests in parallel by default in 1.13, but zktest-st and zktest-mt can't run in parallel. We can use the serial-tests option to run tests serially but this option was introduced in automake 1.12. I don't know which version of automake buidbot has. I'll upload the patch and see. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (ZOOKEEPER-1856) zookeeper C-client can fail to switch from a dead server in a 3+ server ensemble if the client only has a 2 server list.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932856#comment-13932856 ] Hadoop QA commented on ZOOKEEPER-1856: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12634340/ZOOKEEPER-1856.patch against trunk revision 1577019. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958//console This message is automatically generated. zookeeper C-client can fail to switch from a dead server in a 3+ server ensemble if the client only has a 2 server list. Key: ZOOKEEPER-1856 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1856 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Dutch T. Meyer Assignee: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-1856.patch If a client has a 2 server list, and is currently connected to the last server in that list, and that server then goes offline, the addrvec_next() call handle_error() will push the client to the start of the list and terminate the connection. Then, the zoo_cycle_next_server() call in zookeeper_interest will be called in response to the connection failure, and the client will cycle back to the failed server. In this way, a client who has a list of only 2 servers can get stuck on the one failed server. This would only be an issue in an ensemble larger than 2 of course, because failing 1 out of 2 would lead to quorum loss anyway. There are other harmonics possible if every other server in the list is failed, but this is simplest to reproduce in a 3 server ensemble where the client only knows about 2 servers, one of which then fails. There are probably some elegant fixes here, but I think the simplest is to add a flag to track whether a server has been accessed before, and if it hasn't, don't call zoo_cycle_next_server() at the top of the zookeeper_interest() function. -- This message was sent by Atlassian JIRA (v6.2#6252)
Failed: ZOOKEEPER-1856 PreCommit Build #1958
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1856 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 281305 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12634340/ZOOKEEPER-1856.patch [exec] against trunk revision 1577019. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1958//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] 81371a93fe118bd6e9ec089e9896559fecf3eaf8 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: 36 minutes 17 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1856 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
Failed: ZOOKEEPER-1893 PreCommit Build #1959
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1893 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1959/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 285941 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12634342/ZOOKEEPER-1893.patch [exec] against trunk revision 1577019. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 1 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/1959//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1959//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1959//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] 66697134e58918401782ba1c7275e3447b89dad0 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: 33 minutes 10 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1893 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1893) automake: use serial-tests option
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932860#comment-13932860 ] Hadoop QA commented on ZOOKEEPER-1893: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12634342/ZOOKEEPER-1893.patch against trunk revision 1577019. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 1 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/1959//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1959//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1959//console This message is automatically generated. automake: use serial-tests option - Key: ZOOKEEPER-1893 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1893 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-1893.patch automake switched to run tests in parallel by default in 1.13, but zktest-st and zktest-mt can't run in parallel. We can use the serial-tests option to run tests serially but this option was introduced in automake 1.12. I don't know which version of automake buidbot has. I'll upload the patch and see. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19089: Inconsistent behavior in autocreation of dataDir and dataLogDir
On March 12, 2014, 5:43 p.m., Raul Gutierrez Segales wrote:
./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java,
line 67
https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line67
nit: coding style (if (autocreate) {)
ok, I'll modify this.
On March 12, 2014, 5:43 p.m., Raul Gutierrez Segales wrote:
./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java,
line 72
https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line72
nit: coding style (spaces around else)
ok, I'll modify this.
On March 12, 2014, 5:43 p.m., Raul Gutierrez Segales wrote:
./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java,
line 82
https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line82
we already depend on Apache Commons, so you could use
separatorsToSystem():
http://people.apache.org/~jochen/commons-io/site/apidocs/org/apache/commons/io/FilenameUtils.html#separatorsToSystem%28java.lang.String%29
Hi Raul, Please see Camille's comment.
- Rakesh
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19089/#review36935
---
On March 12, 2014, 4:17 a.m., Rakesh R wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/19089/
---
(Updated March 12, 2014, 4:17 a.m.)
Review request for zookeeper, fpj, michim, and Raul Gutierrez Segales.
Bugs: ZOOKEEPER-1878
https://issues.apache.org/jira/browse/ZOOKEEPER-1878
Repository: zookeeper
Description
---
See ZOOKEEPER-1878
Diffs
-
./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java
1566210
./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java
1566210
Diff: https://reviews.apache.org/r/19089/diff/
Testing
---
Test included
Thanks,
Rakesh R
Failed: ZOOKEEPER-1893 PreCommit Build #1960
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1893 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1960/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 294561 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12634342/ZOOKEEPER-1893.patch [exec] against trunk revision 1577019. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 1 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/1960//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1960//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1960//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] d0d9eac97c11696c78eaf4a87fbc1045616f92b8 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: 31 minutes 56 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1893 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1893) automake: use serial-tests option
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932871#comment-13932871 ] Hadoop QA commented on ZOOKEEPER-1893: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12634342/ZOOKEEPER-1893.patch against trunk revision 1577019. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 1 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/1960//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1960//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1960//console This message is automatically generated. automake: use serial-tests option - Key: ZOOKEEPER-1893 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1893 Project: ZooKeeper Issue Type: Bug Components: c client Reporter: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-1893.patch automake switched to run tests in parallel by default in 1.13, but zktest-st and zktest-mt can't run in parallel. We can use the serial-tests option to run tests serially but this option was introduced in automake 1.12. I don't know which version of automake buidbot has. I'll upload the patch and see. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: Review Request 19089: Inconsistent behavior in autocreation of dataDir and dataLogDir
On March 12, 2014, 7:27 p.m., Camille Fournier wrote: ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java, line 82 https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line82 Looks like the apache commons dep is only for the releaseaudit workflow, not for the project in general what about things like: https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/cli/CliCommand.java i see: ``` import org.apache.commons... ``` there. - Raul --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/#review36966 --- On March 12, 2014, 4:17 a.m., Rakesh R wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/ --- (Updated March 12, 2014, 4:17 a.m.) Review request for zookeeper, fpj, michim, and Raul Gutierrez Segales. Bugs: ZOOKEEPER-1878 https://issues.apache.org/jira/browse/ZOOKEEPER-1878 Repository: zookeeper Description --- See ZOOKEEPER-1878 Diffs - ./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java 1566210 ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java 1566210 Diff: https://reviews.apache.org/r/19089/diff/ Testing --- Test included Thanks, Rakesh R
Re: Review Request 19089: Inconsistent behavior in autocreation of dataDir and dataLogDir
On March 12, 2014, 7:27 p.m., Camille Fournier wrote: ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java, line 82 https://reviews.apache.org/r/19089/diff/1/?file=517046#file517046line82 Looks like the apache commons dep is only for the releaseaudit workflow, not for the project in general Raul Gutierrez Segales wrote: what about things like: https://github.com/apache/zookeeper/blob/trunk/src/java/main/org/apache/zookeeper/cli/CliCommand.java i see: ``` import org.apache.commons... ``` there. just asking to learn what the policy is, i am totally fine with not using it for this simple case (but if we can, sure it makes it nicer). - Raul --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/#review36966 --- On March 12, 2014, 4:17 a.m., Rakesh R wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/19089/ --- (Updated March 12, 2014, 4:17 a.m.) Review request for zookeeper, fpj, michim, and Raul Gutierrez Segales. Bugs: ZOOKEEPER-1878 https://issues.apache.org/jira/browse/ZOOKEEPER-1878 Repository: zookeeper Description --- See ZOOKEEPER-1878 Diffs - ./src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java 1566210 ./src/java/test/org/apache/zookeeper/server/ZooKeeperServerMainTest.java 1566210 Diff: https://reviews.apache.org/r/19089/diff/ Testing --- Test included Thanks, Rakesh R
Project report
I'm sorry about the late notice, but I need to submit the project report today. This is the last report we've sent and I was wondering if we can just update it, since we haven't had significant changes: Bookkeeper is a distributed, reliable, and high performance logging service. The project also includes Hedwig which is a highly scalable Pub/Sub service built on top of ZooKeeper and Bookkeeper with strong durability guarantees. We released Bookkeeper 4.2.2 on the 10th October 2013. This was a bugfix release, but also exposed some new administrative functions for dealing with ledgers. We continue to work towards 4.3.0. The final scope of the release has been decided on. It will include improved bookie on-disk performance, a new statistics collection framework and SSL support, among other things. We hope to release 4.3.0 in Q1 of 2014. Infrastructure issues: No issues. Community: 52 subscribers to bookkeeper-dev 67 subscribers to bookkeeper-user 701 issues opened to date, 29 since Sept 1, 2013 465 issues resolved to date, 36 since Sept 1, 2013 7 reports of Jira issues since Sept 1, 2013 7 patch contributors since Sept 1, 2013
[jira] [Commented] (BOOKKEEPER-716) padding writes for bookie journal
[
https://issues.apache.org/jira/browse/BOOKKEEPER-716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931833#comment-13931833
]
Ivan Kelly commented on BOOKKEEPER-716:
---
{quote}for 1), i don't mind adding the flag. but I am not very sure if we
really need the flag. since in the past release we also bump journal version,
which were also breaking changes as you said. and more concerned that shall we
need to do each time we bump version on either disk format? {quote}
The last change was between the 4.1.0 the 4.2.0 release. The changes in 4.3.0
are riskier and there is a lot more production usage of bookkeeper, so
stability is even more important. I'm not just talking about this change, but
the other changes in the code related to checkpointing etc. I think it would be
best to make this feature (and therefore the incompatibility) optional until
the rest of the code has been proven for a few months.
That said, I think this change can be made without breaking BC. Instead of
having a [mask][len][bytes...] which is 8bytes min, you could have
[len][ledgerid][entryid] where ledgerid = -1, which is 20bytes min, but which
will be simply discarded when the scanner gets it on recovery, because the
ledger doesn't exist anymore. This would be backwards compat.
{quote}
for 2), as the batching logic is in journal side, I would prefer adding the
padding logic in journal side, rather than journalchannel.
for 3), the padding there is just for easy to track if it is a padding or a
normal record. it doesn't affect any correctness or performance issue. you
could still let reads start from 512 boundary.
{quote}
ok.
padding writes for bookie journal
-
Key: BOOKKEEPER-716
URL: https://issues.apache.org/jira/browse/BOOKKEEPER-716
Project: Bookkeeper
Issue Type: Sub-task
Components: bookkeeper-server
Reporter: Sijie Guo
Assignee: Sijie Guo
Fix For: 4.3.0
Attachments: BOOKKEEPER-716.diff, BOOKKEEPER-716_715.diff
it would be better to pad journal writes to align sector size, which to avoid
second syncing corrupt an already synced sector/page.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (BOOKKEEPER-734) Improve the HashedWheelTimer usage in PerChannelBookieClient
[ https://issues.apache.org/jira/browse/BOOKKEEPER-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Kelly updated BOOKKEEPER-734: -- Fix Version/s: (was: 4.2.3) Improve the HashedWheelTimer usage in PerChannelBookieClient Key: BOOKKEEPER-734 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-734 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-server Affects Versions: 4.2.2 Reporter: Rakesh R Assignee: Rakesh R Attachments: 0001-BOOKKEEPER-734_br_4_2.patch Observed two potential cases about the HashedWheelTimer usage: # Unnecessary creation of HashedWheelTimer for each channel connection establishment. Instead of creating for each channel connection, we could create one timer per bookie client and close it during permanent closure. # Handle IllegalStateException of HashedWheelTimer.releaseExternalResources() -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (BOOKKEEPER-735) Merge PerChannelBookieClient goodness from trunk to 4.2 branch
[ https://issues.apache.org/jira/browse/BOOKKEEPER-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Kelly updated BOOKKEEPER-735: -- Fix Version/s: (was: 4.2.3) Merge PerChannelBookieClient goodness from trunk to 4.2 branch -- Key: BOOKKEEPER-735 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-735 Project: Bookkeeper Issue Type: Bug Components: bookkeeper-client Affects Versions: 4.2.2 Reporter: Rakesh R Assignee: Rakesh R Attachments: 0001-BOOKKEEPER-735_br_4_2.patch In trunk we have done good imprv/bug fixes to perChannelBookieClient, I feel its worth to merge the necessary changes into 4.2 branch too. Included the following jira issues: # BOOKKEEPER-688 # BOOKKEEPER-714 # BOOKKEEPER-726 # BOOKKEEPER-602 (from this, merge the logging of timed out entries). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (BOOKKEEPER-710) OpenLedgerNoRecovery should watch ensemble change.
[ https://issues.apache.org/jira/browse/BOOKKEEPER-710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Kelly reopened BOOKKEEPER-710: --- [~hustlmsp] [~rakeshr] Did one of you mark this for 4.2.3? This is a new feature, so it doesn't really fit imo. 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.2#6252)
[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=13932022#comment-13932022 ] Sijie Guo commented on BOOKKEEPER-710: -- [~ikelly] I marked this for 4.2.3 when I created the ticket. this is a bug fix not a new feature. we should get it in 4.2.3. but I have no idea why it is on reopened state. 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.2#6252)
Re: Project report
This is the previous report though. I'm generating the numbers for the new one now. -Ivan On Wed, Mar 12, 2014 at 10:08:42AM -0700, Sijie Guo wrote: lgtm +1 On Wed, Mar 12, 2014 at 4:22 AM, Flavio Junqueira fpjunque...@yahoo.comwrote: I'm sorry about the late notice, but I need to submit the project report today. This is the last report we've sent and I was wondering if we can just update it, since we haven't had significant changes: Bookkeeper is a distributed, reliable, and high performance logging service. The project also includes Hedwig which is a highly scalable Pub/Sub service built on top of ZooKeeper and Bookkeeper with strong durability guarantees. We released Bookkeeper 4.2.2 on the 10th October 2013. This was a bugfix release, but also exposed some new administrative functions for dealing with ledgers. We continue to work towards 4.3.0. The final scope of the release has been decided on. It will include improved bookie on-disk performance, a new statistics collection framework and SSL support, among other things. We hope to release 4.3.0 in Q1 of 2014. Infrastructure issues: No issues. Community: 52 subscribers to bookkeeper-dev 67 subscribers to bookkeeper-user 701 issues opened to date, 29 since Sept 1, 2013 465 issues resolved to date, 36 since Sept 1, 2013 7 reports of Jira issues since Sept 1, 2013 7 patch contributors since Sept 1, 2013
[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=13932045#comment-13932045 ] Ivan Kelly commented on BOOKKEEPER-710: --- I reopened, to mark it as non-resolved for 4.2.3. I think everything else in 4.2.3 has been put in the 4.2 branch 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.2#6252)
[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=13932053#comment-13932053 ] Rakesh R commented on BOOKKEEPER-710: - [~hustlmsp] since its not merged into 4.2.3 branch, so its better to be in open state until we finish the changes and this will remind us. I also feel, it can go into 4.2.3 as well. 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.2#6252)
[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=13932067#comment-13932067 ] Sijie Guo commented on BOOKKEEPER-710: -- [~rakeshr] I know that. I just say I don't who reopen it. 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.2#6252)
RE: Project report
Ok, thanks a lot, Ivan, I'm waiting to send it out. -Flavio -Original Message- From: Ivan Kelly [mailto:iv...@apache.org] Sent: 12 March 2014 17:27 To: bookkeeper-dev@zookeeper.apache.org Subject: Re: Project report This is the previous report though. I'm generating the numbers for the new one now. -Ivan On Wed, Mar 12, 2014 at 10:08:42AM -0700, Sijie Guo wrote: lgtm +1 On Wed, Mar 12, 2014 at 4:22 AM, Flavio Junqueira fpjunque...@yahoo.comwrote: I'm sorry about the late notice, but I need to submit the project report today. This is the last report we've sent and I was wondering if we can just update it, since we haven't had significant changes: Bookkeeper is a distributed, reliable, and high performance logging service. The project also includes Hedwig which is a highly scalable Pub/Sub service built on top of ZooKeeper and Bookkeeper with strong durability guarantees. We released Bookkeeper 4.2.2 on the 10th October 2013. This was a bugfix release, but also exposed some new administrative functions for dealing with ledgers. We continue to work towards 4.3.0. The final scope of the release has been decided on. It will include improved bookie on-disk performance, a new statistics collection framework and SSL support, among other things. We hope to release 4.3.0 in Q1 of 2014. Infrastructure issues: No issues. Community: 52 subscribers to bookkeeper-dev 67 subscribers to bookkeeper-user 701 issues opened to date, 29 since Sept 1, 2013 465 issues resolved to date, 36 since Sept 1, 2013 7 reports of Jira issues since Sept 1, 2013 7 patch contributors since Sept 1, 2013
Re: Project report
Bookkeeper is a distributed, reliable, and high performance logging service. The project also includes Hedwig which is a highly scalable Pub/Sub service built on top of ZooKeeper and Bookkeeper with strong durability guarantees. We are currently working towards the 4.3.0 release, which is in its final phase now. We project that it will be released early in April. This release includes a lot of improvements to the bookie on-disk performance, a new statistics framework, and protobuffer protocol support along with numerous bugfixes. We will also release a bugfix release on the 4.2 branch, 4.2.3, in the next fortnight. Infrastructure issues: No issues. Community: 51 subscribers to bookkeeper-dev 68 subscribers to bookkeeper-user 730 issues opened to date, 27 since 2013-12-12 496 issues resolved to date, 30 since 2013-12-12 44 people have reported issues, 3 since 2013-12-12 18 people have contributed patches, 5 since 2013-12-12 On Wed, Mar 12, 2014 at 06:43:12PM -, FPJ wrote: Ok, thanks a lot, Ivan, I'm waiting to send it out. -Flavio -Original Message- From: Ivan Kelly [mailto:iv...@apache.org] Sent: 12 March 2014 17:27 To: bookkeeper-dev@zookeeper.apache.org Subject: Re: Project report This is the previous report though. I'm generating the numbers for the new one now. -Ivan On Wed, Mar 12, 2014 at 10:08:42AM -0700, Sijie Guo wrote: lgtm +1 On Wed, Mar 12, 2014 at 4:22 AM, Flavio Junqueira fpjunque...@yahoo.comwrote: I'm sorry about the late notice, but I need to submit the project report today. This is the last report we've sent and I was wondering if we can just update it, since we haven't had significant changes: Bookkeeper is a distributed, reliable, and high performance logging service. The project also includes Hedwig which is a highly scalable Pub/Sub service built on top of ZooKeeper and Bookkeeper with strong durability guarantees. We released Bookkeeper 4.2.2 on the 10th October 2013. This was a bugfix release, but also exposed some new administrative functions for dealing with ledgers. We continue to work towards 4.3.0. The final scope of the release has been decided on. It will include improved bookie on-disk performance, a new statistics collection framework and SSL support, among other things. We hope to release 4.3.0 in Q1 of 2014. Infrastructure issues: No issues. Community: 52 subscribers to bookkeeper-dev 67 subscribers to bookkeeper-user 701 issues opened to date, 29 since Sept 1, 2013 465 issues resolved to date, 36 since Sept 1, 2013 7 reports of Jira issues since Sept 1, 2013 7 patch contributors since Sept 1, 2013
[jira] [Commented] (BOOKKEEPER-432) Improve performance of entry log range read per ledger entries
[ https://issues.apache.org/jira/browse/BOOKKEEPER-432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932362#comment-13932362 ] Hudson commented on BOOKKEEPER-432: --- SUCCESS: Integrated in bookkeeper-trunk #582 (See [https://builds.apache.org/job/bookkeeper-trunk/582/]) BOOKKEEPER-432: Improve performance of entry log range read per ledger entries (yixue, sijie via ivank) (ivank: rev 1576883) * /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/CacheCallback.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/EntryKeyValue.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/EntryMemTable.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/SkipListArena.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/SkipListFlusher.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/java/org/apache/bookkeeper/bookie/SortedLedgerStorage.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/proto/BookieServer.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/main/resources/findbugsExclude.xml * /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/EntryLogTest.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/bookie/LedgerCacheTest.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/LedgerDeleteTest.java * /zookeeper/bookkeeper/trunk/bookkeeper-server/src/test/java/org/apache/bookkeeper/test/ReadOnlyBookieTest.java Improve performance of entry log range read per ledger entries --- Key: BOOKKEEPER-432 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-432 Project: Bookkeeper Issue Type: Improvement Components: bookkeeper-server Affects Versions: 4.2.0 Environment: Linux Reporter: Yixue (Andrew) Zhu Assignee: Yixue (Andrew) Zhu Labels: patch Fix For: 4.3.0 Attachments: 0001-BOOKKEEPER-432-First-pass.patch, BOOKKEEPER-432.diff, BookieLedgerStorageProposal.pdf, PortSkipListLedgerStore.patch We observed random I/O reads when some subscribers fall behind (on some topics), as delivery needs to scan the entry logs (thru ledger index), which are interleaved with ledger entries across all ledgers being served. Essentially, the ledger index is a non-clustered index. It is not effective when a large number of ledger entries need to be served, which tend to be scattered around due to interleaving. Some possible improvements: 1. Change the ledger entries buffer to use a SkipList (or other suitable), sorted on (ledger, entry sequence). When the buffer is flushed, the entry log is written out in the already-sorted order. The active ledger index can point to the entries buffer (SkipList), and fixed up with entry-log position once latter is persisted. Or, the ledger index can be just rebuilt on demand. The entry log file tail can have index attached (light-weight b-tree, similar with big-table). We need to track per ledger which log files contribute entries to it, so that in-memory index can be rebuilt from the tails of corresponding log files. 2. Use affinity concept to make ensembles of ledgers (belonging to same topic) as identical as possible. This will help above 1. be more effective. -- This message was sent by Atlassian JIRA (v6.2#6252)
