9:20 a.m.
On Jan 8, 2010, at 3:13 PM, Manik Surtani wrote:
On 8 Jan 2010, at 13:05, Mircea Markus wrote:
>>
>> 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?
Well, any form of notification beyond keys would be much too expensive. Although this
can be hidden from the user by using a proxy Event object which has a key but lazily loads
the value when Event.getValue() is invoked.
Not sure I get this. Why would be a view
change notification more expensive than the key one?
Re: the global scope of events, this is important/interesting.
Client ----> ServerA, ServerB, ServerC ... Server Z
Assuming the client has a connection to A, and registers interest in keys k1... k3, you
are correct that ServerA would only be aware of changes on keys located on ServerA and not
globally. Solutions may be that ServerA acts as a proxy for the Client and registers for
events on other servers on the clients' behalf? No simple answers here I'm
afraid...
(this sort of oot)
I'm thinking of an more advanced feature here, that would also enable us to support
Complex Event Processing [1] and continuos query: build-in notification support for key
changes.
E.g. cache.registerKeyChangeListener("a*", listenerInstance);
this is a pseudo-cod, the idea is that the user will be notified whenever an key starting
with "a" (e.g. "a1", "aries") is added/updated/modified, on
ANY node of the cluster (v.s. the current node, which is currently supported).
Implementing this would mean that the consistent hashing function on all nodes should be
aware of all these listeners, and , for each altered key they should notify the
corresponding listener about the change (do a push to the node where the listener is
installed).
This would perfectly fit the following use case:
An application that needs to query a huge data set very often (e.g. 100 times a second).
Instead of running the query each time, we run it once, cache the result, and register as
a listener for possible changes of the queried keys. Whenever the cluster listener is
notified, it updates the query result.
[1] http://en.wikipedia.org/wiki/Complex_event_processing
[2] http://wiki.tangosol.com/display/COH31UG/Continuous+Query
Cheers
--
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