You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(27) |
Feb
(34) |
Mar
(30) |
Apr
(151) |
May
(184) |
Jun
(55) |
Jul
(2) |
Aug
(6) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
From: Benjamin R. <br...@ya...> - 2008-10-28 21:51:38
|
We have moved development to Apache. With the release of 3.0 of ZooKeeper on Apache we are shutting down the sourceforge site. If you are still interested in ZooKeeper (we hope you are :) please subscribe to the lists at http://hadoop.apache.org/zookeeper. thank you ben |
From: SourceForge.net <no...@so...> - 2008-08-31 18:30:33
|
Bugs item #2028321, was opened at 2008-07-25 19:16 Message generated for change (Comment added) made by dodil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: parseAcl method has a bug Initial Comment: code for finding colons is incorrect. It gets the same colon twice and then considers it a wrong parse private static ArrayList<ACL> parseACLs(String aclString) { ArrayList<ACL> acl; String acls[] = aclString.split(","); acl = new ArrayList<ACL>(); for (String a : acls) { int firstColon = a.indexOf(':'); int lastColon = a.indexOf(':'); if (firstColon == -1 || lastColon == -1 || firstColon == lastColon) { //HERE**** <- first and last colon indexes are always the same**** System.err .println(a + " does not have the form scheme:id:perm"); continue; } ACL newAcl = new ACL(); newAcl.setId(new Id(a.substring(0, firstColon), a.substring( firstColon + 1, lastColon))); newAcl.setPerms(getPermFromString(a.substring(lastColon + 1))); acl.add(newAcl); } return acl; } ---------------------------------------------------------------------- Comment By: Don Pinto (dodil) Date: 2008-08-31 14:30 Message: Logged In: YES user_id=1289601 Originator: NO I already submitted a patch for this in patches section. ---------------------------------------------------------------------- Comment By: Don Pinto (dodil) Date: 2008-08-30 15:06 Message: Logged In: YES user_id=1289601 Originator: NO Is changing lastColon = a.indexOf(":"); to lastColon = a.lastIndexOf(":"); a proper fix ? If so, I can submit a patch for this. --Don Pinto ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-25 19:17 Message: Logged In: NO This is in ZooKeeper class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-08-30 19:27:39
|
Patches item #2084339, was opened at 2008-08-30 15:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=2084339&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: java client Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Pinto (dodil) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for 2028321 Initial Comment: Fix for 2028321 - parseAcl method has a bug ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=2084339&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-08-30 19:06:16
|
Bugs item #2028321, was opened at 2008-07-25 19:16 Message generated for change (Comment added) made by dodil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: parseAcl method has a bug Initial Comment: code for finding colons is incorrect. It gets the same colon twice and then considers it a wrong parse private static ArrayList<ACL> parseACLs(String aclString) { ArrayList<ACL> acl; String acls[] = aclString.split(","); acl = new ArrayList<ACL>(); for (String a : acls) { int firstColon = a.indexOf(':'); int lastColon = a.indexOf(':'); if (firstColon == -1 || lastColon == -1 || firstColon == lastColon) { //HERE**** <- first and last colon indexes are always the same**** System.err .println(a + " does not have the form scheme:id:perm"); continue; } ACL newAcl = new ACL(); newAcl.setId(new Id(a.substring(0, firstColon), a.substring( firstColon + 1, lastColon))); newAcl.setPerms(getPermFromString(a.substring(lastColon + 1))); acl.add(newAcl); } return acl; } ---------------------------------------------------------------------- Comment By: Don Pinto (dodil) Date: 2008-08-30 15:06 Message: Logged In: YES user_id=1289601 Originator: NO Is changing lastColon = a.indexOf(":"); to lastColon = a.lastIndexOf(":"); a proper fix ? If so, I can submit a patch for this. --Don Pinto ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-25 19:17 Message: Logged In: NO This is in ZooKeeper class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-08-18 20:13:44
|
Patches item #2057229, was opened at 2008-08-18 02:36 Message generated for change (Comment added) made by akornev You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=2057229&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 9 Private: No Submitted By: fpj (fpj) Assigned to: Nobody/Anonymous (nobody) Summary: Sync + Leader election cleanup Initial Comment: This is a merged port of the patches in JIRAs 2 and 108. ---------------------------------------------------------------------- >Comment By: Andrew Kornev (akornev) Date: 2008-08-18 13:13 Message: Logged In: YES user_id=1926652 Originator: NO +1 committed at revision 177 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=2057229&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-08-18 09:35:55
|
Patches item #2057229, was opened at 2008-08-18 11:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=2057229&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 9 Private: No Submitted By: fpj (fpj) Assigned to: Nobody/Anonymous (nobody) Summary: Sync + Leader election cleanup Initial Comment: This is a merged port of the patches in JIRAs 2 and 108. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=2057229&group_id=209147 |
From: Patrick H. <ph...@gm...> - 2008-08-07 18:43:01
|
An update on the move to Apache: Issue tracking, source control, and mailing lists have been moved to Apache hosting infrastructure: Our Apache homepage can be found at: http://hadoop.apache.org/zookeeper/ Mailing lists are at: http://hadoop.apache.org/zookeeper/mailing_lists.html Please move communication to these lists (the project maintainers are still monitoring conversation on sourceforge mailing lists) Many of the pages on the sourceforge twiki are being converted to a new html/pdf based documentation format. This is in progress. Additionally we will continue to have a wiki hosted on Apache: http://wiki.apache.org/hadoop/ZooKeeper We have not posted an Apache release at this point. Please continue to d/l the latest release (2.2.1) from sourceforge: http://sourceforge.net/project/showfiles.php?group_id=209147 Patrick |
From: SourceForge.net <no...@so...> - 2008-07-25 23:17:09
|
Bugs item #2028321, was opened at 2008-07-25 23:16 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: parseAcl method has a bug Initial Comment: code for finding colons is incorrect. It gets the same colon twice and then considers it a wrong parse private static ArrayList<ACL> parseACLs(String aclString) { ArrayList<ACL> acl; String acls[] = aclString.split(","); acl = new ArrayList<ACL>(); for (String a : acls) { int firstColon = a.indexOf(':'); int lastColon = a.indexOf(':'); if (firstColon == -1 || lastColon == -1 || firstColon == lastColon) { //HERE**** <- first and last colon indexes are always the same**** System.err .println(a + " does not have the form scheme:id:perm"); continue; } ACL newAcl = new ACL(); newAcl.setId(new Id(a.substring(0, firstColon), a.substring( firstColon + 1, lastColon))); newAcl.setPerms(getPermFromString(a.substring(lastColon + 1))); acl.add(newAcl); } return acl; } ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-07-25 23:17 Message: Logged In: NO This is in ZooKeeper class. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-07-25 23:16:20
|
Bugs item #2028321, was opened at 2008-07-25 23:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: parseAcl method has a bug Initial Comment: code for finding colons is incorrect. It gets the same colon twice and then considers it a wrong parse private static ArrayList<ACL> parseACLs(String aclString) { ArrayList<ACL> acl; String acls[] = aclString.split(","); acl = new ArrayList<ACL>(); for (String a : acls) { int firstColon = a.indexOf(':'); int lastColon = a.indexOf(':'); if (firstColon == -1 || lastColon == -1 || firstColon == lastColon) { //HERE**** <- first and last colon indexes are always the same**** System.err .println(a + " does not have the form scheme:id:perm"); continue; } ACL newAcl = new ACL(); newAcl.setId(new Id(a.substring(0, firstColon), a.substring( firstColon + 1, lastColon))); newAcl.setPerms(getPermFromString(a.substring(lastColon + 1))); acl.add(newAcl); } return acl; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=2028321&group_id=209147 |
From: Fernando P. <fe...@al...> - 2008-06-25 17:27:49
|
I'm new to ZooKeeper and learning the recipes, and I got an idea to help implement the lock algorithm, and thought it would be a good start to break the ice. The punchline is that I would like to set a watch for "isFirst", "isLast". So that instead of each client always getting the full list of children ( maybe really large ), just to do sorting and seeing if they hold the first znode in the list.. it just seems like the server should be doing this for the clients. The main questions revolve around the sorting rules.. 1) string or number sorting? If the sort is done only via string id, then it breaks.. because "id_5" doesn't sort correctly with "id_100". The server would have to break out the sequence number and sort by that. - Maybe you can add the sequence number as another stat property. 2) can it support prefix matter? To implement the read/write locking, the prefix matters.. I'm I the first write holder or am I the first read holder, or are there any write holders at the moment? - Maybe getFirst/getLast should be added as extra calls as well, instead of calling getChildren What do you guys think? What would an api look like? |
From: SourceForge.net <no...@so...> - 2008-06-10 22:56:09
|
Patches item #1989049, was opened at 2008-06-09 10:38 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1989049&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: server Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: fpj (fpj) Assigned to: Andrew Kornev (akornev) Summary: Incompatible client server list Initial Comment: This is a patch for request feature: 1937084. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 15:56 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-28 ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-06-10 09:28 Message: Logged In: YES user_id=1926444 Originator: YES Andrew, Could you give me some pointers on how to update the C client to make it work? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1989049&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 22:53:09
|
Patches item #1986201, was opened at 2008-06-06 02:39 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1986201&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: server Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: fpj (fpj) Assigned to: Nobody/Anonymous (nobody) Summary: Vector of Integers (jute) Initial Comment: This patch fixes the problem of creating a vector of integers with jute. Basically, the type of the element of a vector has to be "Integer", and not "int". ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 15:53 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-19 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1986201&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 22:51:54
|
Patches item #1975262, was opened at 2008-05-27 11:03 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1975262&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: server Group: 3.0.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Nobody/Anonymous (nobody) Summary: Server side of the auto reset watches patch Initial Comment: This patch covers the server side of the auto reset watch feature. [ 1831413 ] Auto reset of watches on reconnect It introduces a setWatches message that atomically sets a watch or triggers a watch event depending on the relative zxid for a list of paths. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 15:52 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-43 ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:24 Message: Logged In: YES user_id=154690 Originator: YES The client side patch will be done in connection with [ 1937078 ] Passing a watch object to read requests Once that patch is in the datastructure will be in place to send up the watches that the client is waiting for. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1975262&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 22:50:39
|
Patches item #1970356, was opened at 2008-05-23 04:31 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1970356&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: fpj (fpj) Assigned to: Nobody/Anonymous (nobody) Summary: Change LE default to Fast TCP Initial Comment: This is a very simple change to the default of the leader election implementation to the fast version using TCP. It requires a separate port. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 15:50 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-42 ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-06-10 09:21 Message: Logged In: YES user_id=1926444 Originator: YES I have fetched the latest release, and run the junit tests. It shows no problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1970356&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 22:49:03
|
Patches item #1951806, was opened at 2008-04-25 10:10 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1951806&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 7 Private: No Submitted By: Ted Dunning (tedunning) Assigned to: Mahadev Konar (mahadevkonar) Summary: Sample startup script Initial Comment: This may be useful as a temporary script. Eventually there are several things that should be improved: a) the log rotation hack should go away when real logging get implemented b) the kill hack should go away when there is a good way to kill the process. In the meantime, this may be handy to people at least as a starting point. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 15:49 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-41 ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-29 14:24 Message: Logged In: YES user_id=1926680 Originator: NO the start up scripts will be broken after we remove the log4j file from the zookeeper.jar. I will upload a patch to fix that as a consequence of http://sourceforge.net/tracker/index.php?func=detail&aid=1978290&group_id=209147&atid=1008546 ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-07 11:45 Message: Logged In: YES user_id=1926680 Originator: NO Committed revision 152. committed the patch. Thanks Ben and Ted!! Am not closing the bug -- Ill update the twiki and then close the bug. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-07 11:39 Message: Logged In: YES user_id=154690 Originator: NO +1 make it happen ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-06 15:58 Message: Logged In: YES user_id=1926680 Originator: NO i am uploading a patch that makes log4j configurable in the scripts and also made changes to the script so that it works in the developer environment as well . File Added: log4j_build_script_1.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-06 12:46 Message: Logged In: YES user_id=12853 Originator: NO +1 but should also include update to the wiki to document: a) the commands b) usage, in particular env variables and default expected locations (for example ZOOLIBDIR is bin/../lib + should have all necessary libs, zoo.cfg + log4j.properties are in ZOOCFGDIR, etc...) ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-06 10:43 Message: Logged In: YES user_id=12853 Originator: NO The assignee is responsible for closing (committing) this patch (see ZooKeeperPatches on wiki) -- this includes getting additional review if necessary. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-05 23:22 Message: Logged In: YES user_id=1926680 Originator: NO nice scripts ben... i was supposed to do this ... in http://sourceforge.net/tracker/index.php?func=detail&aid=1958195&group_id=209147&atid=1008544 but looks like this is going to be sufficient. thanks for doing my work :)... (as always) i was surprised to see that readlink is installed by default on cygwin as well. So this should be good enough for cygwin as well. Also, maybe we can add zookeeper.root.logger as a system property which the scripts can set so the lo4j.properties looks like root.Logger = ${zookeeper.root.logger} and make it configurable via the script -Dzookeeper.root.logger=${ZOOKEEPER_ROOT_LOGGER:-INFO,console}" ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-05-05 16:08 Message: Logged In: YES user_id=972206 Originator: YES Much nicer. Thanks. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-05 14:12 Message: Logged In: YES user_id=154690 Originator: NO Okay, I've enhanced your patch a lot Ted. It assumes an installation directory structure of bin, lib, and conf as siblings. It finds the directory based on the realpath of the script being run. (This is how things like firefox and java are setup on Linux usually.) zkServer.sh is designed to be run from init.d zkCleanup.sh is designed to run from cron zkCli.sh is designed to run from a shell. File Added: scripts.patch ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-05-01 15:58 Message: Logged In: YES user_id=972206 Originator: YES Ben, Your comments are good, but this is a place-holder. I would hope that you guys would have something much better soon. a) regarding logging, the logging system should do log rotation and cleanup. Until logging is available in a released version (and I build a log configuration file), I will just do the rotation in this script. It is a placeholder and work-around, after all. b) regarding dirname, please change anything like that you like. It is a good idea. c) regarding zoo.cfg in /etc, I can't comment if that really is a good place or not. If you would like to standardize on that, fine. Perhaps, I should put in a bit of baby logic to look first in /etc/zoo.cfg and then in $ZOO/zoo.cfg. d) regarding zoo.cfg instead of ZOO/zoo.cfg, that is just an error. Thanks for catching it. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-01 15:00 Message: Logged In: YES user_id=154690 Originator: NO Thanx Ted. I think ZOO should be set using dirname $0 Log cleanup shouldn't really be done in the startup scripts right? Finally, I think we should get the config from /etc/zookeeper/zoo.cfg right? In your script you use $ZOO/zoo.cfg and zoo.cfg, but both seem wrong (with the latter more wrong :) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-01 14:20 Message: Logged In: YES user_id=154690 Originator: NO Deleted old version so it was clear what we were reviewing. ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-04-30 10:47 Message: Logged In: YES user_id=972206 Originator: YES Here is an updated script that uses the kill command. I am quite dubious of the wisdom of allowing arbitrary processes anywhere on the net to kill a zookeeper. It definitely means that zookeepers cannot be exposed at all to anything except a very friendly environment. File Added: zookeeper.sh ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-04-29 16:42 Message: Logged In: YES user_id=972206 Originator: YES The kill hack is interesting. Good thing to know about. Kind of a dangerous feature, though. It also requires that I know something about the config or write something clever in the script that turns the config file into the telnet or nc command. The logs I am talking about are the accumulation of what currently comes out of standard output, not the transactional logs. I think that there is an enhancement coming that will use log4J. That would be vastly better than my hack of putting standard out to a file. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-04-29 15:34 Message: Logged In: YES user_id=1926652 Originator: NO A better way to kill a server to send a kill command to the server's client port (the clientPort parameter in zoo.cfg), for example: echo kill|nc localhost 1234 ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-04-25 11:52 Message: Logged In: YES user_id=12853 Originator: NO Ted, be aware that there is also the following to be managed. The "log files" reference are transacitonal log files - not logging log files. "The ZooKeeper server creates snapshot and log files, but never deletes them. The retention policy of the data and log files is implemented outside of the ZooKeeper server. The server itself only needs the latest complete fuzzy snapshot and the log files from the start of that snapshot. The PurgeTxnLog utility implements a simple retention policy that administrators can use." http://zookeeper.wiki.sourceforge.net/ZooKeeperDataFormat ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1951806&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:25:09
|
Bugs item #1985723, was opened at 2008-06-05 11:50 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1985723&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Nobody/Anonymous (nobody) Summary: Improve zk ctor/watcher (state transition) docs Initial Comment: I don't see a succinct doc section on state transition events that are sent to a watcher. (sf search seems to be down so perhaps I missed it). Also need to document the constructor of ZooKeeper class. (missing javadoc) ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:25 Message: Logged In: YES user_id=12853 Originator: YES Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-21 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1985723&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:24:03
|
Bugs item #1981340, was opened at 2008-06-01 08:05 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1981340&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 3.0.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Benjamin Reed (breed) Summary: Child watches are not triggered when the node is deleted Initial Comment: If a client sets a watch on "/foo" with a getChildren("/foo" ...) and "/foo" gets deleted, no watch event is triggered. (Ever.) It could be argued that this is correct behavior since the children did not change, but it can lead to confusion since "/foo" could be recreated and children added and still the watch would not get triggered. (We trace watches by znode instance and deleting and creating "/foo" causes a new znode instance.) The correct behavior should be that when a znode is removed there are three events triggered: parent child watches, znode data watches, and znode child watches. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:24 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-20 ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-06-03 11:44 Message: Logged In: YES user_id=154690 Originator: YES I don't think we want another list, that will just make things more complicated. Option 2 is best since triggerWatch already builds a HashSet that we can simply return. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-06-03 11:27 Message: Logged In: YES user_id=12853 Originator: NO This is going to be a bit more complicated that it seems. Let me know what you think of the following: The server has 2 watcher lists; data & child. Currently watchers are triggered exclusively to one or the other list (all datachanged are on data list, all children changed on child list,etc...) Merely adding a "childwatches.trigger(path, nodedeleted)" to datatree will result in (potentially) two nodedeleted events being sent to a watcher (if client did a exists(path) & getchildren(path) for example). I don't believe we want to do this. There are two options afaict; add a new watch list "deletedNodeWatches" to datatree that contains both data & child watches to be triggered for nodedelete events only, or continue to have 2 lists and filter out any duplicate events during the trigger phase. Adding more lists doesn't seem like a great option. Option 2 would require a change to watchmanager.triggerwatches to return the set of watchers triggered, which would be used to filter out duplicate triggers. pseudo for datatree.deletenode: processedwatches = datawatches.triggerwatches(path, nodedeleted) childwatches.triggerwatches(path, nodedeleted, processedwatches) triggerwatches would be updated to use processwatches parameter to filter out duplicate nodedeleted events from being generated (the child watch would be cleared on the server) Secondly the client (current patch) also has two lists - data and child watches. The client will have to use the same trick -- trigger both data and child watches, eliminate duplicates by uniquely triggering based on path/watcher pairs. (process the data watches, process the child watches filtering out any dups from being generated). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1981340&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:23:02
|
Bugs item #1981288, was opened at 2008-06-01 05:16 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1981288&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: fpj (fpj) Assigned to: Nobody/Anonymous (nobody) Summary: Vector of Integers with Jute Initial Comment: Currently, Jute generates a "List<int>" for the Java code, which is broken. I have tried to simply replace "int" with "Integer" in the third parameter of the call to the constructor of JType. It doesn't seem to work, though. One option would be to hack into JVector, and force it to use the type "Integer" whenever the Jute type is "int". If possible, I'd rather opt for a cleaner option, though. -Flavio ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:23 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-19 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1981288&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:20:17
|
Bugs item #1979772, was opened at 2008-05-30 14:14 Message generated for change (Settings changed) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1979772&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Benjamin Reed (breed) Summary: keeper state inconsistency Initial Comment: I user reported that in the java client KeeperStateChanged seems be be both unused and unusual(shares value with KeeperStateDisconnected) http://sourceforge.net/mailarchive/forum.php?thread_name=0A263CC7-6F54-4978-9F97-4B2E4FD7EE42%40elctech.com&forum_name=zookeeper-user I looked at the history of the watcher.java file - the only log entry is the initial commit by Ben. Assigning to Ben for followup - is this state some artifact and can be removed? Or does it server some purpose - if so we should document in the javadoc. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:20 Message: Logged In: YES user_id=12853 Originator: YES Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-18 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1979772&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:20:09
|
Bugs item #1979772, was opened at 2008-05-30 14:14 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1979772&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Benjamin Reed (breed) Summary: keeper state inconsistency Initial Comment: I user reported that in the java client KeeperStateChanged seems be be both unused and unusual(shares value with KeeperStateDisconnected) http://sourceforge.net/mailarchive/forum.php?thread_name=0A263CC7-6F54-4978-9F97-4B2E4FD7EE42%40elctech.com&forum_name=zookeeper-user I looked at the history of the watcher.java file - the only log entry is the initial commit by Ben. Assigning to Ben for followup - is this state some artifact and can be removed? Or does it server some purpose - if so we should document in the javadoc. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:20 Message: Logged In: YES user_id=12853 Originator: YES Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-18 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1979772&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:18:58
|
Bugs item #1967467, was opened at 2008-05-19 15:05 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1967467&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: c client Group: 3.0.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Andrew Kornev (akornev) Summary: zookeeper_init doc needs clarification Initial Comment: the zookeeper_init document needs to be clarified on two points: 1) that when it returns the client may/maynot have an active session on the server. init call is asyncronous - notification comes back through the watcher when the session is established. 2) this section seems to be wrong. If a client id is invalid (say you pass clientid 1 on a new zk instance) a new session is not created, rather the client's zk handle (when later used) complains that the session is expired. * \param clientid the id of a previously established session that this * client will be reconnecting to. Pass 0 if not reconnecting to a previous * session. If the session timed out or the id is invalid, a new * session will be automatically generated. Clients should check the actual * session id by calling \ref zoo_client_id. Notice that the server message (console) is also misleading - it seems to indicate that the session was reestablished, but in reality is has not. A more clear log message on the server would help here. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:19 Message: Logged In: YES user_id=12853 Originator: YES Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-17 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1967467&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:17:37
|
Bugs item #1963141, was opened at 2008-05-13 07:55 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1963141&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: server Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Nobody/Anonymous (nobody) Summary: Need to do path validation Initial Comment: ZooKeeper needs to do better path validation at the client and server. We need to check for null paths as well as make sure the paths conform to the restrictions in http://zookeeper.wiki.sourceforge.net/ZooKeeperDataModel ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:17 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-16 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1963141&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:15:59
|
Bugs item #1959060, was opened at 2008-05-06 13:58 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1959060&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 3.0.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Patrick Hunt (phunt) Summary: handle failure better in build.xml:test Initial Comment: junit tests should look more like the following which will allow tests to run and build to fail (but all tests will run). <junit haltonfailure="no" fork="yes" errorProperty="tests.failed" failureProperty="tests.failed" ...> ... </junit> <fail if="tests.failed">Tests failed!</fail> ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:16 Message: Logged In: YES user_id=12853 Originator: YES Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-15 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1959060&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:14:37
|
Bugs item #1948097, was opened at 2008-04-21 10:02 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1948097&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: c client Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Benjamin Reed (breed) Summary: Connect timeouts not calculated properly Initial Comment: There should be a better connection between connect timeout, ping timeout, and session timeout. On the Java client it is sessionTimeout/hostsList.length. On the C client it's just the readTimeout. There is also an arbitrary delay when we find that all the hosts are down. We should come up with a good consistent story for the connect timeout. Since we leave sessionTimeout/3 ms for recovery from a down server, it seems most reasonable to have something like sessionTimeout/(3*hostsList.length). ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:14 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-14 ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-05 16:04 Message: Logged In: YES user_id=12853 Originator: NO Assigning to Ben. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1948097&group_id=209147 |
From: SourceForge.net <no...@so...> - 2008-06-10 21:13:07
|
Bugs item #1946934, was opened at 2008-04-19 17:36 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1946934&group_id=209147 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 3.0.0 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: Ted Dunning (tedunning) Assigned to: Mahadev Konar (mahadevkonar) Summary: NPE during normal operations Initial Comment: Somehow, I got my server to do this evil thing. I will try to figure out how to do this more consistently. 4/19/08 5:30:31 PM PDT [FinalRequestProcessor.java@220][8]: ****************************** 11944c2037100d8 256 fffffffffffffffe txn type = unknown getChildren n/a 4/19/08 5:30:31 PM PDT [FinalRequestProcessor.java@227][8]: ffffffff0 4/19/08 5:30:31 PM PDT [FinalRequestProcessor.java@228][8]: : java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.hash(ConcurrentHashMap.java:157) at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:730) at com.yahoo.zookeeper.server.DataTree.getNode(DataTree.java:84) at com.yahoo.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:205) at com.yahoo.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:226) at com.yahoo.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:113) 4/19/08 5:30:49 PM PDT [FinalRequestProcessor.java@220][8]: ****************************** 11944c2037100d8 257 fffffffffffffffe txn type = unknown exists n/a 4/19/08 5:30:49 PM PDT [FinalRequestProcessor.java@227][8]: ffffffff0 4/19/08 5:30:49 PM PDT [FinalRequestProcessor.java@228][8]: : java.lang.NullPointerException at com.yahoo.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:169) at com.yahoo.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:226) at com.yahoo.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:113) ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-06-10 14:13 Message: Logged In: YES user_id=12853 Originator: NO Moved to Apache https://issues.apache.org/jira/browse/ZOOKEEPER-13 ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-05-29 17:53 Message: Logged In: YES user_id=972206 Originator: YES I am pretty sure that I had a null even though it was impossible (in the programming sense). I haven't had this problem since then. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-29 17:21 Message: Logged In: YES user_id=1926680 Originator: NO Ted, just want to check if null path is the only problem here. In your comments you mentioned that null path might not be possible. Can you check to see if this is true -- (in a QA sense -- not a programmer sense)? :) ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-05 16:03 Message: Logged In: YES user_id=12853 Originator: NO Ben looks like you had a handle on this. Please submit a patch. ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-04-22 10:58 Message: Logged In: YES user_id=972206 Originator: YES Good thing then to have found it. My only problem is that by inspection, my code "can't" be sending the null. The usual software engineering definition of "can't" is obviously the one that I mean here. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-04-22 08:34 Message: Logged In: YES user_id=154690 Originator: NO I think your suspicion is correct. (I thought we were handling this.) It's actually a double bug! Both the server and client should check for a null path. ---------------------------------------------------------------------- Comment By: Ted Dunning (tedunning) Date: 2008-04-21 10:35 Message: Logged In: YES user_id=972206 Originator: YES java version "1.5.0_13" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05-241) Java HotSpot(TM) Client VM (build 1.5.0_13-121, mixed mode, sharing) Running on a mac under OSX 10.4 I think actually that this is actually a case of invalid arguments (from me) causing an obscure message rather than being caught. My suspicion is null path passed to create. I still owe you a test case. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-04-21 09:55 Message: Logged In: YES user_id=154690 Originator: NO Which version of Java are you using? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1946934&group_id=209147 |