[infinispan-dev] Hot Rod partial topology update processing with new segment info - Re: ISPN-4674

[Dan Berindei]

Do we really need to send those partial topology updates? What topology id
do they have?

When the coordinator sees the leaver, it updates the consistent hashes on
all the members and increases the cache topology id. Normally this is
immediately followed by a new topology update that starts a rebalance, but
if there is just one node left in the cluster there is nothing to rebalance
and this will be the last topology sent to the client. If we already sent a
partial topology to the client with that id, we'll never update the CH on
the client.

Cheers
Dan



On Thu, Aug 28, 2014 at 3:20 PM, Galder Zamarreño <galder at redhat.com> wrote:

> Hey Dan,
>
> Re: https://issues.jboss.org/browse/ISPN-4674
>
> If you remember, the topology updates that we send to clients are
> sometimes partial. This happens when at the JGroups level we have a new
> view, but the HR address cache has not yet been updated with the JGroups
> address to endpoint address. This logic works well with HR protocol 1.x.
>
> With HR 2.x, there’s a slight problem with this. The problem is that we
> now write segment information in the topology, and when we have this
> partial set up, calls to locateOwnersForSegment(), for a partial cluster of
> 2, it can quite possibly return 2.
>
> The problem comes when the client reads the number of servers, discovers
> it’s one, but reading the segment, it says that there’s two owners. That’s
> where the ArrayIndexOutOfBoundsException comes from.
>
> The question is: how shall we deal with this segment information in the
> even of a partial topology update?
>
> >From a client perspective, one option might be to just ignore those
> segment positions for which there’s no cluster member. IOW, if the number
> of owners is bigger than the cluster view, it could just decide to create a
> smaller segment array, of only cluster view size, and then ignore the index
> of a node that’s not present in the cluster view.
>
> Would this be the best way to solve it? Or could we just avoid sending
> segment information that’s not right? IOW, directly send from the server
> segment information with all this filtered.
>
> Thoughts?
>
> Cheers,
> --
> Galder Zamarreño
> galder at redhat.com
> twitter.com/galderz
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140828/873ef5f9/attachment.html