On Dec 6, 2013, at 10:45 AM, Radim Vansa <rvansa(a)redhat.com> wrote:
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.
What do you mean by runtime parameter exactly? Can you give a concrete example of what you
want to achieve that is not possible with what I've written up?
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 }.
Makes a lot of sense, +1.
3) should the client provide source id when registering listener or
when starting RemoteCacheManager? No API for that.
Every operation will require a source ID from now on, so clients must provide it from
first operation sent to the server. From a Java client perspective, you'd have this
from the start via the configuration.
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.
In clustered listeners, the other nodes you talk about are gonna need to know about the
clustered listeners so that they route events. Some kind of information about these
clustered listeners will need to be sent around the cluster. The exact details are
probably implementation details but we have a clustered registry already in place for this
kind of things. In any case, it'd make a lot of sense that both use cases reuse as
much as logic in this area.
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
Definitely not B. I don't wanna tie the internal cache entry to the ACKs. The two
should be independent. Either C or A. For C, you'd wished to have a single cache for
all listeners+caches, but you'd have to think about the keys and to have the same
consistent hash, you'd have to have same keys. A might be better, but you certainly
don't want this ACK info in a replicated structure. You'd want ACKs in a
distributed cache preferably, and clustered listener info in the clustered replicated
registry.
Cheers,
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(a)redhat.com
>
twitter.com/galderz
>
> Project Lead, Escalante
>
http://escalante.io
>
> Engineer, Infinispan
>
http://infinispan.org
>
--
Radim Vansa <rvansa(a)redhat.com>
JBoss DataGrid QA
--
Galder Zamarreño
galder(a)redhat.com
twitter.com/galderz
Project Lead, Escalante
http://escalante.io
Engineer, Infinispan
http://infinispan.org