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
Specifying the client port address/nic is part of 3.3.0:
https://issues.apache.org/jira/browse/ZOOKEEPER-635
However this is only for client port, not for the quorum ports. FF to
enter a JIRA if you would like to see that as well.
Patrick
César Álvarez Núñez wrote:
Hi all,
I'm testing Zooke
Hi all,
I'm testing Zookeeper with an ensemble where one of the nodes has two
network interfaces (lan and wifi).
That node is listening on both interfaces for all ports: Client, Following
and Leader Election.
Does exist some way to specify which network interface should be used?
BR,
/César.
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
