Re: [infinispan-dev] Design of Remote Hot Rod events - round 2
On Dec 13, 2013, at 4:33 PM, Radim Vansa <rvansa(a)redhat.com> wrote:
On 12/13/2013 03:49 PM, Galder Zamarreño wrote:
> On Dec 6, 2013, at 4:17 PM, Radim Vansa <rvansa(a)redhat.com> wrote:
>
>> Btw., when Hot Rod fails to hit the primary owner, should the non-owner propagate
the SourceID to primary owner somehow? Or is in this case acceptable notifying the
listener about its own change?
> If the call lands in a non-owner, it's probably simpler for the non-owner to send
the notification there and then. ACK information tracking would probably be distributed,
in which case it'd need to deal with potential failure of the primary owner.
I don't think I understand that properly. The node responsible for notifying the
client is either primary owner, or operation origin (where the write has landed in fact).
Previously, we were saying that the responsible node should be the primary owner - now you
say that the origin. When the cluster is accessed only remotely, it does not have much
performance impact (as these two are mostly the same node), but with cluster in
compatibility mode the decision could affect the performance a lot.
Normally, a Hot Rod call would land on the owner of the key, which then is able to send
the notification itself. The question, as you've rightly asked, is what to do when the
call lands in a non-owner. Is that because the owner node has failed? Is it because the
client has a flaky issue with the hash function and not all calls are directed to
non-owners? Rather than spending time forcing the owner to be the one that sends the
notification, a non-owner might say: something weird happened here, I should have received
this call, but just in case, I'll send notifications linked to it.
So, do you think that this should be the origin (easier to implement,
with access to distributed ack registry it can retrieve the information, but with higher
latency as the ack info is probably affine to the entry itself)
or primary owner (in this case you'd have to propagate the source ID with the write
command).
Btw., what should be the source ID for operations coming from library mode? JGroups
address of the node?
Personally, I think remote eventing is complex enough as it is to add compatibility in
this first release because there's no event infrastructure for memcached nor REST. We
should focus on getting remote events right for Hot Rod.
Radim
>
> 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