Menu
▾
▴
zookeeper-developer — Mailing list to discuss development of zookeeper
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: SourceForge.net <no...@so...> - 2008-05-30 00:20:57
|
Bugs item #1946934, was opened at 2008-04-20 00:36 Message generated for change (Comment added) made by mahadevkonar 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: Open 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: Mahadev Konar (mahadevkonar) Date: 2008-05-30 00: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 23: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 17: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 15: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 17: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 16: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 |
|
From: SourceForge.net <no...@so...> - 2008-05-29 21:24:17
|
Patches item #1951806, was opened at 2008-04-25 17:10 Message generated for change (Comment added) made by mahadevkonar 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: Open 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: Mahadev Konar (mahadevkonar) Date: 2008-05-29 21: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 18: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 18:39 Message: Logged In: YES user_id=154690 Originator: NO +1 make it happen ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-06 22: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 19: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 17: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-06 06: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 23:08 Message: Logged In: YES user_id=972206 Originator: YES Much nicer. Thanks. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-05 21: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 22: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 22: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 21: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 17: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 23: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 22: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 18: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-05-29 20:14:05
|
Patches item #1913998, was opened at 2008-03-14 01:52 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1913998&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: Open Resolution: None Priority: 5 Private: No Submitted By: Andrew Kornev (akornev) >Assigned to: Benjamin Reed (breed) Summary: JMX instrumentation Initial Comment: This patch adds support for management and monitoring via JMX. It uses the MXBean feature made available in Java 6. The instrumentation code relies on the new lifecycle event notification mechanism to dynamically register and unregister MBeans. The ant build file has NOT been modified to build this new feature yet. There are no javadocs for the new classes either (but this will be fixed, of course). ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-29 20:14 Message: Logged In: YES user_id=1926680 Originator: NO assigning to ben since he is reviewing the code. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-09 18:34 Message: Logged In: YES user_id=1926652 Originator: YES Fixed compilation errors introduced as a result of [1956480] patch. Now is really a good time to start reviewing this patch. File Added: jmx-4.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-07 18:25 Message: Logged In: YES user_id=1926652 Originator: YES Moved around ManagedZooKeeperServer and ManagedQuorumPeer classes back to the jmx source tree to make it possible to build the src source tree whithout the jmx tree. Now would be a good time to start reviewing this patch. File Added: jmx-3.patch ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-02 01:06 Message: Logged In: YES user_id=1926652 Originator: YES Added javadocs, updated the code to use log4j, moved common classes to the src/ directory tree. File Added: jmx-2.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-03-17 20:44 Message: Logged In: YES user_id=1926680 Originator: NO that is primarily my concern. Meaning if jmx is to be enabled in production then creating an ojbect per connection would deteriorate the scalability of zookeeper. What I mean is that do we actually need per connection management in jmx? or we could have just connection stats in jmx and some other means to debug problems with connections (other than jmx)? ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-03-17 20:14 Message: Logged In: YES user_id=1926652 Originator: YES JMX is primarily for management and monitoring, and my hope is to have JMX enabled in production by default. JMX instrumentation code will eventually rely on the /proc data tree (when it becomes available) to get connection-related information. But we're still gonna have to have a bean per connection registered with MBeanServer. Dynamic registering/unregistering of connection beans may indeed incur some (insignificant) overhead, but I'm not aware of any other way of making a dynamic resource avilable to JMX. ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-03-17 19:50 Message: Logged In: YES user_id=1926680 Originator: NO 3) for this what I meant was that .. we c annot run with jmx on in production .. and if connection tracking is for debugging purpose then jmx just does not sound the right tool for debugging... 4) thats true... but lets have a better process in line :) ... sorry to have started with you. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-03-17 19:23 Message: Logged In: YES user_id=1926652 Originator: YES 1) yes! 2) updated the code to use logError() for logging errors only and logTraceMessage() for logging debug/info. 3) not sure I understand the concern. Connection tracking using /proc FS is orthogonal to JMX. JMX Beans would have to be instantiated for each new connection anyway if we want to be able to manage connections thru JMX. 4) this may take a while. Historically, however, lacking and/or misleading javadocs have never been a showstopper for the existing ZK code ;-) ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-03-15 18:02 Message: Logged In: YES user_id=1926680 Originator: NO 1) dataTreeBean = new com.yahoo.zookeeper.jmx.server.DataTreeBean( + server.dataTree); can we just replace this with DataTreeBean(datatree)? 2) also i wonder if we should have logging levels on the server side like debug and info , warn, fatal right now we just have logerror and logwarn... and we end up using logError for everything .. 3) am really unconfortable with the idea that we keep track of all the connections using jmx beans? I thought we were going to put all this info in the /proc file system? We end up creating a new object connection bean for every connection (as per my understanding) ... 4) can you upload a patch with javadocs? :) Its easier to review :). ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-03-14 17:11 Message: Logged In: YES user_id=1926652 Originator: YES Are you sure it's this patch that has tabs in it? Or, maybe, you meant the other one (the refactoring patch)? Because that one does have tabs (which I've already fixed in locally). But this one does not. Thanks for reviewing! ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-03-14 02:20 Message: Logged In: YES user_id=1926680 Originator: NO this patch has tabs in it... i havent finished reviewing... just getting my review comments out... ill let you know when I am done fully reviewing the patch so that you dont have to upload it again and again. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1913998&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-29 20:13:40
|
Patches item #1944441, was opened at 2008-04-16 23:01 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1944441&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: Fixed Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Mahadev Konar (mahadevkonar) Summary: fix 1941109 -- arraylist -> list<T> in interfaces Initial Comment: fix for 1941109 -- move to more abstract interfaces. arraylist -> list<t> This may require changes to user code. Documentation will need to be updated. ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-29 20:13 Message: Logged In: YES user_id=1926680 Originator: NO I agree that the datatree should not be public and be used by clients. Closing the bug for now. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-20 01:55 Message: Logged In: YES user_id=154690 Originator: NO DataTree is public with respect to Java, but it is not public with respect to the public API of ZooKeeper. No one should be using DataTree directly. Perhaps in the future there may be people that access it, but I don't think it is something we should be worried about now. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-20 00:06 Message: Logged In: YES user_id=1926652 Originator: NO Yes, I mean DataTree.getChildren(). Although, I'm not sure what you meant by "the method is private to zk implementation" (it seems quite public to me), I just thought that if we have changed getACL()'s return type from ArrayList<> to List<> then, for consistency, we should change getChildren()'s, too. Is it possible to fix this as part of this patch? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-19 23:07 Message: Logged In: YES user_id=12853 Originator: YES You mean DataTree.java right? I think it's ok in this case. The method is private to zk implementation -- I updated the public interfaces not necessarily the private ones. Also you can cast the return value to a List easily (not something you can easily do when passing List as argument of type ArrayList). Please enter a bug if you think we should fix. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-19 22:28 Message: Logged In: YES user_id=1926652 Originator: NO Was it your intention to have getChildren returning ArrayList<> and not List<>? public ArrayList<String> getChildren(String path, Stat stat, Watcher watcher) throws KeeperException.NoNodeException ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-19 19:30 Message: Logged In: YES user_id=1926680 Originator: NO committed revision 168. Thanks Pat. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-16 21:41 Message: Logged In: YES user_id=12853 Originator: YES Here's an updated patch. File Added: parameterizedlist2.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-15 21:33 Message: Logged In: YES user_id=1926680 Originator: NO gievn the updates to zookeeper this patch does not apply cleanly. Pat can you upload a new patch for this that applied to the trunk? ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-01 21:30 Message: Logged In: YES user_id=154690 Originator: NO We need to hold this until we start 3.0.0 because of the API breakage. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-01 21:30 Message: Logged In: YES user_id=154690 Originator: NO +1 patch looks good ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-04-17 16:56 Message: Logged In: YES user_id=154690 Originator: NO Can we merge this with 1944401. The purposes overlap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1944441&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-29 20:11:06
|
Patches item #1978290, was opened at 2008-05-29 20:07 Message generated for change (Comment added) made by mahadevkonar You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1978290&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: Mahadev Konar (mahadevkonar) >Assigned to: Patrick Hunt (phunt) Summary: remove log4j prop file from zookeeper.jar Initial Comment: deleting the log4j prop file from the jar. ---------------------------------------------------------------------- >Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-29 20:11 Message: Logged In: YES user_id=1926680 Originator: YES pat can you review it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1978290&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-29 20:07:23
|
Patches item #1978290, was opened at 2008-05-29 20:07 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=1978290&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: Mahadev Konar (mahadevkonar) Assigned to: Mahadev Konar (mahadevkonar) Summary: remove log4j prop file from zookeeper.jar Initial Comment: deleting the log4j prop file from the jar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1978290&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-29 20:02:33
|
Bugs item #1969991, was opened at 2008-05-22 16:15 Message generated for change (Settings changed) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1969991&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: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) >Assigned to: Mahadev Konar (mahadevkonar) Summary: remove log4j.properties from zk.jar Initial Comment: remove log4j config from jar file and instead put conf on classpath in script some users have seen issues with tomcat - seems the default tomcat logging gets screwed up if the log4j.properties is in the jar. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-05-29 13:02 Message: Logged In: YES user_id=12853 Originator: YES Mahadev volunteered to fix this one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1969991&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-28 22:17:22
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) >Assigned to: Benjamin Reed (breed) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-05-28 15:17 Message: Logged In: YES user_id=12853 Originator: NO I updated the patch based on feedback on original. File Added: watcherobj2.patch ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 13:31 Message: Logged In: YES user_id=154690 Originator: YES As far as the implementation goes, we can't do it in the clientcnxn EventThread since only async events go there. The easiest thing would be to do it in finishPacket(). You should probably add members in Packet to hold the Watcher object put it in watches in finishPacket(). ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 13:26 Message: Logged In: YES user_id=154690 Originator: YES 'Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively?' If a create(node) succeeds, that means the node did not exists, which means that getData got a NoNode error, which means that no watch was set. So, you will only see a nodecreated event and it would be delivered to the Watcher of the exists() call. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:48 Message: Logged In: YES user_id=12853 Originator: NO What would you suggest regarding async read requests and watcher registration - we wrap the callback with code that registers the watcher then calls the client callback? I think this would be cleaner than embedding into the clientcnxn EventThread code. What do you think? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:40 Message: Logged In: YES user_id=12853 Originator: NO Hm. I re-read the docs and I'm still a bit confused by your statements regarding watch types. Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively? The watches wiki http://zookeeper.wiki.sourceforge.net/ZooKeeperWatches should really be beefed up with more detail on which event types are generated based on write ops. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:07 Message: Logged In: YES user_id=12853 Originator: NO I'll rework the patch. Regarding the c vs java - I only implemented java due to the category being set to "java client". Perhaps we should add a "client API" category? Or maybe create two requests instead of 1 -- would be better for me since I'm much more familiar with java than C, you could assign to someone better able to execute. :-) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 23:26:21
|
Bugs item #1940659, was opened at 2008-04-11 23:44 Message generated for change (Settings changed) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1940659&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: Closed Resolution: Postponed Priority: 5 Private: No Submitted By: fpj (fpj) Assigned to: fpj (fpj) Summary: Client blocks for 3 minutes on call to socket() Initial Comment: On ClientCnxn.startConnect(), the client blocks for 3 minutes while trying to update the properties of the new socket through the following code: sock.socket().setSoLinger(false, -1); sock.socket().setTcpNoDelay(true); Through testing, I've been able to observe that the client blocks on the call to socket(), and that moving these two after the socket is connected seems to solve the problem. I'm providing a very small patch for this problem. I don't have a good explanation for why this is happening, though. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-04-18 09:49 Message: Logged In: YES user_id=154690 Originator: NO Good job figuring this out! Unfortunately this patches the code that isn't usually followed. Since we are non blocking, usually we go through the finishConnect() path, so the options would not be set correctly. The easiest thing to do might be to put the option setting into primeConnection. ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-04-17 11:38 Message: Logged In: YES user_id=1926444 Originator: YES According to a post on the bug description, "The network code connects a socket to its own loopback interface..." during initialization, and blocking this connection through a firewall would cause a call to socket() to stall. However, a call to socket() after the call to connect() does not seem to block. I suspect that passing an IPv4 address to connect() eliminates the blocking problem if the firewall does not block IPv4 traffic, and the socket initializes correctly. -Flavio ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-04-17 11:25 Message: Logged In: YES user_id=1926444 Originator: YES Link to bug report on a related problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6483406 -Flavio ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-04-15 18:16 Message: Logged In: YES user_id=1926444 Originator: YES I'm attaching the output of jstack when the client hangs on socket, and it shows that some other object as a lock on the socket. -Flavio File Added: stack-trace.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1940659&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 20:31:33
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Patrick Hunt (phunt) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2008-05-27 13:31 Message: Logged In: YES user_id=154690 Originator: YES As far as the implementation goes, we can't do it in the clientcnxn EventThread since only async events go there. The easiest thing would be to do it in finishPacket(). You should probably add members in Packet to hold the Watcher object put it in watches in finishPacket(). ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 13:26 Message: Logged In: YES user_id=154690 Originator: YES 'Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively?' If a create(node) succeeds, that means the node did not exists, which means that getData got a NoNode error, which means that no watch was set. So, you will only see a nodecreated event and it would be delivered to the Watcher of the exists() call. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:48 Message: Logged In: YES user_id=12853 Originator: NO What would you suggest regarding async read requests and watcher registration - we wrap the callback with code that registers the watcher then calls the client callback? I think this would be cleaner than embedding into the clientcnxn EventThread code. What do you think? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:40 Message: Logged In: YES user_id=12853 Originator: NO Hm. I re-read the docs and I'm still a bit confused by your statements regarding watch types. Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively? The watches wiki http://zookeeper.wiki.sourceforge.net/ZooKeeperWatches should really be beefed up with more detail on which event types are generated based on write ops. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:07 Message: Logged In: YES user_id=12853 Originator: NO I'll rework the patch. Regarding the c vs java - I only implemented java due to the category being set to "java client". Perhaps we should add a "client API" category? Or maybe create two requests instead of 1 -- would be better for me since I'm much more familiar with java than C, you could assign to someone better able to execute. :-) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 20:26:37
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Patrick Hunt (phunt) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2008-05-27 13:26 Message: Logged In: YES user_id=154690 Originator: YES 'Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively?' If a create(node) succeeds, that means the node did not exists, which means that getData got a NoNode error, which means that no watch was set. So, you will only see a nodecreated event and it would be delivered to the Watcher of the exists() call. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:48 Message: Logged In: YES user_id=12853 Originator: NO What would you suggest regarding async read requests and watcher registration - we wrap the callback with code that registers the watcher then calls the client callback? I think this would be cleaner than embedding into the clientcnxn EventThread code. What do you think? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:40 Message: Logged In: YES user_id=12853 Originator: NO Hm. I re-read the docs and I'm still a bit confused by your statements regarding watch types. Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively? The watches wiki http://zookeeper.wiki.sourceforge.net/ZooKeeperWatches should really be beefed up with more detail on which event types are generated based on write ops. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:07 Message: Logged In: YES user_id=12853 Originator: NO I'll rework the patch. Regarding the c vs java - I only implemented java due to the category being set to "java client". Perhaps we should add a "client API" category? Or maybe create two requests instead of 1 -- would be better for me since I'm much more familiar with java than C, you could assign to someone better able to execute. :-) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 19:48:48
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Patrick Hunt (phunt) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:48 Message: Logged In: YES user_id=12853 Originator: NO What would you suggest regarding async read requests and watcher registration - we wrap the callback with code that registers the watcher then calls the client callback? I think this would be cleaner than embedding into the clientcnxn EventThread code. What do you think? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:40 Message: Logged In: YES user_id=12853 Originator: NO Hm. I re-read the docs and I'm still a bit confused by your statements regarding watch types. Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively? The watches wiki http://zookeeper.wiki.sourceforge.net/ZooKeeperWatches should really be beefed up with more detail on which event types are generated based on write ops. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:07 Message: Logged In: YES user_id=12853 Originator: NO I'll rework the patch. Regarding the c vs java - I only implemented java due to the category being set to "java client". Perhaps we should add a "client API" category? Or maybe create two requests instead of 1 -- would be better for me since I'm much more familiar with java than C, you could assign to someone better able to execute. :-) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 19:40:39
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Patrick Hunt (phunt) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:40 Message: Logged In: YES user_id=12853 Originator: NO Hm. I re-read the docs and I'm still a bit confused by your statements regarding watch types. Are you saying that if I call getData(node,true) and exists(node,true) and then a subsequent create(node) happens I will get a single watch event of type datachanged for node? I won't see a "datachanged(node)" as well as a "nodecreated(node)", one for each of the read calls respectively? The watches wiki http://zookeeper.wiki.sourceforge.net/ZooKeeperWatches should really be beefed up with more detail on which event types are generated based on write ops. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:07 Message: Logged In: YES user_id=12853 Originator: NO I'll rework the patch. Regarding the c vs java - I only implemented java due to the category being set to "java client". Perhaps we should add a "client API" category? Or maybe create two requests instead of 1 -- would be better for me since I'm much more familiar with java than C, you could assign to someone better able to execute. :-) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 19:07:18
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) >Assigned to: Patrick Hunt (phunt) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Patrick Hunt (phunt) Date: 2008-05-27 12:07 Message: Logged In: YES user_id=12853 Originator: NO I'll rework the patch. Regarding the c vs java - I only implemented java due to the category being set to "java client". Perhaps we should add a "client API" category? Or maybe create two requests instead of 1 -- would be better for me since I'm much more familiar with java than C, you could assign to someone better able to execute. :-) ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 18:24:27
|
Patches item #1975262, was opened at 2008-05-27 11:03 Message generated for change (Comment added) made by breed 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: Open 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: 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-05-27 18:22:34
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Benjamin Reed (breed) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2008-05-27 11:22 Message: Logged In: YES user_id=154690 Originator: YES We do also need to implement this in the C client as well, but for simplicity we should make that a separate patch. We shouldn't add watches to the watches hashmap until we get a successful result back from the server. Otherwise, we might trigger watches for things that the client isn't expecting. There is also a problem with type watch types. In the server we have a watch list for data and child watches. It might be good to keep that same division in the client. (Either way would work though.) a watch on getChildren() can result in a childrenChanged or nodeDeleted watch event. getData() can result in dataChanged or nodeDeleted event. exist() can result in dataChanged, nodeCreated, or nodeDeleted event. getChildren() and getData() will not get nodeCreated events, because non existence is an error condition for those two calls and a watch will not be set. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-27 18:03:40
|
Patches item #1975262, was opened at 2008-05-27 11:03 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=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: Open 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1975262&group_id=209147 |
|
From: Chen Z. <cz...@gm...> - 2008-05-25 15:50:27
|
Hello, I was wondering whether ZooKeeper includes Paxos in its code. Can you tell me which part of the code is about the Paxos? Maybe ZooKeeper may provide a good chance for people to see how to implement Paxos correctly and efficiently. Thank you. |
|
From: SourceForge.net <no...@so...> - 2008-05-23 23:28:37
|
Patches item #1937078, was opened at 2008-04-07 14:21 Message generated for change (Settings changed) made by phunt You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&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: 3.0.0 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Benjamin Reed (breed) Assigned to: Benjamin Reed (breed) Summary: Passing a watch object to read requests Initial Comment: When using a libraries for higher order synchronization primitives it gets hard to coordinate interests in watch events. It would be much more convenient if a Watcher object could be passed to the getData, getChildren, or exists methods. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-22 14:09 Message: Logged In: YES user_id=12853 Originator: NO Here's the patch, assigning to Ben for further review. Please pay particular attention to the handling of state changes - I clear the watch table when we are not sync'd to the server. Verify my workflow. File Added: watcherobj.patch ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 23:18 Message: Logged In: YES user_id=12853 Originator: NO I've implemented this for Java. I overloaded the respective methods with signatures that take watcher object instead of watch boolean. I added new methods rather than replacing -- this maintains b/w compatibility. 1) should I mark the old methods as deprecated or should we just support both method types (newer signature w/ explicit watcher object && old watch boolean which directs to the "global" watcher.) 2) I see this is listed as category "java client" so I'm assuming there is no need for this feature in c code interface. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-20 17:52 Message: Logged In: YES user_id=12853 Originator: NO I was specifically referring to the client api, not the protocol -- should I assume that that last watcher on a particular node "wins". What I mean is if a client calls "getChildren(path, watcherobj1); getChildren(path, watcherobj2);" (notice same patch) what should the client lib do? I'm assuming use the last watcher, but wanted to verify. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-19 19:05 Message: Logged In: YES user_id=154690 Originator: YES The client will need to track the multiple watcher objects to invoke when it gets the callback. The client server protocol doesn't change, this is just a client side thing. We should add the ability to remove watches as a separate feature request. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-14 00:21 Message: Logged In: YES user_id=12853 Originator: NO What should we do if the user calls getData multiple times with different watcher objects? Remove previous watch and replace with new watcher, throw error, or allow multiple watchers on particular node? How about removing a watch by calling method on particular node with null watcher? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1937078&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-23 11:31:32
|
Patches item #1970356, was opened at 2008-05-23 13:31 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=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: Open 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1970356&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-23 08:56:07
|
Bugs item #1941629, was opened at 2008-04-14 02:02 Message generated for change (Settings changed) made by fpj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1941629&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: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: fpj (fpj) Summary: NPE on startup Initial Comment: I got this in my logs just now: 4/13/08 4:58:28 PM PDT [ClientCnxn.java@623][13]: Trying to connect to localhost/127.0.0.1:8181 4/13/08 4:58:28 PM PDT [ClientCnxn.java@544][13]: Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:60651 remote=localhost/127.0.0.1:8181] Exception in thread "EventThread" java.lang.NullPointerException at com.yahoo.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:253) It didn't seem to affect subsequent operation, but it probably shouldn't be happening (or should be caught). ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-05-06 01:44 Message: Logged In: YES user_id=1926444 Originator: NO Patrick, you're right, looks like the same as 1956937. I'll work on the patch. -Flavio ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-06 01:02 Message: Logged In: YES user_id=12853 Originator: NO Flavio can you look at this, looks like the same as 1956937. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1941629&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-23 08:54:09
|
Bugs item #1940659, was opened at 2008-04-12 08:44 Message generated for change (Settings changed) made by fpj You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1940659&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: Postponed Priority: 5 Private: No Submitted By: fpj (fpj) Assigned to: fpj (fpj) Summary: Client blocks for 3 minutes on call to socket() Initial Comment: On ClientCnxn.startConnect(), the client blocks for 3 minutes while trying to update the properties of the new socket through the following code: sock.socket().setSoLinger(false, -1); sock.socket().setTcpNoDelay(true); Through testing, I've been able to observe that the client blocks on the call to socket(), and that moving these two after the socket is connected seems to solve the problem. I'm providing a very small patch for this problem. I don't have a good explanation for why this is happening, though. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-04-18 18:49 Message: Logged In: YES user_id=154690 Originator: NO Good job figuring this out! Unfortunately this patches the code that isn't usually followed. Since we are non blocking, usually we go through the finishConnect() path, so the options would not be set correctly. The easiest thing to do might be to put the option setting into primeConnection. ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-04-17 20:38 Message: Logged In: YES user_id=1926444 Originator: YES According to a post on the bug description, "The network code connects a socket to its own loopback interface..." during initialization, and blocking this connection through a firewall would cause a call to socket() to stall. However, a call to socket() after the call to connect() does not seem to block. I suspect that passing an IPv4 address to connect() eliminates the blocking problem if the firewall does not block IPv4 traffic, and the socket initializes correctly. -Flavio ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-04-17 20:25 Message: Logged In: YES user_id=1926444 Originator: YES Link to bug report on a related problem: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6483406 -Flavio ---------------------------------------------------------------------- Comment By: fpj (fpj) Date: 2008-04-16 03:16 Message: Logged In: YES user_id=1926444 Originator: YES I'm attaching the output of jstack when the client hangs on socket, and it shows that some other object as a lock on the socket. -Flavio File Added: stack-trace.txt ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1940659&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-22 23:15:26
|
Bugs item #1969991, was opened at 2008-05-22 16:15 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=1969991&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: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Patrick Hunt (phunt) Summary: remove log4j.properties from zk.jar Initial Comment: remove log4j config from jar file and instead put conf on classpath in script some users have seen issues with tomcat - seems the default tomcat logging gets screwed up if the log4j.properties is in the jar. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008544&aid=1969991&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-20 01:57:14
|
Patches item #1963584, was opened at 2008-05-13 22:56 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1963584&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: Open Resolution: None Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Benjamin Reed (breed) Summary: fix build.xml cobertura test harness Initial Comment: Need to fail if the junit tests fail - missing fail is causing build to be successful even if cobertura fails. (ci is running cobertura and not std test target) ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2008-05-19 18:57 Message: Logged In: YES user_id=154690 Originator: NO Is this really enough? It will still show up as unstable build if there are error messages printed even though it returns successfully. Right? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-16 10:44 Message: Logged In: YES user_id=12853 Originator: YES Ben please merge this asap to address ci issue. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1963584&group_id=209147 |
|
From: SourceForge.net <no...@so...> - 2008-05-20 01:55:35
|
Patches item #1944441, was opened at 2008-04-16 16:01 Message generated for change (Comment added) made by breed You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1944441&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: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Patrick Hunt (phunt) Assigned to: Mahadev Konar (mahadevkonar) Summary: fix 1941109 -- arraylist -> list<T> in interfaces Initial Comment: fix for 1941109 -- move to more abstract interfaces. arraylist -> list<t> This may require changes to user code. Documentation will need to be updated. ---------------------------------------------------------------------- >Comment By: Benjamin Reed (breed) Date: 2008-05-19 18:55 Message: Logged In: YES user_id=154690 Originator: NO DataTree is public with respect to Java, but it is not public with respect to the public API of ZooKeeper. No one should be using DataTree directly. Perhaps in the future there may be people that access it, but I don't think it is something we should be worried about now. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-19 17:06 Message: Logged In: YES user_id=1926652 Originator: NO Yes, I mean DataTree.getChildren(). Although, I'm not sure what you meant by "the method is private to zk implementation" (it seems quite public to me), I just thought that if we have changed getACL()'s return type from ArrayList<> to List<> then, for consistency, we should change getChildren()'s, too. Is it possible to fix this as part of this patch? ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-19 16:07 Message: Logged In: YES user_id=12853 Originator: YES You mean DataTree.java right? I think it's ok in this case. The method is private to zk implementation -- I updated the public interfaces not necessarily the private ones. Also you can cast the return value to a List easily (not something you can easily do when passing List as argument of type ArrayList). Please enter a bug if you think we should fix. Thanks. ---------------------------------------------------------------------- Comment By: Andrew Kornev (akornev) Date: 2008-05-19 15:28 Message: Logged In: YES user_id=1926652 Originator: NO Was it your intention to have getChildren returning ArrayList<> and not List<>? public ArrayList<String> getChildren(String path, Stat stat, Watcher watcher) throws KeeperException.NoNodeException ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-19 12:30 Message: Logged In: YES user_id=1926680 Originator: NO committed revision 168. Thanks Pat. ---------------------------------------------------------------------- Comment By: Patrick Hunt (phunt) Date: 2008-05-16 14:41 Message: Logged In: YES user_id=12853 Originator: YES Here's an updated patch. File Added: parameterizedlist2.patch ---------------------------------------------------------------------- Comment By: Mahadev Konar (mahadevkonar) Date: 2008-05-15 14:33 Message: Logged In: YES user_id=1926680 Originator: NO gievn the updates to zookeeper this patch does not apply cleanly. Pat can you upload a new patch for this that applied to the trunk? ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-01 14:30 Message: Logged In: YES user_id=154690 Originator: NO We need to hold this until we start 3.0.0 because of the API breakage. ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-05-01 14:30 Message: Logged In: YES user_id=154690 Originator: NO +1 patch looks good ---------------------------------------------------------------------- Comment By: Benjamin Reed (breed) Date: 2008-04-17 09:56 Message: Logged In: YES user_id=154690 Originator: NO Can we merge this with 1944401. The purposes overlap. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1008546&aid=1944441&group_id=209147 |
