Re: [infinispan-dev] Hot Rod - pt3

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.

<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(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev