[jira] Updated: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-82: -- Status: Open (was: Patch Available) After applying this patch the zkServer.sh (trunk/bin) script fails due to main method being removed from quorum peer. Also the javadoc in QuorumPeer is referencing "main" method which no longer exists - was main removed accidentally? main was also removed from zookeeperserver which is the standalone server. I think we should document the public api methods which were added to zookeeperserver & quorumpeer classes. I like your idea of moving from extending thread to implementing runnable if it can be done with minimal impact on existing (user) code... esp since it means we don't hide the previously checked exceptions as unchecked. Note: I'm not familiar with jmx, Andrew should review the updated patch, might be issues there I'm not aware of, I'll add him to the watch list. > Make the ZooKeeperServer more DI friendly > - > > Key: ZOOKEEPER-82 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Attachments: ZOOKEEPER-82.patch > > > Proposed changes were discussed in [this mailing list > thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL > PROTECTED]: > Basic goals are: > * Decouple the current configuration system from the public API. I > see stuff like ZooKeeperServer being coupled to ServerConfig a bit. > * Allow the use of setter injection in addition to constructor > injection. This is the most important thing needed to let spring more > easily configure the objects. > * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-74) Cleaning/restructuring up Zookeeper server code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616765#action_12616765 ] Patrick Hunt commented on ZOOKEEPER-74: --- We may want to use "violations" which hadoop core uses. Integrates into hudson and supports many more tools than just checkstyle. http://hudson.gotdns.com/wiki/display/HUDSON/Violations http://hudson.zones.apache.org/hudson/view/Hadoop/job/Hadoop-trunk/ we could bootstrap (taking into accnt ben's comment on in flight patches) using the cleanup/format tools in eclipse, I assume there must be a config that gets you close to the sun std. > Cleaning/restructuring up Zookeeper server code > --- > > Key: ZOOKEEPER-74 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-74 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.0.0 > > > I have been thinking this for a while and find that the zookeeper server code > needs some cleaning up. The server code is a little tricky/confusing to read > sometimes gievn that there is no clearity on ownership of objects. I will put > down a proposal for restructuring/cleaning the code up with javadocs so that > the code is easier to understand and develop on. comments on what you find > confusing are welcome on this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Interested in IRC to lube ZK communication?
http://hadoop.apache.org/zookeeper/irc.html Patrick
[jira] Commented: (ZOOKEEPER-74) Cleaning/restructuring up Zookeeper server code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616757#action_12616757 ] Patrick Hunt commented on ZOOKEEPER-74: --- According to the homepage checkstyle already has a "sun coding configuration" config http://checkstyle.sourceforge.net/ > Cleaning/restructuring up Zookeeper server code > --- > > Key: ZOOKEEPER-74 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-74 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.0.0 > > > I have been thinking this for a while and find that the zookeeper server code > needs some cleaning up. The server code is a little tricky/confusing to read > sometimes gievn that there is no clearity on ownership of objects. I will put > down a proposal for restructuring/cleaning the code up with javadocs so that > the code is easier to understand and develop on. comments on what you find > confusing are welcome on this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-74) Cleaning/restructuring up Zookeeper server code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616755#action_12616755 ] Patrick Hunt commented on ZOOKEEPER-74: --- +1 - I always found the field issue james mentioned pretty annoying as well +1 as well for getting "checkstyle" with customized config into the commit process (doc on howtocommit and report on Hudson) as part of this change. If we're serious about coding conventions we should be able to track/enforce it. > Cleaning/restructuring up Zookeeper server code > --- > > Key: ZOOKEEPER-74 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-74 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.0.0 > > > I have been thinking this for a while and find that the zookeeper server code > needs some cleaning up. The server code is a little tricky/confusing to read > sometimes gievn that there is no clearity on ownership of objects. I will put > down a proposal for restructuring/cleaning the code up with javadocs so that > the code is easier to understand and develop on. comments on what you find > confusing are welcome on this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616722#action_12616722 ] Benjamin Reed commented on ZOOKEEPER-78: Can we focus on the issue at hand? This patch is almost done there is no reason for the meta physical discussions or even an external SVN. It's simple enough. The only thing that must be done is to remove the use of the ZooKeeperFacade and use the ZooKeeper object correctly. If you want to discuss why ZooKeeperFacade is a bad idea, lets open an issue to discuss there. I really like the idea of using the Lock interface, but changing aquire to lock() should be good enough. Lets get this thing committed so that we can move on. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan >Assignee: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-74) Cleaning/restructuring up Zookeeper server code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616716#action_12616716 ] Benjamin Reed commented on ZOOKEEPER-74: +1 we should coordinate the creation of this patch there are quite a few patches in flight and we don't want to break them. (BTW I had totally missed this mart of the Sun standards. It's a good idea.) > Cleaning/restructuring up Zookeeper server code > --- > > Key: ZOOKEEPER-74 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-74 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.0.0 > > > I have been thinking this for a while and find that the zookeeper server code > needs some cleaning up. The server code is a little tricky/confusing to read > sometimes gievn that there is no clearity on ownership of objects. I will put > down a proposal for restructuring/cleaning the code up with javadocs so that > the code is easier to understand and develop on. comments on what you find > confusing are welcome on this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-59:
--
Assignee: Mahadev konar (was: Benjamin Reed)
Status: Open (was: Patch Available)
Looks like patch _2 replaces _1? Canceling the patch for now. Please resubmit
after addressing.
See http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute, remember that we
are replacing (re-attaching with the same name) the patch.
> Synchronized block in NIOServerCnxn
> ---
>
> Key: ZOOKEEPER-59
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
> Project: Zookeeper
> Issue Type: Bug
> Components: server
>Reporter: Flavio Paiva Junqueira
>Assignee: Mahadev konar
> Attachments: ZOOKEEPER-59_1.patch, ZOOKEEPER-59_2.patch
>
>
> There are two synchronized blocks locking on different objects, and to me
> they should be guarded by the same object. Here are the parts of the code I'm
> talking about:
> {noformat}
> [EMAIL PROTECTED]
> ...
> synchronized (this) {
> outstandingRequests++;
> // check throttling
> if (zk.getInProcess() > factory.outstandingLimit) {
> disableRecv();
> // following lines should not be needed since we are
> already
> // reading
> // } else {
> // enableRecv();
> }
> }
> {noformat}
> {noformat}
> [EMAIL PROTECTED]
> ...
> synchronized (this.factory) {
> outstandingRequests--;
> // check throttling
> if (zk.getInProcess() < factory.outstandingLimit
> || outstandingRequests < 1) {
> sk.selector().wakeup();
> enableRecv();
> }
> }
> {noformat}
> I think the second one is correct, and the first synchronized block should be
> guarded by "this.factory".
> This could be related to issue ZOOKEEPER-57, but I have no concrete
> indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-84) provide a mechanism to reconnect a ZooKeeper if a client receives a SessionExpiredException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-84: -- Status: Open (was: Patch Available) If I read the comments correctly the attached patch seems to be moot. Also the last comment references a SVN repository, please attach the patch as a "svn diff" and resubmit for review. > provide a mechanism to reconnect a ZooKeeper if a client receives a > SessionExpiredException > --- > > Key: ZOOKEEPER-84 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-84 > Project: Zookeeper > Issue Type: Improvement > Components: java client >Reporter: james strachan >Assignee: james strachan > Attachments: reconnect_patch.patch > > > am about to attach a patch which adds a reconnect() method to easily > re-establish a connection if a session expires - along with a toString() > implementation for easier debugging -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-84) provide a mechanism to reconnect a ZooKeeper if a client receives a SessionExpiredException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-84: - Assignee: james strachan (was: Benjamin Reed) > provide a mechanism to reconnect a ZooKeeper if a client receives a > SessionExpiredException > --- > > Key: ZOOKEEPER-84 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-84 > Project: Zookeeper > Issue Type: Improvement > Components: java client >Reporter: james strachan >Assignee: james strachan > Attachments: reconnect_patch.patch > > > am about to attach a patch which adds a reconnect() method to easily > re-establish a connection if a session expires - along with a toString() > implementation for easier debugging -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-86) intermittent test failure of org.apache.zookeeper.test.AsyncTest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-86: -- Status: Open (was: Patch Available) The exceptions in the log like this: 2008-07-23 17:57:15,449 - WARN [SendThread:[EMAIL PROTECTED] - Closing: java.io.IOException: Read error rc = -1 java.nio.DirectByteBuffer[pos=0 lim=4 cap=4] at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:491) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:712) are the same issue as ZOOKEEPER-63 - the client has asked the server to close the connection but hasn't noted this fact (read returns -1), then when the server closes the client complains. I don't like adding delays since it results in the unit tests taking forever (they already take a lot more time than they should , almost all the time is due to doing sleeps). IMO tests should run very quickly so that we're more likely to run them. ;-) We really need a better way of handling this - see ZOOKEEPER-61 which already captures this issue with excessive/unnecessary sleep. -1 on this patch until the two issues 61/63, are addressed and we can be certain of successful fix It would be great if you could tackle this test "harness" issue. There are at least 3 jira (86/61/63) related to this. Hudson has intermittent failures as well. Feel free to collapse these 3 bugs into 1 jira if it makes sense to have a single patch for all of them. (or "link" them together and submit a patch against one) > intermittent test failure of org.apache.zookeeper.test.AsyncTest > > > Key: ZOOKEEPER-86 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-86 > Project: Zookeeper > Issue Type: Bug > Components: tests > Environment: OS X and linux. It sometimes passes; but mostly seems to > fail on OS X each time >Reporter: james strachan >Assignee: james strachan > Attachments: patch_for_ZOOKEEPER-86.patch, > TEST-org.apache.zookeeper.test.AsyncTest.txt > > > Will attach the test output in an attachment... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-39) Use Watcher objects rather than boolean on read operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kornev updated ZOOKEEPER-39: --- Resolution: Fixed Status: Resolved (was: Patch Available) Patch committed > Use Watcher objects rather than boolean on read operations > -- > > Key: ZOOKEEPER-39 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-39 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Andrew Kornev > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-39.patch, ZOOKEEPER-39_license.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1962501&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] Closed: (ZOOKEEPER-39) Use Watcher objects rather than boolean on read operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kornev closed ZOOKEEPER-39. -- > Use Watcher objects rather than boolean on read operations > -- > > Key: ZOOKEEPER-39 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-39 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Andrew Kornev > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-39.patch, ZOOKEEPER-39_license.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1962501&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-39) Use Watcher objects rather than boolean on read operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616664#action_12616664 ] Andrew Kornev commented on ZOOKEEPER-39: Verified the patch builds and the unit tests run successfully. > Use Watcher objects rather than boolean on read operations > -- > > Key: ZOOKEEPER-39 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-39 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Andrew Kornev > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-39.patch, ZOOKEEPER-39_license.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1962501&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-39) Use Watcher objects rather than boolean on read operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-39: --- Attachment: ZOOKEEPER-39_license.patch here is a patch that adds the license file to the hashtable implementation. +1 for the patch from my side. > Use Watcher objects rather than boolean on read operations > -- > > Key: ZOOKEEPER-39 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-39 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Andrew Kornev > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-39.patch, ZOOKEEPER-39_license.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1962501&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] Assigned: (ZOOKEEPER-82) Make the ZooKeeperServer more DI friendly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-82: - Assignee: Hiram Chirino > Make the ZooKeeperServer more DI friendly > - > > Key: ZOOKEEPER-82 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-82 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Attachments: ZOOKEEPER-82.patch > > > Proposed changes were discussed in [this mailing list > thread|http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL > PROTECTED]: > Basic goals are: > * Decouple the current configuration system from the public API. I > see stuff like ZooKeeperServer being coupled to ServerConfig a bit. > * Allow the use of setter injection in addition to constructor > injection. This is the most important thing needed to let spring more > easily configure the objects. > * Move the main() methods out of the ZooKeeperServer class. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-86) intermittent test failure of org.apache.zookeeper.test.AsyncTest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-86: - Assignee: james strachan > intermittent test failure of org.apache.zookeeper.test.AsyncTest > > > Key: ZOOKEEPER-86 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-86 > Project: Zookeeper > Issue Type: Bug > Components: tests > Environment: OS X and linux. It sometimes passes; but mostly seems to > fail on OS X each time >Reporter: james strachan >Assignee: james strachan > Attachments: patch_for_ZOOKEEPER-86.patch, > TEST-org.apache.zookeeper.test.AsyncTest.txt > > > Will attach the test output in an attachment... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-78: -- Assignee: james strachan Status: Open (was: Patch Available) Per the comments here: https://issues.apache.org/jira/browse/ZOOKEEPER-78?focusedCommentId=12616579#action_12616579 and here: https://issues.apache.org/jira/browse/ZOOKEEPER-78?focusedCommentId=12616624#action_12616624 I'm moving the status from patch available to open. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan >Assignee: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-83: -- Status: Open (was: Patch Available) Removed from patch available status: the changes need to be attached as a patch file. (or patch file + script if things need to be moved around a lot as it seems in this case). > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-83: - Assignee: Hiram Chirino > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino >Assignee: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-88) implement java.util.concurrent.locks.Lock
[ https://issues.apache.org/jira/browse/ZOOKEEPER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-88: -- Status: Open (was: Patch Available) Removing from "patch available" - please attach a "svn diff" patch to this jira. thanks. > implement java.util.concurrent.locks.Lock > - > > Key: ZOOKEEPER-88 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-88 > Project: Zookeeper > Issue Type: Sub-task > Components: java client >Reporter: james strachan >Assignee: james strachan > > we should implement the > [java.util.concurrent.locks.Lock|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html] > to make it easier for folks to reuse the Lock and to help make the API be > more natural to end users -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-88) implement java.util.concurrent.locks.Lock
[ https://issues.apache.org/jira/browse/ZOOKEEPER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-88: - Assignee: james strachan > implement java.util.concurrent.locks.Lock > - > > Key: ZOOKEEPER-88 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-88 > Project: Zookeeper > Issue Type: Sub-task > Components: java client >Reporter: james strachan >Assignee: james strachan > > we should implement the > [java.util.concurrent.locks.Lock|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html] > to make it easier for folks to reuse the Lock and to help make the API be > more natural to end users -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616650#action_12616650 ] Patrick Hunt commented on ZOOKEEPER-78: --- I agree, we do need to do a better job on the reviews. In our defense: :-) 1) we're trying to complete the migration from SF to Apache. good thing is it looks like we're pretty close to the end on that 2) there's a ZooKeeper workshop @yahoo on Monday, just so happens that all commiters are presenters. 3) the continual push to change the build/wiki/patchsubmission/etc... processes are pulling me off things like patch review in order to track down answers (cuz I'm new to Apache as well - thanks Doug/Owen!) > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-63) Race condition in client close() operation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-63: -- Status: Open (was: Patch Available) I agree with your comments, in addition the patch should address: 1) there is still the stated race condition 2) what is causing the underlying hang? this should not be happening and needs to be addressed directly, may even be related to item 1 3) if the timeout is reached a warning should be issued in the log > Race condition in client close() operation > -- > > Key: ZOOKEEPER-63 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63 > Project: Zookeeper > Issue Type: Bug > Components: java client >Reporter: Patrick Hunt >Assignee: james strachan > Attachments: patch_ZOOKEEPER-63.patch > > > There is a race condition in the java close operation on ZooKeeper.java. > Client is sending a disconnect request to the server. Server will close any > open connections with the client when it receives this. If the client has not > yet shutdown it's subthreads (event/send threads for example) these threads > may consider the condition an error. We see this alot in the tests where the > clients output error logs because they are unaware that a disconnection has > been requested by the client. > Ben mentioned: perhaps we just have to change state to closed (on client) > before sending disconnect request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616641#action_12616641 ] Doug Cutting commented on ZOOKEEPER-78: --- > FWIW I've attached about 5 patch files so far, with none of them being > committed anywhere [ ...] Are they getting reviewed promptly? A primary job of committers is to keep the Patch Available queue short, by trying to review patches within a few days of their contribution, either committing them or rejecting them with a clear explanation. If the committers are unable to keep up with the contributors, then the project probably needs more committers. In this case, contributors should also do everything they can to make committers lives easier, so as not to further delay their patches. Contributors should be nominated to become committers when they've provided a series (e.g., 3+) non-trivial, high-quality patches, and demonstrated an ability to work peacefully with existing committers, following procedures, etc. If someone provides patches that apply cleanly, fix real user problems, include unit tests, and the contributor responds to criticism in a positive manner, then they should be nominated as a committer in short order. Then they can start reviewing and grooming new committers themselves! > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-63) Race condition in client close() operation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-63: -- Assignee: james strachan (was: Benjamin Reed) > Race condition in client close() operation > -- > > Key: ZOOKEEPER-63 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63 > Project: Zookeeper > Issue Type: Bug > Components: java client >Reporter: Patrick Hunt >Assignee: james strachan > Attachments: patch_ZOOKEEPER-63.patch > > > There is a race condition in the java close operation on ZooKeeper.java. > Client is sending a disconnect request to the server. Server will close any > open connections with the client when it receives this. If the client has not > yet shutdown it's subthreads (event/send threads for example) these threads > may consider the condition an error. We see this alot in the tests where the > clients output error logs because they are unaware that a disconnection has > been requested by the client. > Ben mentioned: perhaps we just have to change state to closed (on client) > before sending disconnect request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616637#action_12616637 ] Mahadev konar commented on ZOOKEEPER-38: i am working on it... should get it out by next week > headers (version+) in log/snap files > > > Key: ZOOKEEPER-38 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Benjamin Reed > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, > ZOOKEEPER-38.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1961767&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] Assigned: (ZOOKEEPER-32) CRCs for ZooKeeper data
[ https://issues.apache.org/jira/browse/ZOOKEEPER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kornev reassigned ZOOKEEPER-32: -- Assignee: Benjamin Reed (was: Andrew Kornev) Part of ZOOKEEPER-38 patch > CRCs for ZooKeeper data > --- > > Key: ZOOKEEPER-32 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-32 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Benjamin Reed > Fix For: 3.0.0 > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1945106&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] Assigned: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kornev reassigned ZOOKEEPER-38: -- Assignee: Benjamin Reed (was: Andrew Kornev) How's the cracking been going so far? > headers (version+) in log/snap files > > > Key: ZOOKEEPER-38 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Benjamin Reed > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, > ZOOKEEPER-38.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1961767&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] Resolved: (ZOOKEEPER-26) monitoring and management via JMX
[ https://issues.apache.org/jira/browse/ZOOKEEPER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kornev resolved ZOOKEEPER-26. Resolution: Won't Fix Fix Version/s: (was: 3.0.0) This feature was implemented and commited prior to the apache move. > monitoring and management via JMX > - > > Key: ZOOKEEPER-26 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-26 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Andrew Kornev > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1894138&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] Closed: (ZOOKEEPER-26) monitoring and management via JMX
[ https://issues.apache.org/jira/browse/ZOOKEEPER-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Kornev closed ZOOKEEPER-26. -- > monitoring and management via JMX > - > > Key: ZOOKEEPER-26 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-26 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Andrew Kornev > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1894138&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-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616624#action_12616624 ] Doug Cutting commented on ZOOKEEPER-78: --- > Give me a few weeks or so to completely finish the code and documentation and > I'll submit a single big patch for all the work to this JIRA. If you want to get more feedback as you go, please attach interim patches too, rather than just the final patch. That way folks who monitor the -dev mailing list will see the updates and can try them in the usual manner. We generally don't put things into the "Patch Available" state until the contributor believes that the patch is in a final form. > Everyone has access to ASF svn? I think all that Nigel meant was that not everyone can submit patches by naming an Apache svn revision since not everyone has commit access to Apache's svn. We try to use a uniform mechanism, the same for committers as non-committers. Committers generally have to do more work, not less, than other contributors, since every patch committed must be reviewed and accepted by a committer. Committing is a duty, not a privilege. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616603#action_12616603
]
james strachan commented on ZOOKEEPER-78:
-
{quote}
Let's stick with a process for now that all contributors can use, not just ASF
committers.
{quote}
Huh? Everyone has access to ASF svn? Only committers can commit using either
approach. I don't grok your point.
> added a high level protocol/feature - for easy Leader Election or exclusive
> Write Lock creation
> ---
>
> Key: ZOOKEEPER-78
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
> Project: Zookeeper
> Issue Type: New Feature
> Components: java client
>Affects Versions: 3.0.0
>Reporter: james strachan
> Attachments: patch_with_including_Benjamin's_fix.patch,
> using_zookeeper_facade.patch
>
>
> Here's a patch which adds a little WriteLock helper class for performing
> leader elections or creating exclusive locks in some directory znode. Note
> its an early cut; am sure we can improve it over time. The aim is to avoid
> folks having to use the low level ZK stuff but provide a simpler high level
> abstraction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-39) Use Watcher objects rather than boolean on read operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616599#action_12616599 ] Andrew Kornev commented on ZOOKEEPER-39: No, this patch doesn't take care of ZOOKEEPER-50, which is a bug in the Java client code. This patch is for the C client only. > Use Watcher objects rather than boolean on read operations > -- > > Key: ZOOKEEPER-39 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-39 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Andrew Kornev > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-39.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1962501&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-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616591#action_12616591
]
Nigel Daley commented on ZOOKEEPER-78:
--
{quote}
Fewer, simpler mechanisms generally include more people.
{quote}
+1. Let's stick with a process for now that all contributors can use, not just
ASF committers.
> added a high level protocol/feature - for easy Leader Election or exclusive
> Write Lock creation
> ---
>
> Key: ZOOKEEPER-78
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
> Project: Zookeeper
> Issue Type: New Feature
> Components: java client
>Affects Versions: 3.0.0
>Reporter: james strachan
> Attachments: patch_with_including_Benjamin's_fix.patch,
> using_zookeeper_facade.patch
>
>
> Here's a patch which adds a little WriteLock helper class for performing
> leader elections or creating exclusive locks in some directory znode. Note
> its an early cut; am sure we can improve it over time. The aim is to avoid
> folks having to use the low level ZK stuff but provide a simpler high level
> abstraction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616590#action_12616590 ] Patrick Hunt commented on ZOOKEEPER-83: --- When I pinged Nigel earlier we got our wires crossed, I understood ASF Hudson to not support Maven (I know Hudson in general does), but after my comment he pinged me back saying that it does - it's an option when you initially create but doesn't show up on configure page (if you select ant rather than maven) which further lead to my confusion. Sorry, my bad > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616586#action_12616586 ] Mahadev konar commented on ZOOKEEPER-83: i like the idea. +1 for maven directory convention and no maven build files and using ant .. > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616583#action_12616583 ] Nigel Daley commented on ZOOKEEPER-83: -- +1 for staying with Ant and creating maven artifacts. > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-39) Use Watcher objects rather than boolean on read operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616581#action_12616581 ] Mahadev konar commented on ZOOKEEPER-39: the patch looks good ... andrew is zookeeper-50 taken care of in this patch? > Use Watcher objects rather than boolean on read operations > -- > > Key: ZOOKEEPER-39 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-39 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt >Assignee: Andrew Kornev > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-39.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1962501&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-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616580#action_12616580 ] james strachan commented on ZOOKEEPER-83: - Hudson does support Maven and Ant natively http://hudson.gotdns.com/wiki/display/HUDSON/Plugins#Plugins-Buildtools > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616577#action_12616577 ] Hiram Chirino commented on ZOOKEEPER-83: BTW Hudson does support maven.. see: http://weblogs.java.net/blog/kohsuke/archive/2007/02/maven_2_integra.html > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616579#action_12616579 ] james strachan commented on ZOOKEEPER-78: - Wow I confess to be being kinda surprised by that response :) I didn't realise you guys were so attached to the exact svn command line used to apply a patch - I thought you'd welcome all contributions and that the svn commit history would be more useful to you, given the large amount of changes and complexity of the code and large number of comments already on this JIRA - rather than focus purely on a minor couple of keystrokes required apply the patch :) FWIW I've attached about 5 patch files so far, with none of them being committed anywhere - then made about 7 patches since then in svn with history and I'm sure there'll be another 5 or so changes to go before this patch is done. Never mind - I'll happily comply with your strict patch acceptance policy. Give me a few weeks or so to completely finish the code and documentation and I'll submit a single big patch for all the work to this JIRA. If you want you can get all the history too with a trivial alternative svn command - but if that offends you, please forget I'm using a sandbox svn area to work on this (pretend I'm just saving it on my hard drive and please disregard the links I've added to some JIRAs to refer to parts of this patch in a simple way) and just use the single patch file I'll attach in a few weeks or so. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616575#action_12616575 ] Hiram Chirino commented on ZOOKEEPER-83: BTW there are lots of CI tools used at the ASF which DO support maven. But hey if you like Hudson that's cool. Can we at least merge the patch in so that the maven directory convention is preserved and then we can delete the maven build files if you like. The ant build can work with that structure just fine. If we do that then I can provide folks who are interested in a maven build the pom files that just overlay onto the project do they can use maven to build it. So we both win. ZooKeeper only has 1 build system ant. Maven users also win cause they can get some optional poms from me to build the project with. What do you think? > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- 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-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616567#action_12616567 ] chirino edited comment on ZOOKEEPER-78 at 7/24/08 11:30 AM: -- Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are both Apache committers and Members, and as such, when we commit code to the ASF repository a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] was (Author: chirino): Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, and as such, when we commit code to the ASF repository a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- 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-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616567#action_12616567 ] chirino edited comment on ZOOKEEPER-78 at 7/24/08 11:28 AM: -- Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, and as such, when we commit code to the ASF repository a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] was (Author: chirino): Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, as such when we commit code to the ASF repository like what James had done, and like when you do when you commit code to zookeeper trunk, a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616567#action_12616567 ] Hiram Chirino commented on ZOOKEEPER-78: Hi Patrick, The "Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. " is not accurate in this case. James and I are are bother Apache committers and Members, as such when we commit code to the ASF repository like what James had done, and like when you do when you commit code to zookeeper trunk, a license is granted to the ASF. The jira feature is really only there to be able to accept code from folks who have not filed an ICLA with the ASF. Another way to view this development model is as if we were ZooKeeper committers who do not commit to trunk but which develop new features and bug fixes in development branches. This model of development is use extensively in projects who are adverse to destabilizing the trunk. They develop and test new features in a branch and then merge back once folks are happy with it. This model is also outlined at [Rules for Revolutionaries|http://incubator.apache.org/learn/rules-for-revolutionaries.html] > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-87) Follower does not shut itself down if its too far behind the leader.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616566#action_12616566 ] Mahadev konar commented on ZOOKEEPER-87: throttling at the follower is a little tricky. do you mean the follower will stop reading requests ? since you do not know what is on the tcp stack --- when you do a send it might be buffered on either of the tcp stacks on the leader and the follower. so you do not know how many txn's are buffered up the tcp stack. So throttling is a tricky thing with the follower and leader. also the rsponse to leader.PING are critical with session management. > Follower does not shut itself down if its too far behind the leader. > > > Key: ZOOKEEPER-87 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-87 > Project: Zookeeper > Issue Type: Bug >Reporter: Mahadev konar >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.0.0 > > > Currently, the follower if lagging behind keeps sending pings to the leader > it will stay alive and will keep getting further and further behind the > leader. The follower should shut itself down if it is not able to keep up to > the leader within some limit so that gurantee of updates can be made to the > clients connected to different servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616560#action_12616560 ] Patrick Hunt commented on ZOOKEEPER-83: --- ASF Hudson, our CI for ZooKeeper, does not support Maven: http://hudson.zones.apache.org/hudson/view/ZooKeeper/ I'm -1 on supporting multiple build systems. +1 for having zookeeper jars in the maven repository (I suggest someone create a new JIRA for this as it's orthogonal to the build tool) > Switch to using maven to build ZooKeeper > > > Key: ZOOKEEPER-83 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 > Project: Zookeeper > Issue Type: Improvement > Components: build >Reporter: Hiram Chirino > Attachments: zookeeper-mavened.tgz > > > Maven is a great too for building java projects at the ASF. It helps > standardize the build a bit since it's a convention oriented. > It's dependency auto downloading would remove the need to store the > dependencies in svn, and it will handle many of the suggested ASF policies > like gpg signing of the releases and such. > The ZooKeeper build is almost vanilla except for the jute compiler bits. > Things that would need to change are: > * re-organize the source tree a little so that it uses the maven directory > conventions > * seperate the jute bits out into seperate modules so that a maven plugin > can be with it > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-87) Follower does not shut itself down if its too far behind the leader.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616556#action_12616556 ] Flavio Paiva Junqueira commented on ZOOKEEPER-87: - If you throttle at the follower, then the queue on the leader side will build up, and you won't have the problem you mention. The approach I describe seems to be safer as you don't have to wait for the next Leader.PING period to make a decision. It is true that the leader can send a ping at any time it wants, but if the leader is clueless as you say, then it will wait for the next ping period and it won't send any exceptional pings. > Follower does not shut itself down if its too far behind the leader. > > > Key: ZOOKEEPER-87 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-87 > Project: Zookeeper > Issue Type: Bug >Reporter: Mahadev konar >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.0.0 > > > Currently, the follower if lagging behind keeps sending pings to the leader > it will stay alive and will keep getting further and further behind the > leader. The follower should shut itself down if it is not able to keep up to > the leader within some limit so that gurantee of updates can be made to the > clients connected to different servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-93) Create Documentation for Zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Scott updated ZOOKEEPER-93: -- Component/s: (was: c client) documentation > Create Documentation for Zookeeper > -- > > Key: ZOOKEEPER-93 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-93 > Project: Zookeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.0.0 > Environment: N/A >Reporter: Robbie Scott > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-93.patch > > Original Estimate: 0.02h > Remaining Estimate: 0.02h > > Initial version of the documentation, migrated from source forge. > Reorganizing, expanding. Initial goal is to port Source Forge documentation > into Forrest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-93) Create Documentation for Zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Scott updated ZOOKEEPER-93: -- Attachment: ZOOKEEPER-93.patch This is a first, rough draft of Zookeeper documentation, concentrating mostly on moving information from the SourceForge set over to Apache/Forrest. Any and all comments are welcome. Notes: 1) I'm writing in DocBook 4.2. (forrest.properties modified to load the correct plugin) 2) links site.xml and index.xml may not be in the right format. For example, I just point to an html right off the root. It looks like you are doing "ext:dirname/dirname" etc. 3) I've worked mostly on the overview. It's clear where I've stopped, as suddenly the file just becomes an outline. There are all manner of inaccuracies that need to be worked out -- I've marked these with [tbd]. 4) The other documents -- the admin guide, getting started, etc -- exist only as outlines right now. I'm flush out all the skeletons with the text straight from the existing (sourceforge generation) of the docs. 5) I changed index.xml to have some welcome verbage -- just to have something there. (Everything should be considered in-flux obviously.) 6) I will continue flushing out the overview, then move onto the other docs until all the source forge info is moved over. After that, I'll start working on a few new documents -- like a real programmer's guide, etc. > Create Documentation for Zookeeper > -- > > Key: ZOOKEEPER-93 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-93 > Project: Zookeeper > Issue Type: Task > Components: c client >Affects Versions: 3.0.0 > Environment: N/A >Reporter: Robbie Scott > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-93.patch > > Original Estimate: 0.02h > Remaining Estimate: 0.02h > > Initial version of the documentation, migrated from source forge. > Reorganizing, expanding. Initial goal is to port Source Forge documentation > into Forrest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
Since we are already feeling the burden of moving to apache, we can just work with svn diff for now and leave the discussion for later. It will give us more time to focus on the 3.0 release which needs a lot of work right now. Mahadev On 7/24/08 10:43 AM, "Doug Cutting (JIRA)" <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plu > gin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616547#action_12 > 616547 ] > > Doug Cutting commented on ZOOKEEPER-78: > --- > > The project's patch submission mechanism is not inflexible, but neither should > it be changed unilaterally on an issue-by-issue basis. The currently > acceptable mechanism is to attach patch files to Jira, generated by 'svn > diff'. When files are renamed, a shell script should be provided that > performs the renames, where the script is run before the patch is applied. If > some find this awkward, then a separate discussion should be launched on the > mailing list. Some projects are now, e.g., using 'git' to handle things like > this, but this needs to be done carefully so that the entire community is > included in the process. Fewer, simpler mechanisms generally include more > people. > >> added a high level protocol/feature - for easy Leader Election or exclusive >> Write Lock creation >> - >> -- >> >> Key: ZOOKEEPER-78 >> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 >> Project: Zookeeper >> Issue Type: New Feature >> Components: java client >>Affects Versions: 3.0.0 >>Reporter: james strachan >> Attachments: patch_with_including_Benjamin's_fix.patch, >> using_zookeeper_facade.patch >> >> >> Here's a patch which adds a little WriteLock helper class for performing >> leader elections or creating exclusive locks in some directory znode. Note >> its an early cut; am sure we can improve it over time. The aim is to avoid >> folks having to use the low level ZK stuff but provide a simpler high level >> abstraction.
[jira] Commented: (ZOOKEEPER-87) Follower does not shut itself down if its too far behind the leader.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616550#action_12616550 ] Mahadev konar commented on ZOOKEEPER-87: i was thinking abt the same lines but not on maximum capacity on follower handlers -- ben and I had a discussion regarding this and we decided on doing htis --- 1) we send a Leader.PING from the leader to the follower --- we will include the ticktime at the leader and send it to the follower 2) the follower just returns back the tick time with the ping response. 3) we update the ticktime that we saw last from the follower and then kill the follower handler if its lagging behind. -- this approach is less error prone since we are getting response from the follower and know whats the last ticktime it processed. The problem with your suggestion is that you might be sending it out fast to the follower but the follower might be buffering all of it and not doing anything with it... though the above suggestion has a problem right now since the Leader.PING does not go through the pipeline at the follower. so a response to the ping does not necessarily mean that the follower is in line with processing the requests. We have to get an end to end response from the follower to see how much it is behind.. > Follower does not shut itself down if its too far behind the leader. > > > Key: ZOOKEEPER-87 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-87 > Project: Zookeeper > Issue Type: Bug >Reporter: Mahadev konar >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.0.0 > > > Currently, the follower if lagging behind keeps sending pings to the leader > it will stay alive and will keep getting further and further behind the > leader. The follower should shut itself down if it is not able to keep up to > the leader within some limit so that gurantee of updates can be made to the > clients connected to different servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-93) Create Documentation for Zookeeper
Create Documentation for Zookeeper -- Key: ZOOKEEPER-93 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-93 Project: Zookeeper Issue Type: Task Components: c client Affects Versions: 3.0.0 Environment: N/A Reporter: Robbie Scott Fix For: 3.0.0 Initial version of the documentation, migrated from source forge. Reorganizing, expanding. Initial goal is to port Source Forge documentation into Forrest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616547#action_12616547 ] Doug Cutting commented on ZOOKEEPER-78: --- The project's patch submission mechanism is not inflexible, but neither should it be changed unilaterally on an issue-by-issue basis. The currently acceptable mechanism is to attach patch files to Jira, generated by 'svn diff'. When files are renamed, a shell script should be provided that performs the renames, where the script is run before the patch is applied. If some find this awkward, then a separate discussion should be launched on the mailing list. Some projects are now, e.g., using 'git' to handle things like this, but this needs to be done carefully so that the entire community is included in the process. Fewer, simpler mechanisms generally include more people. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616545#action_12616545 ] Patrick Hunt commented on ZOOKEEPER-78: --- Hi James -- I understand where you are coming from and we appreciate the effort, but regarding use of SVN for patch submission - I'm afraid this is not acceptable. Notice on the "attach patch" JIRA page that it has the " Grant license to ASF for inclusion in ASF works " option. This has to be checked for us to consider a patch for inclusion. Also consider that we have limited resources/time and need to follow the designated patch process in order to optimize around the limited set of core reviewers/commiters we have relative to the community at large. (if you think you've got it bad checkout some of the hadoop examples like: https://issues.apache.org/jira/browse/HADOOP-3412) What I'd suggest is that you "overwrite" the existing patch when submitting an update. If you upload a file with the same name the old version of the file _is_ still available in the JIRA, and the new file will take it's place. (I need to update the wiki with this, just haven't gotten around to it - ok just added near the end of the "contributing your work section", thanks) A bit less important but wanted to mention the naming scheme defined on the following page (creating a patch section): http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute ZOOKEEPER-#.patch This helps reviewers/committers keep all the patches straight. :-) > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-58) Race condition on ClientCnxn.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616521#action_12616521 ] Flavio Paiva Junqueira commented on ZOOKEEPER-58: - yeah, right, I'll take care of it... :-) > Race condition on ClientCnxn.java > - > > Key: ZOOKEEPER-58 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-58 > Project: Zookeeper > Issue Type: Bug > Components: java client >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Attachments: patch-incoming-race.txt > > > There is a race condition involving the ByteByffer incomingBuffer, a field of > ClientCnxn.SendThread. SendThread reads a packet in two steps: first it reads > the length of the packet, followed by a read of the packet itself. Each of > these steps corresponds to a call to doIO() from the main loop of run(). If > there is an exception or the session times out, then it may leave > incomingBuffer in an inconsistent state. > The attached patch adds code to reset incomingBuffer upon a call to > SendThread.cleanup(). This method is called upon an exception on run(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-58) Race condition on ClientCnxn.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan updated ZOOKEEPER-58: Status: Patch Available (was: Open) just marking this issue as having a patch - does a committer fancy applying it? :) > Race condition on ClientCnxn.java > - > > Key: ZOOKEEPER-58 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-58 > Project: Zookeeper > Issue Type: Bug > Components: java client >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Attachments: patch-incoming-race.txt > > > There is a race condition involving the ByteByffer incomingBuffer, a field of > ClientCnxn.SendThread. SendThread reads a packet in two steps: first it reads > the length of the packet, followed by a read of the packet itself. Each of > these steps corresponds to a call to doIO() from the main loop of run(). If > there is an exception or the session times out, then it may leave > incomingBuffer in an inconsistent state. > The attached patch adds code to reset incomingBuffer upon a call to > SendThread.cleanup(). This method is called upon an exception on run(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-74) Cleaning/restructuring up Zookeeper server code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-74?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616518#action_12616518 ] james strachan commented on ZOOKEEPER-74: - its a very minor thing, but the contributing guide says to use Sun's coding conventions.. http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute yet lots of the code tends to litter fields in classes in between methods; its sometimes a bit hard looking at the source to grok what fields are owned by what object. I prefer the Sun standards where all the fields are at the top as most java folks and apache java projects do. Though good IDE's can kinda work around this though and so I tend to rely on the outline view in my IDE rather than the source to grok what state a class has :) > Cleaning/restructuring up Zookeeper server code > --- > > Key: ZOOKEEPER-74 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-74 > Project: Zookeeper > Issue Type: Improvement > Components: server >Reporter: Mahadev konar >Assignee: Mahadev konar > Fix For: 3.0.0 > > > I have been thinking this for a while and find that the zookeeper server code > needs some cleaning up. The server code is a little tricky/confusing to read > sometimes gievn that there is no clearity on ownership of objects. I will put > down a proposal for restructuring/cleaning the code up with javadocs so that > the code is easier to understand and develop on. comments on what you find > confusing are welcome on this jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-88) implement java.util.concurrent.locks.Lock
[ https://issues.apache.org/jira/browse/ZOOKEEPER-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan updated ZOOKEEPER-88: Status: Patch Available (was: Open) I've just submitted an [initial patch at implementing this|http://svn.apache.org/viewvc?rev=679435&view=rev] which could use some more tests and code review > implement java.util.concurrent.locks.Lock > - > > Key: ZOOKEEPER-88 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-88 > Project: Zookeeper > Issue Type: Sub-task > Components: java client >Reporter: james strachan > > we should implement the > [java.util.concurrent.locks.Lock|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html] > to make it easier for folks to reuse the Lock and to help make the API be > more natural to end users -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-90) invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the znode is the leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616456#action_12616456 ] james strachan commented on ZOOKEEPER-90: - I guess the earlier we can notify a leader/owner that they are no longer gonna be the leader/owner the better. e.g. its better to notify them up front than wait until the effect of a socket closing etc? > invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the > znode is the leader > --- > > Key: ZOOKEEPER-90 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-90 > Project: Zookeeper > Issue Type: Sub-task >Reporter: james strachan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-90) invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the znode is the leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616455#action_12616455 ] james strachan commented on ZOOKEEPER-90: - FWIW I don't think the ZooKeeperFacade needs to have a WhenOwnerListener to be honest; as the underlying ZooKeeper should invoke the Watcher directly - when the connection is closed via the session expired reconnect or via close(). I guess it doesn't harm to have a few too many events firing in there just in case :) > invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the > znode is the leader > --- > > Key: ZOOKEEPER-90 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-90 > Project: Zookeeper > Issue Type: Sub-task >Reporter: james strachan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-42) Change LE default to Fast TCP
[ https://issues.apache.org/jira/browse/ZOOKEEPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-42: Attachment: ZOOKEEPER-42.patch Changes the default leader election algorithm, and sets the default port to 2182. > Change LE default to Fast TCP > - > > Key: ZOOKEEPER-42 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-42 > Project: Zookeeper > Issue Type: Improvement > Components: leaderElection >Reporter: Patrick Hunt >Assignee: Flavio Paiva Junqueira > Attachments: ZOOKEEPER-42.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1970356&group_id=209147&atid=1008546 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-42) Change LE default to Fast TCP
[ https://issues.apache.org/jira/browse/ZOOKEEPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-42: Assignee: Benjamin Reed (was: Flavio Paiva Junqueira) Status: Patch Available (was: Open) > Change LE default to Fast TCP > - > > Key: ZOOKEEPER-42 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-42 > Project: Zookeeper > Issue Type: Improvement > Components: leaderElection >Reporter: Patrick Hunt >Assignee: Benjamin Reed > Attachments: ZOOKEEPER-42.patch > > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1970356&group_id=209147&atid=1008546 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-92) spring factory beans for ZooKeeper, ZooKeeperFacade and ZooKeeperServer
spring factory beans for ZooKeeper, ZooKeeperFacade and ZooKeeperServer --- Key: ZOOKEEPER-92 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-92 Project: Zookeeper Issue Type: Sub-task Components: java client Reporter: james strachan for folks who use Spring for Dependency Injection it might be handy to have a couple of factory beans to make it easier to create and configure the ZooKeeper, ZooKeeperFacade and ZooKeeperServer via the normal Spring dependency mechanism; via Java or XML code etc -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-89) invoke WhenOwnerListener.whenNotOwner() when the ZK connection fails
[ https://issues.apache.org/jira/browse/ZOOKEEPER-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved ZOOKEEPER-89. - Resolution: Fixed fixed now with [this patch|http://svn.apache.org/viewvc?rev=679354&view=rev] from ZOOKEEPER-78 > invoke WhenOwnerListener.whenNotOwner() when the ZK connection fails > > > Key: ZOOKEEPER-89 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-89 > Project: Zookeeper > Issue Type: Sub-task >Reporter: james strachan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616446#action_12616446 ] james strachan commented on ZOOKEEPER-78: - Benjamin I added ZOOKEEPER-89 and ZOOKEEPER-90 to track the dealing with loss of ownership/leader with connection reconnects and with session expiration. I've not been able to test out the latter yet; but I've tested the former and I think both are implemented now via the patch for [ZOOKEEPER-90|http://svn.apache.org/viewvc?rev=679354&view=r] and [ZOOKEEPER-89|http://svn.apache.org/viewvc?rev=679341&view=rev] > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-91) provide an option for the WriteLock to also watch the locks own znode, so that if someone else deletes it then it is equivalent to calling WriteLock.unlock()
provide an option for the WriteLock to also watch the locks own znode, so that if someone else deletes it then it is equivalent to calling WriteLock.unlock() - Key: ZOOKEEPER-91 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-91 Project: Zookeeper Issue Type: Sub-task Components: java client Reporter: james strachan Most clients probably wont need this, but it could be a handy system management feature to allow the WriteLock to watch its own znode so that if someone else deletes it, it then relinquishes the lock and tries to get it back again -- 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 #32
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/32/changes -- [...truncated 17082 lines...] [junit] 2008-07-24 10:41:52,829 - INFO [main:[EMAIL PROTECTED] - Client test setup [junit] 2008-07-24 10:41:57,896 - INFO [main:[EMAIL PROTECTED] - Client test setup finished [junit] 2008-07-24 10:41:57,913 - INFO [SendThread:[EMAIL PROTECTED] - Attempting connection to server /127.0.0.1:33221 [junit] 2008-07-24 10:41:57,914 - INFO [SendThread:[EMAIL PROTECTED] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:53977 remote=/127.0.0.1:33221] [junit] 2008-07-24 10:41:57,923 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Connected to /127.0.0.1:53977 lastZxid 0 [junit] 2008-07-24 10:41:57,925 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Creating new session 11b54a918f5 [junit] 2008-07-24 10:41:57,971 - WARN [SyncThread:[EMAIL PROTECTED] - Finished init of 11b54a918f5: true [junit] 2008-07-24 10:41:57,973 - INFO [SendThread:[EMAIL PROTECTED] - Attempting connection to server /127.0.0.1:33221 [junit] 2008-07-24 10:41:57,974 - INFO [SendThread:[EMAIL PROTECTED] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:53978 remote=/127.0.0.1:33221] [junit] 2008-07-24 10:41:57,975 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Connected to /127.0.0.1:53978 lastZxid 0 [junit] 2008-07-24 10:41:57,975 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Creating new session 11b54a918f50001 [junit] 2008-07-24 10:41:57,986 - WARN [SyncThread:[EMAIL PROTECTED] - Finished init of 11b54a918f50001: true [junit] 2008-07-24 10:41:58,273 - INFO [ProcessThread:[EMAIL PROTECTED] - Processed session termination request for id: 11b54a918f5 [junit] 2008-07-24 10:41:58,281 - WARN [SendThread:[EMAIL PROTECTED] - Closing: [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:491) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:712) [junit] 2008-07-24 10:41:58,390 - INFO [ProcessThread:[EMAIL PROTECTED] - Processed session termination request for id: 11b54a918f50001 [junit] 2008-07-24 10:41:58,403 - WARN [SendThread:[EMAIL PROTECTED] - Closing: [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:491) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:712) [junit] 2008-07-24 10:41:59,936 - INFO [SendThread:[EMAIL PROTECTED] - Attempting connection to server /127.0.0.1:33221 [junit] 2008-07-24 10:41:59,937 - INFO [SendThread:[EMAIL PROTECTED] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:53979 remote=/127.0.0.1:33221] [junit] 2008-07-24 10:41:59,938 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Connected to /127.0.0.1:53979 lastZxid 10 [junit] 2008-07-24 10:41:59,938 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Finished init of 11b54a918f5: false [junit] 2008-07-24 10:41:59,939 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Renewing session 11b54a918f5 [junit] 2008-07-24 10:41:59,940 - WARN [SendThread:[EMAIL PROTECTED] - Closing: [junit] java.io.IOException: Session Expired [junit] at org.apache.zookeeper.ClientCnxn$SendThread.readConnectResult(ClientCnxn.java:414) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:499) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:712) [junit] 2008-07-24 10:42:00,276 - INFO [SendThread:[EMAIL PROTECTED] - Attempting connection to server /127.0.0.1:33221 [junit] 2008-07-24 10:42:00,277 - INFO [SendThread:[EMAIL PROTECTED] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:53980 remote=/127.0.0.1:33221] [junit] 2008-07-24 10:42:00,298 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Connected to /127.0.0.1:53980 lastZxid -1 [junit] 2008-07-24 10:42:00,299 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Finished init of 11b54a918f50001: false [junit] 2008-07-24 10:42:00,299 - WARN [NIOServerCxn.Factory:[EMAIL PROTECTED] - Renewing session 11b54a918f50001 [junit] 2008-07-24 10:42:00,300 - WARN [SendThread:[EMAIL PROTECTED] - Closing: [junit] java.io.IOException: Session Expired [junit] at org.apache.zookeeper.ClientCnxn$SendThread.readConnectResult(ClientCnxn.java:414) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:499) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:712) [junit] 2008-07-24 10:42:03,516 - INFO [main:[EMAIL PROTECTED] - Clent
[jira] Resolved: (ZOOKEEPER-90) invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the znode is the leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan resolved ZOOKEEPER-90. - Resolution: Fixed this is now fixed in [this patch|http://svn.apache.org/viewvc?rev=679341&view=rev] to ZOOKEEPER-78 > invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the > znode is the leader > --- > > Key: ZOOKEEPER-90 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-90 > Project: Zookeeper > Issue Type: Sub-task >Reporter: james strachan > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-87) Follower does not shut itself down if its too far behind the leader.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616435#action_12616435 ] Flavio Paiva Junqueira commented on ZOOKEEPER-87: - Mahadev, I was thinking that we we could set a maximum capacity to queuedPackets on FollowerHandler, and check the remaining capacity on FollowerHandler.queuePacket() before accepting a new packet. We could then invoke FollowerHandler.shutdown() in the case we reach the capacity. What do you think? If you think this is a good idea, I can create a patch. > Follower does not shut itself down if its too far behind the leader. > > > Key: ZOOKEEPER-87 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-87 > Project: Zookeeper > Issue Type: Bug >Reporter: Mahadev konar >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.0.0 > > > Currently, the follower if lagging behind keeps sending pings to the leader > it will stay alive and will keep getting further and further behind the > leader. The follower should shut itself down if it is not able to keep up to > the leader within some limit so that gurantee of updates can be made to the > clients connected to different servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-63) Race condition in client close() operation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616426#action_12616426 ] james strachan commented on ZOOKEEPER-63: - So this patch does not attempt to fix the race condition problem, apologies if I gave that impression :) What it does do though is act as a workaround so that if a client is not able to properly send a disconnect packet to the server for *any reason at all* such as * a hung socket (which can be quite common) * no servers available * a race condition in the ZK client code of some kind (which we definitely have now) to not hang the client application forever - as its trying to close and shut down anyway :). So its a side benefit that it acts as a band aid until someone fixes all the possible race conditions and potential socket hangs. Let me put it another way. Given that the client is closing; is it really correct to leave it potentially hanging around forever just because it cannot be sure if the disconnect packet was received and properly processed by the server? If the socket is dead before the call to close(), is it really correct to block until a connection can be re-established, just so it can be properly closed - when the code will effectively close the hung socket without sending a disconnect packet anyway :) ? The server has to detect and timeout failed sessions; whether it receives an explicit disconnect packet or not (as a process could just hang). So do we really need to be super strict on the client side, forcing clients to block when trying to shut down if they can't do so cleanly within some time period? I totally agree that we should fix the race condition though :). I just wanted a work around to avoid my ZK test cases hanging forever due to the race condition :) > Race condition in client close() operation > -- > > Key: ZOOKEEPER-63 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63 > Project: Zookeeper > Issue Type: Bug > Components: java client >Reporter: Patrick Hunt >Assignee: Benjamin Reed > Attachments: patch_ZOOKEEPER-63.patch > > > There is a race condition in the java close operation on ZooKeeper.java. > Client is sending a disconnect request to the server. Server will close any > open connections with the client when it receives this. If the client has not > yet shutdown it's subthreads (event/send threads for example) these threads > may consider the condition an error. We see this alot in the tests where the > clients output error logs because they are unaware that a disconnection has > been requested by the client. > Ben mentioned: perhaps we just have to change state to closed (on client) > before sending disconnect request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-84) provide a mechanism to reconnect a ZooKeeper if a client receives a SessionExpiredException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616420#action_12616420 ] james strachan commented on ZOOKEEPER-84: - BTW here is the code for [ZooKeeperFacade|http://svn.apache.org/viewvc/activemq/sandbox/zookeeper/zookeeper-protocols/src/main/java/org/apache/zookeeper/protocols/ZooKeeperFacade.java?view=markup] as I've checked in the patch for ZOOKEEPER-78 into a temporary sandbox area, [details here|https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616391#action_12616391] > provide a mechanism to reconnect a ZooKeeper if a client receives a > SessionExpiredException > --- > > Key: ZOOKEEPER-84 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-84 > Project: Zookeeper > Issue Type: Improvement > Components: java client >Reporter: james strachan >Assignee: Benjamin Reed > Attachments: reconnect_patch.patch > > > am about to attach a patch which adds a reconnect() method to easily > re-establish a connection if a session expires - along with a toString() > implementation for easier debugging -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-90) invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the znode is the leader
invoke WhenOwnerListener.whenNotOwner() when the ZK session expires and the znode is the leader --- Key: ZOOKEEPER-90 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-90 Project: Zookeeper Issue Type: Sub-task Reporter: james strachan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-89) invoke WhenOwnerListener.whenNotOwner() when the ZK connection fails
invoke WhenOwnerListener.whenNotOwner() when the ZK connection fails Key: ZOOKEEPER-89 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-89 Project: Zookeeper Issue Type: Sub-task Reporter: james strachan -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-22) Automatic request retries on connect failover
[ https://issues.apache.org/jira/browse/ZOOKEEPER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616418#action_12616418 ] james strachan commented on ZOOKEEPER-22: - BTW you can see the code for [ProtocolSupport|http://svn.apache.org/viewvc/activemq/sandbox/zookeeper/zookeeper-protocols/src/main/java/org/apache/zookeeper/protocols/ProtocolSupport.java?view=markup] and [ZooKeeperFacade|http://svn.apache.org/viewvc/activemq/sandbox/zookeeper/zookeeper-protocols/src/main/java/org/apache/zookeeper/protocols/ZooKeeperFacade.java?view=markup] as I've checked in the patch for ZOOKEEPER-78 into a temporary sandbox area, [details here|https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616391#action_12616391] > Automatic request retries on connect failover > - > > Key: ZOOKEEPER-22 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-22 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1831412&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-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616416#action_12616416 ] james strachan commented on ZOOKEEPER-78: - Just added the WhenOwnerListener interface : http://svn.apache.org/viewvc?view=rev&revision=679325 I just need to figure out how to add notifications of loss of owner/leader status when the connection fails or the session expires etc. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-88) implement java.util.concurrent.locks.Lock
implement java.util.concurrent.locks.Lock - Key: ZOOKEEPER-88 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-88 Project: Zookeeper Issue Type: Sub-task Components: java client Reporter: james strachan we should implement the [java.util.concurrent.locks.Lock|http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/locks/Lock.html] to make it easier for folks to reuse the Lock and to help make the API be more natural to end users -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616413#action_12616413
]
james strachan commented on ZOOKEEPER-78:
-
Thanks for the great comments Benjamin! Have already [added the constructor for
you|https://svn.apache.org/repos/asf/activemq/sandbox/zookeeper/zookeeper-protocols/src/main/java/org/apache/zookeeper/protocols/WriteLock.java]
:)
BTW I was pondering about switching the whenOwner from a Runnable to some kinda
interface that invokes you when you become the leader/owner - or when you stop
being the leader/owner. Something like
{code}
public interface WhenOwnerListener {
void whenOwner();
void whenNotOwner();
}
{code}
Where only znodes that are the owner would be notified with the whenOwner()
method; but then if a connection fails or session times out, they'd be notified
with a call to whenNotOwner();
Spookily - I'd set myself the target today to properly implement the watches so
that WriteLock gets a notification of it no longer being the leader/owner when
a connection fails (which normally auto-reconnects anyway right now in the base
ZooKeeper). Then I was gonna add a notification mechanism so we could notify
the leader/owner is no longer the leader/owner when the session expired
exception occurs.
So we're absolutely on the same page; once I'd grokked the proper watch code
for dealing with normal connection failures & reconnects I was hoping to add
something vaguely similar to the ZooKeeperFacade so that higher level protocols
can be aware of both when ZooKeeper reconnects and when ZooKeeperFacade creates
a whole new connection.
Does that make sense? I totally understand your concerns at making sure the
WriteLock and associated helper classes like ProtocolSupport/ZooKeeperFacade do
the right thing - I want exactly the same thing :) I'd just not yet had the
chance to go through all the different failure conditions and scenarios and
make sure they all work properly :)
> added a high level protocol/feature - for easy Leader Election or exclusive
> Write Lock creation
> ---
>
> Key: ZOOKEEPER-78
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
> Project: Zookeeper
> Issue Type: New Feature
> Components: java client
>Affects Versions: 3.0.0
>Reporter: james strachan
> Attachments: patch_with_including_Benjamin's_fix.patch,
> using_zookeeper_facade.patch
>
>
> Here's a patch which adds a little WriteLock helper class for performing
> leader elections or creating exclusive locks in some directory znode. Note
> its an early cut; am sure we can improve it over time. The aim is to avoid
> folks having to use the low level ZK stuff but provide a simpler high level
> abstraction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616391#action_12616391 ] james strachan commented on ZOOKEEPER-78: - h3. Moving patches for this issue to subversion for easier tracking http://svn.apache.org/repos/asf/activemq/sandbox/zookeeper/zookeeper-protocols/ I've already submitted about five patches for this issue so far and I'm sure there's gonna be loads more coming. Developing higher level protocols is a much bigger job than I previously thought ;-) particularly with having tests for all the various failure scenarios and adding support for the various other higher level protocols. Its kinda time consuming creating loads of patches & attaching them to the same issue and deleting the old ones so its easy for commmitters to review - but more importantly, all the history of the many patches gets totally lost using the attach-patch-to-jira model - which also makes it harder for committers to watch progress on this issue. I've never done this before on any other Apache project - and this approach is *temporary* and only reserved for the single ZOOKEEPER-78 issue; but I've checked in this patch into an svn sandbox area at Apache that I have commit karma on and will continue to work on it there; so that all the history is preserved. I can then do many more frequent & smaller commits; any ZK committer can review and easily apply my patches whenever they feel like - and its gonna be much easier for anyone in the ZK community to track progress on this issue and see how the implementation has changed over time as some things work or I find better ways of solving the issue. This approach is totally temporary; its not an attempt to move the code outside of the ZK community or anything like that. At any point feel free to commit (actually just copy in svn which will keep all the history & commit comments etc) to the ZK trunk. You could even mirror the code to the ZK tree in sandbox/contrib area if you like - just like Hiram did to mirror the ZK code to the maven-patch example in the activemq sandbox. I'm hoping in a few weeks my hacking on this issue will near completion and we can permanently move the code back into the ZK tree; but in the meantime its trivial to reuse it where it is or mirror it into the ZK tree as folks in the ZK community see fit. Also if I ever earn committer karma on ZK I can just move it into some ZK contrib area myself :) h3. Building the code In terms of sandbox - I ended up reusing Hiram's sandbox area that shows the maven build working on ZK; as I prefer to use maven and it was then super easy for me to create a new maven module, zookeeper-protocols that just includes the source and test cases for the high level protocols. If you're new to maven and want to build it, I've checked in instructions here... https://svn.apache.org/repos/asf/activemq/sandbox/zookeeper/BUILDING-maven.txt Whenever we move this code back into the ZK trunk am sure we can hack an Ant build for it. > added a high level protocol/feature - for easy Leader Election or exclusive > Write Lock creation > --- > > Key: ZOOKEEPER-78 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 > Project: Zookeeper > Issue Type: New Feature > Components: java client >Affects Versions: 3.0.0 >Reporter: james strachan > Attachments: patch_with_including_Benjamin's_fix.patch, > using_zookeeper_facade.patch > > > Here's a patch which adds a little WriteLock helper class for performing > leader elections or creating exclusive locks in some directory znode. Note > its an early cut; am sure we can improve it over time. The aim is to avoid > folks having to use the low level ZK stuff but provide a simpler high level > abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-22) Automatic request retries on connect failover
[ https://issues.apache.org/jira/browse/ZOOKEEPER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616374#action_12616374 ] james strachan commented on ZOOKEEPER-22: - BTW this discussion came up recently on the dev lists too... http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED] To be able to retry operations on conection close (or due to session expiration) there is a patch in https://issues.apache.org/jira/browse/ZOOKEEPER-78 which adds a ZooKeeperFacade for dealing with reconnecting on session expiration and some helper methods in ProtocolSupport for retrying synchronous operations or blocks of code in light of connection failures > Automatic request retries on connect failover > - > > Key: ZOOKEEPER-22 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-22 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client >Reporter: Patrick Hunt > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1831412&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-86) intermittent test failure of org.apache.zookeeper.test.AsyncTest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616365#action_12616365 ] james strachan commented on ZOOKEEPER-86: - BTW I have sometimes still seen the AsyncHammerTest fail on OS X still; the basic issue is the restart of the quorum servers - its often the 3rd one - the server socket has not yet been released by the OS which tends to cause the failure. While things seem to work much better now, we might wanna add a bigger sleep in between restarts if it starts getting more common again > intermittent test failure of org.apache.zookeeper.test.AsyncTest > > > Key: ZOOKEEPER-86 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-86 > Project: Zookeeper > Issue Type: Bug > Components: tests > Environment: OS X and linux. It sometimes passes; but mostly seems to > fail on OS X each time >Reporter: james strachan > Attachments: patch_for_ZOOKEEPER-86.patch, > TEST-org.apache.zookeeper.test.AsyncTest.txt > > > Will attach the test output in an attachment... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
