[infinispan-dev] State transfer-related terms

[William Burns]

On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa <rvansa at redhat.com> wrote:

> Hi,
>
> I've started (again) working on ISPN-5021 [1], and I'd like to get some
> common agreement on few terms. So below I summarize my understanding (or
> misunderstanding) of these, please state you opinion, thinking a bit
> more generally.
>
> State transfer: whole process beginning with some ST-related event =
> node being detected to crash/sending join or leave request, and ending
> when this event is processed. When another event happens, the current ST
> can either be finished or canceled and then *another* ST can begin.
> State transfer is a cluster-wide process, though it cannot be started
> and ended absolutely simultaneously.
>
> Rebalance: one phase of ST, when the data transfer occurs.
>
> Data rehash: this is a bit painful point: we have DataRehashEvent where
> the name suggest that it is related rather to rebalance, but currently
> it fires when CacheTopology.getPendingCH() == null (that means when ST
> is complete), and the event itself also looks more like it should be
> fired at the end of state transfer. If we have something more to do
> after the rebalance, I am not sure how useful is firing that just
> because all data has been transferred (but for example before old data
> has been wiped out). Should I add another StateTransferEvent event (and
> appropriate listeners)? That would break the compatibility with tightly
> related implementations...
>

The stream retry mechanism currently uses DataRehashedEvent. It is
beneficial but not required for it to be notified immediately after all
entries have been transferred but before any have been removed. This
shortens the window for when a stream operation is retried since it has to
be sure that all entries for a given segment are present, but we don't care
if entries for a non owned segment are present. But the good thing is that
the code shouldn't require much work at all to be changed if we needed to.

I am personally not keen on having another event that is like
DataRehashedEvent, but only signifies entries were removed. It seems a bit
confusing. Is there any usage you were thinking that required the old
entries to be removed that could benefit from the new event/listeners?


>
> WDYT?
>
> Radim
>
> [1] https://issues.jboss.org/browse/ISPN-5021
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> 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/20170119/fa2755b8/attachment.html