[infinispan-dev] Design of Remote Hot Rod events - round 2

[Radim Vansa]

Hi,

1) IMO, filtering for specific key is a very important use case. 
Registering a filterId is a very powerful feature, but as long as you 
don't provide runtime parameter for this filter, you cannot implement 
one-key filtering.

2) setting ack/no ack in listener, and then configuring server-wise 
whether you should ack each / only last event sounds weird. I'd replace 
the boolean with enum { NO_ACK, ACK_EACH, ACK_LAST }.

3) should the client provide source id when registering listener or when 
starting RemoteCacheManager? No API for that.

4) clustered events design does not specify any means to replicating the 
clustered event listener - all it does is that you register the listener 
on one node and the other nodes then route events to this node, until 
the node dies/deregisters the listener. No replication. Please specify, 
how should it piggyback on clustered events, and how should the listener 
list be replicated.

5) non-acked events: how exactly do you expect the ack data to be 
replicated, and updated? I see three options:
A) Let non-acked list be a part of the listener record in replicated 
cache, and the primary owner which executes the event should update 
these via delta messages. I guess for proper reliability it should add 
operation record synchronously before confirming the operation to the 
originator, and then it might asynchronously remove it after the ack 
from client. When a node becomes primary owner, it should send events to 
client for all non-acked events.
B) Having the non-acked list attached directly to cache entry (updating 
it together with regular backup), and then asynchronously updating the 
non-ack list after ack comes
C) Separate cache for acks by entry keys, similar to B, consistent hash 
synced with the main entry cache

Radim


On 12/05/2013 05:16 PM, Galder Zamarreño wrote:
> Hi all,
>
> Re: https://github.com/infinispan/infinispan/wiki/Remote-Hot-Rod-Events
>
> Thanks a lot for the feedback provided in last thread. It was very constructive feedback :)
>
> I've just finished updating the design document with the feedback provided in the previous email thread. Can you please have another read and let the list know what you think of it?
>
> Side note: The scope has got bigger (with the addition of filters/converters), so we might need to consider whether we want all features in next version, or whether some parts could be branched out to next iterations.
>
> Cheers,
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>


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