[
https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12616413#action_12616413
]
james strachan commented on ZOOKEEPER-78:
-----------------------------------------
Thanks for the great comments Benjamin! Have already [added the constructor for
you|https://svn.apache.org/repos/asf/activemq/sandbox/zookeeper/zookeeper-protocols/src/main/java/org/apache/zookeeper/protocols/WriteLock.java]
:)
BTW I was pondering about switching the whenOwner from a Runnable to some kinda
interface that invokes you when you become the leader/owner - or when you stop
being the leader/owner. Something like
{code}
public interface WhenOwnerListener {
void whenOwner();
void whenNotOwner();
}
{code}
Where only znodes that are the owner would be notified with the whenOwner()
method; but then if a connection fails or session times out, they'd be notified
with a call to whenNotOwner();
Spookily - I'd set myself the target today to properly implement the watches so
that WriteLock gets a notification of it no longer being the leader/owner when
a connection fails (which normally auto-reconnects anyway right now in the base
ZooKeeper). Then I was gonna add a notification mechanism so we could notify
the leader/owner is no longer the leader/owner when the session expired
exception occurs.
So we're absolutely on the same page; once I'd grokked the proper watch code
for dealing with normal connection failures & reconnects I was hoping to add
something vaguely similar to the ZooKeeperFacade so that higher level protocols
can be aware of both when ZooKeeper reconnects and when ZooKeeperFacade creates
a whole new connection.
Does that make sense? I totally understand your concerns at making sure the
WriteLock and associated helper classes like ProtocolSupport/ZooKeeperFacade do
the right thing - I want exactly the same thing :) I'd just not yet had the
chance to go through all the different failure conditions and scenarios and
make sure they all work properly :)
> added a high level protocol/feature - for easy Leader Election or exclusive
> Write Lock creation
> -----------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-78
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78
> Project: Zookeeper
> Issue Type: New Feature
> Components: java client
> Affects Versions: 3.0.0
> Reporter: james strachan
> Attachments: patch_with_including_Benjamin's_fix.patch,
> using_zookeeper_facade.patch
>
>
> Here's a patch which adds a little WriteLock helper class for performing
> leader elections or creating exclusive locks in some directory znode. Note
> its an early cut; am sure we can improve it over time. The aim is to avoid
> folks having to use the low level ZK stuff but provide a simpler high level
> abstraction.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.