On Jan 6, 2009, at 6:55 PM, Kevin Burton wrote:


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

Reply via email to