[jira] Commented: (ZOOKEEPER-367) RecoveryTest failure - "unreasonable length" IOException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699523#action_12699523 ] Hadoop QA commented on ZOOKEEPER-367: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12405473/invalidsnap.tar.gz against trunk revision 764673. +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 tests are needed for this patch. -1 patch. The patch command could not apply the patch. Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/31/console This message is automatically generated. > 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] Commented: (ZOOKEEPER-36) REST access to ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699514#action_12699514 ] Chris Darroch commented on ZOOKEEPER-36: I took a quick look at the spec; nice! I like that it follows the spirit of the HTTP spec in the way I envisioned. A couple of minor thoughts: I think it would be nice to avoid POST entirely, if only because POST is so over-used that it no longer has any particular meaning except "send stuff to server". Suppose you used the trailing slash in the URI to distinguish meanings? Having hacked on mod_dir at various points this occurs to me as a possibility. For example: PUT /foo -> zoo_set(/foo) PUT /foo/ -> zoo_create(/foo) The same would work to overload GET: GET /foo -> zoo_get(/foo) GET /foo/ -> zoo_get_children(/foo) I especially like the GET cases because they correspond nicely to how URIs are mapped to files and directories. As for running code, I'm working (slowly) on a mod_zookeeper and you'll be the first to know if I get it to a releasable state. The basic purpose is similar to mod_dbd: provide connections that other modules can use however they choose. > 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=detail&aid=1961763&group_id=209147&atid=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-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:comment-tabpanel&focusedCommentId=12699478#action_12699478
]
Hadoop QA commented on ZOOKEEPER-337:
-
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12405366/ZOOKEEPER-337.patch
against trunk revision 764673.
+1 @author. The patch does not contain any @author tags.
+1 tests included. The patch appears to include 37 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/30/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/30/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/30/console
This message is automatically generated.
> 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-36) REST access to ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-36: -- Attachment: SPEC.txt A spec detailing how to bind http to zk. > 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=detail&aid=1961763&group_id=209147&atid=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-tabpanel&focusedCommentId=12699436#action_12699436 ] Benjamin Reed commented on ZOOKEEPER-29: this looks really good. you build an ackToString String, but don't use it. it's probably a left over debugging. 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. 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? > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-tabpanel&focusedCommentId=12699426#action_12699426 ] Benjamin Reed commented on ZOOKEEPER-373: - looks good. 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. 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? > 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-36) REST access to ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-36?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699419#action_12699419 ] Patrick Hunt commented on ZOOKEEPER-36: --- Thanks for the input Chris. I think I'm going to stick with Java though. ;-) At the same time it would be interesting to have what you've done available in contrib. If you'd be willing to put together a patch for contrib we could include it. What types of use cases does this mod_* address? Any example of use? > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1961763&group_id=209147&atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-376) ant test target re-compiles cppunit code every time
ant test target re-compiles cppunit code every time --- Key: ZOOKEEPER-376 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-376 Project: Zookeeper Issue Type: Bug Components: build, c client Affects Versions: 3.2.0 Reporter: Patrick Hunt Assignee: Giridharan Kesavan Priority: Minor Fix For: 3.2.0 Giri, can you take a look at this: 1) looks like autoreconf is always run, which means that a re-configure/re-make is run each time the tests are run using ant 2) tabs were introduced to the build when cppunit changes were made, please only use spaces (would be great if you could fix this too -- hard to read in my editor) Thanks! -- 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 ] Patrick Hunt updated ZOOKEEPER-346: --- Attachment: ZOOKEEPER-346.patch this patch removes the kill command, updates the docs, and also updates the zkServer.sh script to use pids and unix "kill" cli to manage the process. Note: I removed kill entirely due to it's potential security issues. There was consideration to keep it defaulted to off, but in the end if you have local access to the server there is no reason not to just use command line kill, fuser, JMX, whatever. I also included a small change to the build.xml to allow either the java or cppunit tests to be run individually. > 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 > > > 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] 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 ] Patrick Hunt updated ZOOKEEPER-346: --- Status: Patch Available (was: Open) submitting this patch - there are no tests, code/feature was removed. > 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.1.0, 3.0.1, 3.0.0 >Reporter: Mahadev konar >Assignee: Patrick Hunt > Fix For: 3.2.0 > > Attachments: 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] Assigned: (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 ] Patrick Hunt reassigned ZOOKEEPER-346: -- Assignee: Patrick Hunt > 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 > > > 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-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699407#action_12699407 ] Flavio Paiva Junqueira commented on ZOOKEEPER-29: - Just to motivate a little more this scheme, taking the example above, suppose that each group corresponds to the set of ZooKeeper servers in a colocation. To form a quorum, we just need to get a majority of servers from a majority of groups. This gives us quorums of size 4, whereas majority quorums would require 5. This model is reasonable, though, as it is reasonable to expect that at least a majority of colocations have a majority of servers up and running. This idea actually appeared in the following citation (apologies for the self-reference): http://dslab.epfl.ch/hotdep/2005/papers/junqueira_dependent.pdf Another question that may arise is how leader election changes. With this scheme it only changes minimally. In the current trunk code, we always wait for a majority of votes, and that's because we have majority quorums hardcoded. With this patch, we check if we have a quorum, and a quorum can be a majority, as we have currently, or a different quorum system as the one of the example. > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-361) integrate cppunit testing as part of hudson patch process.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-361?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699381#action_12699381 ] Hudson commented on ZOOKEEPER-361: -- Integrated in ZooKeeper-trunk #281 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/281/]) > integrate cppunit testing as part of hudson patch process. > -- > > Key: ZOOKEEPER-361 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-361 > Project: Zookeeper > Issue Type: New Feature > Components: build >Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.1.1 >Reporter: Mahadev konar >Assignee: Giridharan Kesavan > Fix For: 3.2.0 > > Attachments: zk-361.patch, zookeeper-361.patch > > > we need to test the c tests as part of our hudson patch testing process. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: ZooKeeper-trunk #281
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/281/
[jira] Commented: (ZOOKEEPER-373) One thread per bookie
[ https://issues.apache.org/jira/browse/ZOOKEEPER-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699341#action_12699341 ] Flavio Paiva Junqueira commented on ZOOKEEPER-373: -- With this patch, a BookKeeper client has only one BookieHandle per Bookie. With the current trunk implementation, if a client creates writes to two ledgers simultaneously and they share a bookie, there will be two BookieHandle threads. This is not a problem for applications like the namenode that writes to one ledger at a time, but there might be applications that require clients writing to several ledgers concurrently. More specifically, with this patch, a BookKeeper object keeps a list of BookieHandle objects. When creating a ledger, LedgerHandle checks if there is a BookieHandle object available before instantiating BookieHandle through a call to BookKeeper::getBookieHandle. We then have to make sure that a BookieHandle keeps running as long as there is at least one reference to it. > 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-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699336#action_12699336 ] Flavio Paiva Junqueira commented on ZOOKEEPER-29: - Mahadev, thanks for checking it out. Here are answers to your questions: 1- With this patch, it defaults to majority if there is no declaration of groups and weights. We currently use majority quorums; 2- No, the example is fine. You have a quorum if you have at least two servers from two different groups; 3- I don't see a reason for having groups in a first cut and weights in a second. In fact, one typical way of specifying quorums is to assign weights, so even if a user is not interested in groups, the user can declare one group and assign weights. > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-tabpanel&focusedCommentId=12699308#action_12699308 ] Mahadev konar commented on ZOOKEEPER-373: - flavio, can you comment on the jira, what specific changes you made? > 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-29) Flexible quorums
[ https://issues.apache.org/jira/browse/ZOOKEEPER-29?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699289#action_12699289 ] Mahadev konar commented on ZOOKEEPER-29: also, - why not just have groups and equal weights for first cut? wouldnt that suffice for the scenario of co located zookeeper 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-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: Status: Patch Available (was: Open) > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-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: Status: Open (was: Patch Available) I'd like to replace QuorumValidator with QuorumVerifier. It is just a small modification. > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-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 Uploading a new patch with the name of the interface changed. > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-tabpanel&focusedCommentId=12699288#action_12699288 ] Mahadev konar commented on ZOOKEEPER-29: some questions on the patch - is it backwards compatible in the sense that if I do not specify groups and weights in the config then it will work as it used to? - also in the example that you mentioned above shouldnt the group size be atleast 5 since you have equal weights and 9 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-375) zoo_add_auth only retains most recent auth on re-sync
zoo_add_auth only retains most recent auth on re-sync - Key: ZOOKEEPER-375 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-375 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.1.1, 3.1.0 Reporter: Patrick Hunt Priority: Critical Fix For: 3.2.0 zoo_add_auth doesn't maintain a list of auths - it only stores the most recent auth send to the server. As a result on re-sync to the cluster it will lose (not reregister) any auths prior to the most recent. This code should maintain a list of auths similar to the java code. Be sure to free the memory in close. -- 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 ] Patrick Hunt updated ZOOKEEPER-29: -- Fix Version/s: (was: 3.1.1) 3.2.0 > 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 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1938782&group_id=209147&atid=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-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: - Assignee: Flavio Paiva Junqueira > 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] 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: - Fix Version/s: 3.2.0 Affects Version/s: 3.1.1 Status: Patch Available (was: Open) > 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] 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 Includes a new unit test. > One thread per bookie > - > > Key: ZOOKEEPER-373 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-373 > Project: Zookeeper > Issue Type: Improvement > Components: contrib-bookkeeper >Reporter: Flavio Paiva Junqueira > 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] 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 I have written a unit test and changed the implementation to read the quorum configuration from QuorumPeerConfig as all the other parameters. > 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.1.1 > > Attachments: 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=detail&aid=1938782&group_id=209147&atid=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-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: Fix Version/s: 3.1.1 Status: Patch Available (was: Open) > 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.1.1 > > Attachments: 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=detail&aid=1938782&group_id=209147&atid=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-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-tabpanel&focusedCommentId=12699124#action_12699124 ] Nitay Joffe commented on ZOOKEEPER-374: --- +1. Works for me. > 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.
