Hmm,
Thanks Ted. I am going to have to do some more reading.
regards,
Martin
On 25 February 2010 19:11, Ted Dunning wrote:
> Not really. You have ordering guarantees and you can avoid the whole mess
> by using the version numbers when you update the file. See my other email.
>
> On Thu, Feb
Not really. You have ordering guarantees and you can avoid the whole mess
by using the version numbers when you update the file. See my other email.
On Thu, Feb 25, 2010 at 2:50 AM, Martin Waite wrote:
> But to do this, would I need to call sync between steps 2 and 3 to ensure
> the node "FN" w
That is one of the strengths of ZK. Your client would do this:
1) create node, if success client has lock
2) get current node (you get the current version when you do this), if lease
is current and ours, we have the lock, if lease is current and not ours, we
have failed to get the lock
3) try to
Hi,
Another possible approach:
1. client generates hash code to be locked. use the first N hex digits
(eg. first 2 digits) as a filename "FN".
2. attempt to create (ephemeral) node "FN.lock". loop until this
succeeds, or abort when time budget exhausted.
3. read node "FN" contain
Hi
Usually, this would hold about 2k items, pushing to 10k peaks.
My current understanding is that I cannot lock a node while I consider its
contents, and so only the garbage remover would be allowed to remove locks
(currently lock-clients can claim expired locks).
The clients would simply do th
You can simply implement the current system if you like by keeping a file
per card in ZK that contains your lock expiration time. The garbage
collector would work the same way. In order to make the getchildren
operation in the garbage collector work well, I would recommend a
hierarchical naming s
Not sure if there is a jira on this but I have long been lobbying the
team to add a new API/feature that allows clients to get a view of the
"global clock". I think this would be a very useful (although admittedly
potentially damaging) feature to add, esp around leases. If we think
leases are s
I am not sure if I was clear enoguh in my last message.
What is suggested was this:
Create a client with a timeout of lets say 10 seconds!
Zookeeper zk = new ZooKeeper(1); (for brevity ignoring other parameters)
Zk.create("/parent/ephemeral", data, EPEMERAL);
//create a another thread that
Hi Henry,
I can appreciate your concerns about clocks, but there are no safety issues
with our system. If locks are held for a few seconds too long, no-one will
be concerned.
I am currently looking at moving two locking mechanisms from within a SQL
database into a distributed locking mechanism o
Hi Mahadev,
That is interesting. All I need to do is hold the connection for the
required time of a session that created an ephemeral node.
Zookeeper is an interesting tool.
Thanks again,
Martin
On 24 February 2010 17:00, Mahadev Konar wrote:
> Hi Martin,
> There isnt an inherent model for
A cautionary note with this problem - who says when 2 minutes is up? Clocks
will go forward at different rates and with different offsets. You cannot
rely on two machines having the same perception of what 2 minutes means. In
general, in distributed systems, it's a good design principle to minimise
Hi Martin,
There isnt an inherent model for leases in the zookeeper library itself.
To implement leases you will have to implement them at your application side
with timeouts triggers (lease triggers) leading to session close at the
client.
Thanks
mahadev
On 2/24/10 3:40 AM, "Martin Waite" w
12 matches
Mail list logo
