javadoc for the Write Lock / Leader Election

2008-07-18 Thread James Strachan
The other thread was already quite big and covering a large range of issues so thought I'd spin up a little separate thread :) I've just updated the patch to include better javadoc which is linked to an embedded HTML documentation describing the protocol. The documention includes the pseudocode

javadoc for the Write Lock / Leader Election

2008-07-18 Thread James Strachan
The other thread was already quite big and covering a large range of issues so thought I'd spin up a little separate thread :) I've just updated the patch to include better javadoc which is linked to an embedded HTML documentation describing the protocol. The documention includes the pseudocode

RE: javadoc for the Write Lock / Leader Election

2008-07-18 Thread Flavio Junqueira
Hi James, the fact that the client's node has another node n ahead of it the in the sequence order doesn't mean that the owner of n is aware that it is the lock holder or the leader. This is because operations are propagated asynchronously. Also, a getChildren() doesn't guarantee that you have the

Re: javadoc for the Write Lock / Leader Election

2008-07-18 Thread James Strachan
Thanks for the clarification. I think it makes lots of sense for the leader to write to some canonical place to advertise itself; if others are interested in knowing if it is the leader 2008/7/18 Flavio Junqueira [EMAIL PROTECTED]: Hi James, the fact that the client's node has another node n

[jira] Updated: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation

2008-07-18 Thread james strachan (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan updated ZOOKEEPER-78: Attachment: (was: writeLock_protocol_with_documentation-version2.patch) added a

[jira] Updated: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation

2008-07-18 Thread james strachan (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] james strachan updated ZOOKEEPER-78: Attachment: (was: writeLock_protocol.patch) added a high level protocol/feature -

[jira] Commented: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation

2008-07-18 Thread james strachan (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614748#action_12614748 ] james strachan commented on ZOOKEEPER-78: - BTW I just deleted the other 2 patches

Re: An interest in increasing the DI'ness of ZooKeeper?

2008-07-18 Thread James Strachan
+1 :) I'm a fellow ActiveMQ hacker too and would love to see ZK included with ActiveMQ. Dependency Injection can really help keep your code simple but leaving it flexible so it can be used in many different ways. Here's some links on DI http://martinfowler.com/articles/injection.html

[jira] Updated: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent

2008-07-18 Thread Hiram Chirino (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-81: --- Attachment: ZOOKEEPER-81.patch attaching patch for the fix. JMX module is using 1 java 6

[jira] Created: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent

2008-07-18 Thread Hiram Chirino (JIRA)
JMX module is using 1 java 6 method that has a java 5 equivalent Key: ZOOKEEPER-81 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-81 Project: Zookeeper Issue Type:

[jira] Updated: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent

2008-07-18 Thread Hiram Chirino (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hiram Chirino updated ZOOKEEPER-81: --- Status: Patch Available (was: Open) {code} Index:

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent

2008-07-18 Thread Mahadev konar (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614780#action_12614780 ] Mahadev konar commented on ZOOKEEPER-81: i think the build.xml only allows

auto-reconnection ZooKeeper proxy?

2008-07-18 Thread James Strachan
background I work on the ActiveMQ project which implements the JMS API - which is a kinda complex thing but it involves a number of objects (Connections, Sessions, Producers, Consumers). In some JMS providers its the end users responsibility to deal with detecting a connection failure (from any

[jira] Commented: (ZOOKEEPER-81) JMX module is using 1 java 6 method that has a java 5 equivalent

2008-07-18 Thread Andrew Kornev (JIRA)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614787#action_12614787 ] Andrew Kornev commented on ZOOKEEPER-81: The JMX instrumentation code relies on

Re: An interest in increasing the DI'ness of ZooKeeper?

2008-07-18 Thread Hiram Chirino
Yep, I've looked that the test cases. In short to make that public API more DI friendly, we should: * Decouple the current configuration system from the public API. I see stuff like ZooKeeperServer being coupled to ServerConfig a bit. * Allow the use of setter injection in addition to

Re: An interest in increasing the DI'ness of ZooKeeper?

2008-07-18 Thread Hiram Chirino
Yeah mainly. Ideally only your main class deals with configuration parsing and it constructs all the zk server objects using the public api which is DI friendly. For example, I think we should move the main() method out of the ZooKeeperServer class. On Fri, Jul 18, 2008 at 1:11 PM, Benjamin

Re: An interest in increasing the DI'ness of ZooKeeper?

2008-07-18 Thread Benjamin Reed
This sounds great. I would suggest opening a Jira to work out the proposal and track the patch. ben Hiram Chirino wrote: Yep, I've looked that the test cases. In short to make that public API more DI friendly, we should: * Decouple the current configuration system from the public API. I

Re: Recipe contrib -- was Re: [PATCH] a simple Leader Election or exclusive Write Lock protocol/policy

2008-07-18 Thread Benjamin Reed
Some initial implementations of a recipe may only be in C, so it would be nice to have a standard way of finding the recipe that wasn't dependent on the language that implements the recipe. ben James Strachan wrote: 2008/7/17 Benjamin Reed [EMAIL PROTECTED]: Excellent proposal. The only