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
> gal...@redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
--
Radim Vansa <rva...@redhat.com>
JBoss DataGrid QA
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
