On Jan 6, 2009, at 6:55 PM, Kevin Burton wrote:
In case 1), if you are proposing to overwrite the content of the
then you would need first to make sure that all receivers have
received the previous message. This doesn't seem a good solution to
because a client that wants to broadcast a message would have to
all others flag that they have received the previous message.
messages to the current content of the znode doesn't seem a great
either because clients would have to make sure that they are
It's not good for all situations... we have a daemon state file
and it works well for this use case.
Also the throughput here is very low.
Sorry, I missed which version of my description you're using. Are you
overwriting or appending? Or perhaps doing something else?
Solution 2) sounds better to me because it is wait-free: no client
to broadcast a message contends with other clients. Now, as you
have to use the sequence flag to make sure that all messages are
in the same order (if you want total order). You may still want to
mechanism for clients to flag which messages they have already
that you remove messages that everyone has already delivered. If your
application generates a large number of messages and you don't
you might end up with an unnecessarily large number of znodes.
not sure why you want to use ephemeral znodes for messages. I think
ephemeral znodes may cause you trouble in this case. Suppose that a
broadcasts a message by creating an ephemeral znode and crashes
other clients deliver the message. You may end up with two clients
delivering different sequences of messages.
But you would need a cleanup mechanism if they weren't ephemeral...
As we currently have ephemerals, you need a cleanup mechanism anyway,
unless you kill the sessions of all broadcasters.
Of course if ephemeral nodes weren't necessarily session based and
had a TTL
value that would solve this problem.
I don't find the idea of having nodes existing on a TTL basis
unreasonable, but I don't think it should be a replacement for our
current ephemeral nodes. As we have it currently is certainly useful.
I do find, though, difficult in general to select such TTL values, but
I can see that this is an arguable point. Perhaps some requirement of
your application makes it easy to select such values.
In any case, I believe you can emulate such a TTL behavior by killing
a session after some amount of time.
Location: San Francisco, CA