[infinispan-dev] Hot Rod - pt3

[Mircea Markus]

On Jan 11, 2010, at 3:18 PM, Manik Surtani wrote:

> 
> On 8 Jan 2010, at 15:20, Mircea Markus wrote:
> 
>> 
>> 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.
> 
> A good way to deal with CEP/Continuous Queries in an efficient manner is to use Drools, rather than reinvent stuff here.  Mark Proctor and I have had many a conversation around this, but time and bandwidth constraints always kick in ... :)
Don't know too much about drools, I'll take a look.
> 
>> 
>> 
>> [1] http://en.wikipedia.org/wiki/Complex_event_processing
>> [2] http://wiki.tangosol.com/display/COH31UG/Continuous+Query
>>> 
>>> Cheers
>>> --
>>> 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
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> 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