[infinispan-dev] Hot Rod - pt3

[Mircea Markus]

On Jan 5, 2010, at 12:04 PM, Manik Surtani wrote:

> 
> On 5 Jan 2010, at 09:52, Galder Zamarreno wrote:
> 
>> 
>> 
>> On 01/04/2010 10:44 PM, Alex Kluge wrote:
>>>>> - No events. I used events, that is asynchronous messages originating
>>>>>   from the server when certain conditions are met, to notify clients
>>>>>   that data was written to the server.  This was mostly driven by the
>>>>>   need to notify an L1 cache of a write to the cache server. It would
>>>>>   be good to allow for this usage in this protocol. Note that this is
>>>>>   another case where the op code is useful to have as part of the
>>>>>   message.
>>>> 
>>>> Isn't this expensive?  Doesn't this mean the server
>>>> has to fire off messages to each and every connected client,
>>>> whether the clients are interested in these messages or
>>>> not?
>>> 
>>>  Not necessarily. There are a number of options. It wouldn't be
>>>  difficult to allow the clients to register for the events, and
>>>  then only send them to the interested clients. The events can
>>>  be sent asynchronously (a separate thread), thus they won't
>>>  delay the response to a write. Piratically speaking, they aren't
>>>  that expensive.
>> 
>> I'm still not convinced by this either. What you're talking about sounds 
>> like JMS to me :). Right now, the only situation where I can see this 
>> being useful is for sending back cluster formation changes but we found 
>> simpler way to deal with it and that doesn't require the added complexity.
> 
> I think eventing is pretty important.  Especially if clients decide to add a further layer of client-side caching to prevent network lookups.
> 
> I can see how they can be abused to form a JMS-like message-passing layer, but then a lot of stuff could be open to abuse.  Perhaps the events should just be restricted to notifying when a key has changed (i.e., a bit like Invalidation) but with no values/payload passed on, forcing the client to do a GET if the value was required.
Once we have the server->client notification mechanism working IMO we should allow the user to decide which notifications he wants to listen to, and not be restrictive about it. Re:key change notifications, I'm not sure that will work with the current ISP architecture: right now the notifications are local, i.e. one will only be notified by the keys changed in the local cache. So if a used want to be notified when the "account" key changed, that will only happen if he is connected to the server on which the "account" key was hashed.  Even more, if he will connect to another server, which contains "account", the notification behavior might be different, which might be confusing.  
Not a protocol design expert, but is it common for this "push" approach for protocols? 
>  
> 
> <SNIP />
> 
>>>  In my implementation I have a size attached to each field, and this
>>> allows the messages to be handled easily. I retrieve more data from
>>> the network if there is not enough data to complete the processing of
>>> a field. There is no need to know the size of the full message.
>> 
>> I borrowed the idea from the memcached binary protocol, but you have a a 
>> good point. I'll revisit the model to include size together with each field.
>> 
>> Finally, I've noted that you add cache name in the requests. This is 
>> interesting because until now, I had thought of a Hot Rod server to map 
>> 1 to 1 to a cache, but if you add the cache name, you can map 1 Hot Rod 
>> server to a Cache manager and the cache allows you to direct requests to 
>> different caches under the same cache manager.
> 
> I think this makes sense, since you reduce the overhead of a cache server per cache.  Would be divergent from the memcached server design though (as we wouldn't be able to change the memcached server to add cache name to requests)
> 
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20100108/66090004/attachment-0002.html