[infinispan-dev] Design of Remote Hot Rod events - round 2
Radim Vansa
rvansa at redhat.com
Fri Dec 13 10:33:59 EST 2013
On 12/13/2013 03:49 PM, Galder Zamarreño wrote:
> On Dec 6, 2013, at 4:17 PM, Radim Vansa <rvansa at 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.
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?
Radim
>
> Cheers,
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
> Project Lead, Escalante
> http://escalante.io
>
> Engineer, Infinispan
> http://infinispan.org
>
--
Radim Vansa <rvansa at redhat.com>
JBoss DataGrid QA
More information about the infinispan-dev
mailing list