zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Flavio Junqueira <...@yahoo-inc.com>
Subject Re: group messaging, empheral nodes on zookeeper
Date Tue, 06 Jan 2009 18:14:06 GMT

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.


> Kevin
> -- 
> Founder/CEO Spinn3r.com
> Location: San Francisco, CA
> AIM/YIM: sfburtonator
> Skype: burtonator
> Work: http://spinn3r.com

View raw message