[jira] Updated: (ZOOKEEPER-373) One thread per bookie
[ https://issues.apache.org/jira/browse/ZOOKEEPER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-373: - Status: Open (was: Patch Available) Canceling patch until we sort out all raised issues. One thread per bookie - Key: ZOOKEEPER-373 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-373 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Affects Versions: 3.1.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-373.patch, ZOOKEEPER-373.patch Currently, if a client is writing to multiple ledgers and these ledgers overlap on some bookie, there will be as many threads for such a bookie as the number of ledgers writing to it. Consequently, if a client writes to many ledgers simultaneously, it may end up with an undesirably large number of threads. I don't have a concrete proposal yet, but I suspect it is as simple as keeping an array of BookieHandle objects, one per bookie, and having each BookieHandle object shared by all ledgers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699580#action_12699580 ] Hadoop QA commented on ZOOKEEPER-374: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12405500/ZOOKEEPER-374.patch against trunk revision 764673. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs 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: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/32/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/32/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/32/console This message is automatically generated. Uninitialized struct variable in C causes warning which is treated as an error -- Key: ZOOKEEPER-374 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.1.1 Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Reporter: Nitay Joffe Assignee: Patrick Hunt Priority: Trivial Fix For: 3.2.0 Attachments: ZOOKEEPER-374.patch nitay-joffes-macbook-pro:c nitay$ pwd /Users/nitay/code/zookeeper/src/c nitay-joffes-macbook-pro:c nitay$ make make all-am /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c' || echo './'`src/zookeeper.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o cc1: warnings being treated as errors src/zookeeper.c: In function 'zoo_add_auth': src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this function src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this function make[1]: *** [zookeeper.lo] Error 1 make: *** [all] Error 2 Need to set auth.buff and auth.len to zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-373) One thread per bookie
[ https://issues.apache.org/jira/browse/ZOOKEEPER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699590#action_12699590 ] Flavio Paiva Junqueira commented on ZOOKEEPER-373: -- the one trick piece is the refCounting. specifically decrementing the counter. in close when you decrement the counter and then do the remove you aren't in a synchronized method, so you have a race condition. That was a great catch. I have initially thought that making the counter volatile was sufficient given the code paths that we have, but I realized after your comment that this is not true, so I have re-structured a bit so that we don't have a race condition. I haven't made BookieHandle::incRefCount and BookieHandle::halt synchronized because they are currently only called from BookKeeper::getBookieHandle and BookKeeper::haltBookieHandles, respectively, and these two last methods are synchronized. To make it safe for future versions of BookKeeper, we could make the two BookieHandle methods synchronized, but if I'm not mistaken, I don't think they have to be in the way I have implemented. It would be great if you could double-check. one other place that could be problematic is the mac object. isn't it possible that two different threads going to two different ledgers use the same mac? This one doesn't seem to be a problem because each mac object is a variable of either BookieHandle (for writes) or BookieClient (for reads), and each of these classes extends Thread. Finally, the methods that use the mac objects are called from the Threads that own them. One thread per bookie - Key: ZOOKEEPER-373 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-373 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Affects Versions: 3.1.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-373.patch, ZOOKEEPER-373.patch, ZOOKEEPER-373.patch Currently, if a client is writing to multiple ledgers and these ledgers overlap on some bookie, there will be as many threads for such a bookie as the number of ledgers writing to it. Consequently, if a client writes to many ledgers simultaneously, it may end up with an undesirably large number of threads. I don't have a concrete proposal yet, but I suspect it is as simple as keeping an array of BookieHandle objects, one per bookie, and having each BookieHandle object shared by all ledgers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-373) One thread per bookie
[ https://issues.apache.org/jira/browse/ZOOKEEPER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-373: - Attachment: ZOOKEEPER-373.patch One thread per bookie - Key: ZOOKEEPER-373 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-373 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Affects Versions: 3.1.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-373.patch, ZOOKEEPER-373.patch, ZOOKEEPER-373.patch Currently, if a client is writing to multiple ledgers and these ledgers overlap on some bookie, there will be as many threads for such a bookie as the number of ledgers writing to it. Consequently, if a client writes to many ledgers simultaneously, it may end up with an undesirably large number of threads. I don't have a concrete proposal yet, but I suspect it is as simple as keeping an array of BookieHandle objects, one per bookie, and having each BookieHandle object shared by all ledgers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-29: Attachment: ZOOKEEPER-29.patch New patch with comments addressed. Flexible quorums Key: ZOOKEEPER-29 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699661#action_12699661 ] Flavio Paiva Junqueira commented on ZOOKEEPER-29: - you build an ackToString String, but don't use it. it's probably a left over debugging. I forgot to add to add the string to the message following it. I have fixed it in the new patch. i'm wondering if it is a good idea to let the QuorumVerifier to be changed while the service is up. perhaps we should throw an exception in that case. If I interpret your comment correctly, you're concerned about calls to QuorumPeer::setQuorumVerifier after initialization. As far as I can tell, we have the same issue with other variables. For example, if we change the quorum port on-the-fly, we might get into trouble. Actually, changing the QuorumVerifier on-the-fly doesn't seem to cause a server to stop operating. The only issue I can see is that a server may have a different notion of quorums, but I think this can happen even if we enforce that we set the QuorumVerifier only during initialization. We guarantee that servers have consistent configuration files, right? If you think this is a general issue with initialization, we should perhaps open a different jira and address this problem there? could you document the configuration of the hierarchical QuorumVerifier? it would also be good to expand the description in the javadoc at the top of QuorumHierarchical? Done. Let me know if you think it is sufficient. Flexible quorums Key: ZOOKEEPER-29 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: ZooKeeper-trunk #282
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/282/changes Changes: [gkesavan] to ignore external reference while doing svn stat -- [...truncated 54012 lines...] [junit] 2009-04-16 13:31:15,917 - INFO [main:finalrequestproces...@268] - shutdown of request processor complete [junit] 2009-04-16 13:31:15,917 - INFO [SyncThread:0:syncrequestproces...@119] - SyncRequestProcessor exited! [junit] 2009-04-16 13:31:15,917 - INFO [ProcessThread:-1:preprequestproces...@111] - PrepRequestProcessor exited loop! [junit] 2009-04-16 13:31:16,017 - INFO [main:clientb...@306] - STARTING server [junit] 2009-04-16 13:31:16,017 - INFO [main:zookeeperser...@160] - Created server [junit] 2009-04-16 13:31:16,018 - INFO [main:files...@71] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test5673569349459041973.junit.dir/version-2/snapshot.0 [junit] 2009-04-16 13:31:16,019 - INFO [main:filetxnsnap...@198] - Snapshotting: 3 [junit] 2009-04-16 13:31:16,021 - INFO [NIOServerCxn.Factory:33221:nioserverc...@635] - Processing stat command from /127.0.0.1:57734 [junit] 2009-04-16 13:31:16,022 - WARN [NIOServerCxn.Factory:33221:nioserverc...@431] - Exception causing close of session 0x0 due to java.io.IOException: Responded to info probe [junit] 2009-04-16 13:31:16,022 - INFO [NIOServerCxn.Factory:33221:nioserverc...@766] - closing session:0x0 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:57734] [junit] 2009-04-16 13:31:18,000 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-04-16 13:31:18,000 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-04-16 13:31:18,012 - INFO [main-SendThread:clientcnxn$sendthr...@800] - Attempting connection to server /127.0.0.1:33221 [junit] 2009-04-16 13:31:18,012 - INFO [main-SendThread:clientcnxn$sendthr...@716] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:57735 remote=/127.0.0.1:33221] [junit] 2009-04-16 13:31:18,012 - INFO [main-SendThread:clientcnxn$sendthr...@868] - Server connection successful [junit] 2009-04-16 13:31:18,013 - INFO [NIOServerCxn.Factory:33221:nioserverc...@517] - Connected to /127.0.0.1:57735 lastZxid 3 [junit] 2009-04-16 13:31:18,014 - INFO [NIOServerCxn.Factory:33221:nioserverc...@895] - Finished init of 0x120af1fc433 valid:true [junit] 2009-04-16 13:31:18,015 - INFO [NIOServerCxn.Factory:33221:nioserverc...@545] - Renewing session 0x120af1fc433 [junit] 2009-04-16 13:31:52,023 - INFO [main:clientb...@300] - STOPPING server [junit] 2009-04-16 13:31:52,023 - INFO [main:nioserverc...@766] - closing session:0x120af1fc433 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:57735] [junit] 2009-04-16 13:31:52,024 - WARN [main-SendThread:clientcnxn$sendthr...@898] - Exception closing session 0x120af1fc433 to sun.nio.ch.selectionkeyi...@778255 [junit] java.io.IOException: Read error rc = -1 java.nio.DirectByteBuffer[pos=0 lim=4 cap=4] [junit] at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:632) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:876) [junit] 2009-04-16 13:31:52,024 - INFO [NIOServerCxn.Factory:33221:nioservercnxn$fact...@177] - NIOServerCnxn factory exited run method [junit] 2009-04-16 13:31:52,024 - INFO [main:finalrequestproces...@268] - shutdown of request processor complete [junit] 2009-04-16 13:31:52,024 - INFO [SyncThread:0:syncrequestproces...@119] - SyncRequestProcessor exited! [junit] 2009-04-16 13:31:52,024 - INFO [ProcessThread:-1:preprequestproces...@111] - PrepRequestProcessor exited loop! [junit] 2009-04-16 13:31:52,124 - INFO [main:clientb...@306] - STARTING server [junit] 2009-04-16 13:31:52,125 - INFO [main:zookeeperser...@160] - Created server [junit] 2009-04-16 13:31:52,126 - INFO [main:files...@71] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test5673569349459041973.junit.dir/version-2/snapshot.3 [junit] 2009-04-16 13:31:52,127 - INFO [main:filetxnsnap...@198] - Snapshotting: 5 [junit] 2009-04-16 13:31:52,129 - INFO [NIOServerCxn.Factory:33221:nioserverc...@635] - Processing stat command from /127.0.0.1:57737 [junit] 2009-04-16 13:31:52,130 - WARN [NIOServerCxn.Factory:33221:nioserverc...@431] - Exception causing close of session 0x0 due to java.io.IOException: Responded to info probe [junit] 2009-04-16 13:31:52,141 - INFO [NIOServerCxn.Factory:33221:nioserverc...@766] - closing session:0x0 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221
[jira] Commented: (ZOOKEEPER-316) configure option --without-cppunit does not work
[ https://issues.apache.org/jira/browse/ZOOKEEPER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699766#action_12699766 ] Chris Darroch commented on ZOOKEEPER-316: - One step forward (not a complete solution) would be to add cppunit.m4 to svn. For example, src/c/m4/cppunit.m4 can then be included when building from scratch with trunk using aclocal -I m4. That gets rid of the undefined macro error for AM_PATH_CPPUNIT if you don't have cppunit installed in a default location. configure option --without-cppunit does not work Key: ZOOKEEPER-316 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-316 Project: Zookeeper Issue Type: Bug Components: c client, tests Affects Versions: 3.1.0 Reporter: Mahadev konar configure option --without-cppunit does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-316) configure option --without-cppunit does not work
[ https://issues.apache.org/jira/browse/ZOOKEEPER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699768#action_12699768 ] Mahadev konar commented on ZOOKEEPER-316: - cppunit is under GNU license so we cannot include the cppunit.m4. I am still finding my way throguh auto tools. Is their some other way we can do it ? configure option --without-cppunit does not work Key: ZOOKEEPER-316 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-316 Project: Zookeeper Issue Type: Bug Components: c client, tests Affects Versions: 3.1.0 Reporter: Mahadev konar configure option --without-cppunit does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-316) configure option --without-cppunit does not work
[ https://issues.apache.org/jira/browse/ZOOKEEPER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Darroch updated ZOOKEEPER-316: Attachment: ZOOKEEPER-316.patch This patch makes sure CPPUNIT_CFLAGS isn't overwritten; if one has cppunit in a non-standard location it's important to have the -I flags passed into the compiler. configure option --without-cppunit does not work Key: ZOOKEEPER-316 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-316 Project: Zookeeper Issue Type: Bug Components: c client, tests Affects Versions: 3.1.0 Reporter: Mahadev konar Attachments: ZOOKEEPER-316.patch configure option --without-cppunit does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-316) configure option --without-cppunit does not work
[ https://issues.apache.org/jira/browse/ZOOKEEPER-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699774#action_12699774 ] Chris Darroch commented on ZOOKEEPER-316: - I don't know about cppunit.m4, but AM_PATH_CPPUNIT isn't available without it -- maybe it's installed by default on some systems, but not any of mine, at least. configure option --without-cppunit does not work Key: ZOOKEEPER-316 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-316 Project: Zookeeper Issue Type: Bug Components: c client, tests Affects Versions: 3.1.0 Reporter: Mahadev konar Attachments: ZOOKEEPER-316.patch configure option --without-cppunit does not work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-373) One thread per bookie
[ https://issues.apache.org/jira/browse/ZOOKEEPER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699778#action_12699778 ] Benjamin Reed commented on ZOOKEEPER-373: - +1 looks good One thread per bookie - Key: ZOOKEEPER-373 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-373 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Affects Versions: 3.1.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-373.patch, ZOOKEEPER-373.patch, ZOOKEEPER-373.patch Currently, if a client is writing to multiple ledgers and these ledgers overlap on some bookie, there will be as many threads for such a bookie as the number of ledgers writing to it. Consequently, if a client writes to many ledgers simultaneously, it may end up with an undesirably large number of threads. I don't have a concrete proposal yet, but I suspect it is as simple as keeping an array of BookieHandle objects, one per bookie, and having each BookieHandle object shared by all ledgers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-29) Flexible quorums
[
https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699796#action_12699796
]
Mahadev konar commented on ZOOKEEPER-29:
sorry to be commenting late on the patch flavio,
- minor nit - there is an unneccesary change in AuthFastLeaderElection.java
- I see changes to FastLeaderElection but no changes in LeaderElection.
Shouldnt both of them change.
- also this breaks backward comtability with servers, should this go into 4.0?
or is 3.2 fine?
- isnt the sid sent only once so why do we have that in a loop -
{code}
break;
case Leader.SID:
bb = ByteBuffer.wrap(qp.getData());
this.sid = bb.getLong();
break;
{code}
do we expect the followers to keep sending the SID?
- I think this code is wrong in Leader.java (line 297 or so)
{code}
HashSetLong followerSet = new HashSetLong();
for(FollowerHandler f : followers)
followerSet.add(f.getSid());
if (self.getQuorumVerifier().containsQuorum(followerSet)) {
//if (followers.size() = self.quorumPeers.size() / 2) {
LOG.warn(Enough followers present. +
Perhaps the init
{code}
The reason being the sid is always get to 0 even if the follower hasnt been
able to be synced with the leader
and sent back the sid -- which is the above case. So mostly the above statement
would never execute since
the sid is only sent after the follower synchronizes the database. Meaning that
your code would not be able
to estimate if you had the right set of followers with the SID. Why isnt the
SID sent as the first packet when
syncing up with the leader as a payload? Why do we need another protocol
change?
- also it would be good to have checking in groups and weights (mostly for
mistakes that people would make). You can see
that it gets really easy to make mistakes with this configuration pattern. We
should have more error checking (like serverid belongs
to some unique group) and also in cases like
{code}
if((serverWeight.size() 0)
(serverGroup.size() 0)
(servers.size() == serverGroup.size())){
{code}
where only one or two of the above statements are true, we should fail saying
that some problem on the config files rather than
resorting to majority config. We can do it in seperate jira.
- sorry for being naive, you mentioned in the comments that This gives us
quorums of size 4, whereas majority quorums would require 5. . What are
the implications of this? Meaning is their anycase where the servers can
diverge on the databases?
Flexible quorums
Key: ZOOKEEPER-29
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29
Project: Zookeeper
Issue Type: New Feature
Components: server
Reporter: Patrick Hunt
Assignee: Flavio Paiva Junqueira
Fix For: 3.2.0
Attachments: ZOOKEEPER-29.patch, ZOOKEEPER-29.patch,
ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch,
ZOOKEEPER-29.patch, ZOOKEEPER-29.patch
Moved from SourceForge to Apache.
http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ZOOKEEPER-29) Flexible quorums
[
https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699796#action_12699796
]
Mahadev konar edited comment on ZOOKEEPER-29 at 4/16/09 11:33 AM:
--
sorry to be commenting late on the patch flavio,
- minor nit - there is an unneccesary change in AuthFastLeaderElection.java
- I see changes to FastLeaderElection but no changes in LeaderElection.
Shouldnt both of them change.
- also this breaks backward comtability with servers, should this go into 4.0?
or is 3.2 fine?
- isnt the sid sent only once so why do we have that in a loop -
{code}
break;
case Leader.SID:
bb = ByteBuffer.wrap(qp.getData());
this.sid = bb.getLong();
break;
{code}
do we expect the followers to keep sending the SID?
- I think this code is wrong in Leader.java (line 297 or so)
{code}
HashSetLong followerSet = new HashSetLong();
for(FollowerHandler f : followers)
followerSet.add(f.getSid());
if (self.getQuorumVerifier().containsQuorum(followerSet)) {
//if (followers.size() = self.quorumPeers.size() / 2) {
LOG.warn(Enough followers present. +
Perhaps the init
{code}
The reason being the sid is always set to 0 even if the follower hasnt been
able to be synced with the leader
and sent back the sid -- which is the above case. So mostly the above statement
would never execute since
the sid is only sent after the follower synchronizes the database. Meaning that
your code would not be able
to estimate if you had the right set of followers with the SID. Why isnt the
SID sent as the first packet when
syncing up with the leader as a payload? Why do we need another protocol
change?
- also it would be good to have checking in groups and weights (mostly for
mistakes that people would make). You can see
that it gets really easy to make mistakes with this configuration pattern. We
should have more error checking (like serverid belongs
to some unique group) and also in cases like
{code}
if((serverWeight.size() 0)
(serverGroup.size() 0)
(servers.size() == serverGroup.size())){
{code}
where only one or two of the above statements are true, we should fail saying
that some problem on the config files rather than
resorting to majority config. We can do it in seperate jira.
- sorry for being naive, you mentioned in the comments that This gives us
quorums of size 4, whereas majority quorums would require 5. . What are
the implications of this? Meaning is their anycase where the servers can
diverge on the databases?
was (Author: mahadev):
sorry to be commenting late on the patch flavio,
- minor nit - there is an unneccesary change in AuthFastLeaderElection.java
- I see changes to FastLeaderElection but no changes in LeaderElection.
Shouldnt both of them change.
- also this breaks backward comtability with servers, should this go into 4.0?
or is 3.2 fine?
- isnt the sid sent only once so why do we have that in a loop -
{code}
break;
case Leader.SID:
bb = ByteBuffer.wrap(qp.getData());
this.sid = bb.getLong();
break;
{code}
do we expect the followers to keep sending the SID?
- I think this code is wrong in Leader.java (line 297 or so)
{code}
HashSetLong followerSet = new HashSetLong();
for(FollowerHandler f : followers)
followerSet.add(f.getSid());
if (self.getQuorumVerifier().containsQuorum(followerSet)) {
//if (followers.size() = self.quorumPeers.size() / 2) {
LOG.warn(Enough followers present. +
Perhaps the init
{code}
The reason being the sid is always get to 0 even if the follower hasnt been
able to be synced with the leader
and sent back the sid -- which is the above case. So mostly the above statement
would never execute since
the sid is only sent after the follower synchronizes the database. Meaning that
your code would not be able
to estimate if you had the right set of followers with the SID. Why isnt the
SID sent as the first packet when
syncing up with the leader as a payload? Why do we need another protocol
change?
- also it would be good to have checking in groups and weights (mostly for
mistakes that people would make). You can see
that it gets really easy to make mistakes with this configuration pattern. We
should have more error checking (like serverid belongs
to some unique group) and also in cases like
{code}
[jira] Commented: (ZOOKEEPER-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699804#action_12699804 ] Mahadev konar commented on ZOOKEEPER-29: also we should have (forrest) documentation for the new configuration style for groups and servers. Flexible quorums Key: ZOOKEEPER-29 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699808#action_12699808 ] Mahadev konar commented on ZOOKEEPER-29: I am +1 on putting in 3.2 since it does not break any compatibility with database and clients (only that 3.1.1 servers cannot run with 3.2 servers) which I think is fine. Flexible quorums Key: ZOOKEEPER-29 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-373) One thread per bookie
[ https://issues.apache.org/jira/browse/ZOOKEEPER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699828#action_12699828 ] Hadoop QA commented on ZOOKEEPER-373: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12405634/ZOOKEEPER-373.patch against trunk revision 764673. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs 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: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/34/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/34/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/34/console This message is automatically generated. One thread per bookie - Key: ZOOKEEPER-373 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-373 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Affects Versions: 3.1.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-373.patch, ZOOKEEPER-373.patch, ZOOKEEPER-373.patch Currently, if a client is writing to multiple ledgers and these ledgers overlap on some bookie, there will be as many threads for such a bookie as the number of ledgers writing to it. Consequently, if a client writes to many ledgers simultaneously, it may end up with an undesirably large number of threads. I don't have a concrete proposal yet, but I suspect it is as simple as keeping an array of BookieHandle objects, one per bookie, and having each BookieHandle object shared by all ledgers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699844#action_12699844 ] Mahadev konar commented on ZOOKEEPER-374: - +1 for the patch.. the test fails on java test case LETest which the patch has ntohing to do with. Uninitialized struct variable in C causes warning which is treated as an error -- Key: ZOOKEEPER-374 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.1.1 Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Reporter: Nitay Joffe Assignee: Patrick Hunt Priority: Trivial Fix For: 3.2.0 Attachments: ZOOKEEPER-374.patch nitay-joffes-macbook-pro:c nitay$ pwd /Users/nitay/code/zookeeper/src/c nitay-joffes-macbook-pro:c nitay$ make make all-am /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c' || echo './'`src/zookeeper.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o cc1: warnings being treated as errors src/zookeeper.c: In function 'zoo_add_auth': src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this function src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this function make[1]: *** [zookeeper.lo] Error 1 make: *** [all] Error 2 Need to set auth.buff and auth.len to zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-374) Uninitialized struct variable in C causes warning which is treated as an error
[ https://issues.apache.org/jira/browse/ZOOKEEPER-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-374: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks pat. Uninitialized struct variable in C causes warning which is treated as an error -- Key: ZOOKEEPER-374 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-374 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.1.1 Environment: i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490) Reporter: Nitay Joffe Assignee: Patrick Hunt Priority: Trivial Fix For: 3.2.0 Attachments: ZOOKEEPER-374.patch nitay-joffes-macbook-pro:c nitay$ pwd /Users/nitay/code/zookeeper/src/c nitay-joffes-macbook-pro:c nitay$ make make all-am /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c -o zookeeper.lo `test -f 'src/zookeeper.c' || echo './'`src/zookeeper.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I./include -I./tests -I./generated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c src/zookeeper.c -fno-common -DPIC -o .libs/zookeeper.o cc1: warnings being treated as errors src/zookeeper.c: In function 'zoo_add_auth': src/zookeeper.c:2378: warning: 'auth.buff' may be used uninitialized in this function src/zookeeper.c:2378: warning: 'auth.len' may be used uninitialized in this function make[1]: *** [zookeeper.lo] Error 1 make: *** [all] Error 2 Need to set auth.buff and auth.len to zero. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
New ZooKeeper wiki page on Troubleshooting
I added a new ZK page detailing how to troubleshoot the operating environment. A FAQ of sorts, it has a number of examples of situations we've seen and how to determine/resolve the issue. We'll expand on the content as new issues are seen. http://wiki.apache.org/hadoop/ZooKeeper/Troubleshooting Patrick
[jira] Commented: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699852#action_12699852 ] Mahadev konar commented on ZOOKEEPER-371: - +1 on the patch . I ll wait for hudson to run through it. to implement jdiff --- Key: ZOOKEEPER-371 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.2.0 Environment: to implement jdiff Reporter: Giridharan Kesavan Assignee: Giridharan Kesavan Fix For: 3.2.0 Attachments: zookeeper-371.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-367) RecoveryTest failure - unreasonable length IOException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-367: --- Status: Open (was: Patch Available) You need try/finally around the operations that might throw exceptions while processing the stream(s). The finally needs to close the stream. This will handle the case where an exception is thrown while processing the stream - otw resources may be leaked. You might want to run with something like Coverity prevent - it's good at flagging this sort of thing. (I realize the old code didn't handle this properly either, but as you're updating the code you should fix it) RecoveryTest failure - unreasonable length IOException Key: ZOOKEEPER-367 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-367 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.0 Environment: ubuntu 8.10 intrpid ibex, jvm 1.6.0_10 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.2.0 Attachments: invalid1.tar.gz, invalidsnap.tar.gz, rec.tar.gz, rep2.tar.gz, TEST-org.apache.zookeeper.test.RecoveryTest.txt, ZOOKEEPER-367.patch, ZOOKEEPER-367.patch during local testing I received the attached recoverytest failure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-346) remove the kill command fro mthe client port.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-346: Attachment: ZOOKEEPER-346.patch just changed the script to gracefully error out in case its not able to find the pid file. other than that +1. ill wait for hudson to run through it. remove the kill command fro mthe client port. - Key: ZOOKEEPER-346 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-346 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0, 3.0.1, 3.1.0 Reporter: Mahadev konar Assignee: Patrick Hunt Fix For: 3.2.0 Attachments: ZOOKEEPER-346.patch, ZOOKEEPER-346.patch we should just remove the kill command from the client port. Its a security risk (though we do not have much security right now) to be able to kill the server from a tcp port without any authentication... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-36) REST access to ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699890#action_12699890 ] Patrick Hunt commented on ZOOKEEPER-36: --- Chris thanks for reviewing this. In particular I think it's important both for users as well as implementors (interop) to have a clear spec. /foo and /foo/ were considered, but imo this is pretty hacky and prone to error (both user and potentially intermediate actors like proxies...) Perhaps my search background showing through - url canonicalization often ignores the trailing slash. /foo and /foo/* were also considered, this is a bit better imo (you might also support things like /foo/*/bar, yikes! :-) ) EOD I think it makes more sense to be explicit. it's not as clean but it allows us to follow the HTTP spec and it's more obvious what's going on when reading the client code that uses the REST service (even if you haven't read the spec view=children is going to be more obvious than trailing/non-trailing slash). REST access to ZooKeeper Key: ZOOKEEPER-36 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-36 Project: Zookeeper Issue Type: New Feature Components: contrib Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.2.0 Attachments: rest_2.tar.gz, SPEC.txt Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1961763group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-337) improve logging in leader election lookForLeader method when address resolution fails
[ https://issues.apache.org/jira/browse/ZOOKEEPER-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-337: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks pat. improve logging in leader election lookForLeader method when address resolution fails - Key: ZOOKEEPER-337 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-337 Project: Zookeeper Issue Type: Improvement Components: quorum Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.2.0 Attachments: ZOOKEEPER-337.patch, ZOOKEEPER-337.patch, ZOOKEEPER-337.patch leader election has the following code: requestPacket.setSocketAddress(server.addr); LOG.info(Server address: + server.addr); this should be switched to have the info log first, set sock addr second. The reason for this is that if the setSocketAddress fails sun is not printing the address used. As a result it's verfy difficult to debug this issue. If we log the server address first, then if the setsockaddr fails we'll see both the address of the server and the exception detail (right now we just see the exception detail which does not include the invlaid address in invalidaddressexception). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-371) to implement jdiff
[ https://issues.apache.org/jira/browse/ZOOKEEPER-371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-371: Status: Patch Available (was: Open) to implement jdiff --- Key: ZOOKEEPER-371 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-371 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.2.0 Environment: to implement jdiff Reporter: Giridharan Kesavan Assignee: Giridharan Kesavan Fix For: 3.2.0 Attachments: zookeeper-371.patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-367) RecoveryTest failure - unreasonable length IOException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-367: Attachment: ZOOKEEPER-367.patch good catch pat... thanks for the review.. here's an updated patch. RecoveryTest failure - unreasonable length IOException Key: ZOOKEEPER-367 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-367 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.0 Environment: ubuntu 8.10 intrpid ibex, jvm 1.6.0_10 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.2.0 Attachments: invalid1.tar.gz, invalidsnap.tar.gz, rec.tar.gz, rep2.tar.gz, TEST-org.apache.zookeeper.test.RecoveryTest.txt, ZOOKEEPER-367.patch, ZOOKEEPER-367.patch, ZOOKEEPER-367.patch during local testing I received the attached recoverytest failure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-367) RecoveryTest failure - unreasonable length IOException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-367: Status: Patch Available (was: Open) RecoveryTest failure - unreasonable length IOException Key: ZOOKEEPER-367 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-367 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.0 Environment: ubuntu 8.10 intrpid ibex, jvm 1.6.0_10 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.2.0 Attachments: invalid1.tar.gz, invalidsnap.tar.gz, rec.tar.gz, rep2.tar.gz, TEST-org.apache.zookeeper.test.RecoveryTest.txt, ZOOKEEPER-367.patch, ZOOKEEPER-367.patch, ZOOKEEPER-367.patch during local testing I received the attached recoverytest failure -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12699951#action_12699951 ] Hadoop QA commented on ZOOKEEPER-29: -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12405640/ZOOKEEPER-29.patch against trunk revision 765797. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 21 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 appears to introduce 3 new Findbugs 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: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/36/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/36/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/36/console This message is automatically generated. Flexible quorums Key: ZOOKEEPER-29 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-29 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.2.0 Attachments: ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch, ZOOKEEPER-29.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1938782group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
