[infinispan-dev] Design of Remote Hot Rod events

[Radim Vansa]

Hi, my couple of questions & remarks:

1. Why there is no RemoteCacheEntryCreated? I guess you had good reason 
to exclude it but you could at least explain it. For the event lifecycle 
creation sounds to me as important as removal.

2. Does removal due to expiration map to Removed as well? What about 
invalidation in invalidation cache?

3. IMO, registering events for particular keys is not that optional. If 
you allow only all-keys listener, you end up with users screwing 
performance by registering listeners with if (key.equals(myKey)) {...}.

4. It seems to me that one global listener per client per cache is 
enough. Will the client code register such single listener and multiplex 
all the events to the registered listeners? Related to 3. if you don't 
implement the filtering by key on server, you should at least already 
provide this as client API and do the equals check locally. 
Nevertheless, this would require client equality on keys.

5. Are pre/post events supported here? I guess not, but this is 
something to note.

6. Are the events in fact async? It seems to me that these are (the ACKs 
are only for delivery).

7. The reliability guarantees should be specified more closely. From the 
document it seems that we try to support the near-cache use case by 
always sending the last update (the intermediate updates can be lost 
according to ACK tracking), but the events themselves are not guaranteed 
to be delivered. So is the target reliability "eventually synced cache"?

8. As the client itself is responsible for contacting each server and 
registering the listener, there's another scenario besides server 
failure. It takes some time before client receives new topology, so 
another server might join and become primary owner - the client does not 
register to that server until it's late and does not receive the update. 
Even after the client joins, the server has not tracked the listener and 
can't see that it should send the update.
Solution for this would be to keep a cache of listeners (replicated for 
global ones, distributed for key-filtered), delay all writes until this 
cache is replicated and then keep the event in memory even if the client 
is not yet connected.

Radim


On 11/12/2013 04:17 PM, 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


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