[infinispan-dev] Design of Remote Hot Rod events

[Radim Vansa]

On 11/19/2013 09:48 AM, Emmanuel Bernard wrote:
> Hey there,
>
> Here are a few comments based on a quick reading.
> I might have totally misread or misinterpreted what was exposed, feel
> free to correct me.
>
> ## General
>
> I think you are restricting the design to listeners:
>
> * that only listen to raw entry changes
> * whose processing is remote
> * with no way to filter out the event from the server
>
> Is that correct? I can see that it does address the remote L1 use case
> but I feel like it will close the doors to many more use cases. An
> interesting example being continuous query.
Please, use the term "near cache" rather than "remote L1". L1 is rather 
ambiguous as it already represents L1 cache and L1 HotRod intelligence 
level.

>
> In that use case the listener code runs a filtering logic server side
> and only send keys that are impacted by the query plus some flag
> defining whether it's added to changed or removed from the corpus.
> The key is filtering event before sending it to the client.
>
> I wish the design document was showing how we can achieve a general
> purpose remote listener approach but have a step 1 that is only
> targeting a restricted set of listeners if you feel that it's too much
> to chew. I don't want us to be trapped in a situation where backward
> compatibility prevent us from adding use cases.
I was also suggesting that listener on particular key should be 
mandatory requirement. However, any general server-side filtering logic 
would be hard to specify as HotRod is language-unaware binary protocol. 
Therefore, the best you could get is some kind of binary regular 
expressions. For the start, global/one-key filtering is a good start and 
the door are not closed for any further options.

>
> ## Specific questions
>
> When the topology changes, it is the responsibility of the client to add
> the listener to the new servers that show up. Correct? The API is a
> global addRemoteListener but I imagine the client implementation will
> have to transparently deal with that.
> I wonder if a server approach is not more convinient. At least it does
> not put the burden and bugs in several implementations and several
> languages.
+1
>
> You never send code at the moment. Only one kind of listener is
> available and listeners to all entry change and deletion. Correct?
>
> Why not have the ability to listen to new entry events? That would limit
> generic listeners as it is.
>
> Do you have plans to make the ACK optional depending on the listener
> requirement? Looks like an expensive process.
>
> "Only the latest event is tracked for ACK for a given key"
> It seems it's fine for L1 but would be a problem for many more generic
> listeners.
>
> Emmanuel

Radim

>
> On Tue 2013-11-12 16:17, Galder Zamarreño wrote:
>> Hi all,
>>
>> Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
>>
>> I've just finished writing up the Hot Rod remote events design document. Amongst many other use cases, this will enable near caching use cases with the help of Hot Rod client callbacks.
>>
>> Cheers,
>> --
>> Galder Zamarreño
>> galder at redhat.com
>> twitter.com/galderz
>>
>> Project Lead, Escalante
>> http://escalante.io
>>
>> Engineer, Infinispan
>> http://infinispan.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


-- 
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA