On Jan 6, 2009, at 6:55 PM, Kevin Burton wrote:
Advertising
In case 1), if you are proposing to overwrite the content of the
znode,
then you would need first to make sure that all receivers have
already
received the previous message. This doesn't seem a good solution to
me
because a client that wants to broadcast a message would have to
wait until
all others flag that they have received the previous message.
Appending new
messages to the current content of the znode doesn't seem a great
solution
either because clients would have to make sure that they are
overwriting the
correct version.
It's not good for all situations... we have a daemon state file
we're using
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
willing
to broadcast a message contends with other clients. Now, as you
say, you
have to use the sequence flag to make sure that all messages are
delivered
in the same order (if you want total order). You may still want to
have a
mechanism for clients to flag which messages they have already
delivered so
that you remove messages that everyone has already delivered. If your
application generates a large number of messages and you don't
remove them,
you might end up with an unnecessarily large number of znodes.
Finally, I'm
not sure why you want to use ephemeral znodes for messages. I think
that
ephemeral znodes may cause you trouble in this case. Suppose that a
client
broadcasts a message by creating an ephemeral znode and crashes
before all
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.
-Flavio
Kevin
--
Founder/CEO Spinn3r.com
Location: San Francisco, CA
AIM/YIM: sfburtonator
Skype: burtonator
Work: http://spinn3r.com
