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

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: -- Radim Vansa <rvansa(a)redhat.com&gt; JBoss DataGrid QA