[infinispan-dev] State transfer-related terms

[Radim Vansa]

On 01/19/2017 11:14 PM, William Burns wrote:
>
>
> On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa <rvansa at redhat.com 
> <mailto: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?

Okay, so from streams POV, DataRehashedEvent should mark rebalance, and 
be fired once all incoming segments arrive. The implementation does not 
rely on pendingCH being null when the event is fired, right? I like such 
definition as "data rehash" sounds like moving data around.

I can see StateTransferEvent being useful when downscaling the cluster, 
and you want to remove one node at a time (as the current leave is not 
too graceful and calling cacheManager.stop() does not wait until ST 
completes).

R.

>
>     WDYT?
>
>     Radim
>
>     [1] https://issues.jboss.org/browse/ISPN-5021
>
>
>     --
>     Radim Vansa <rvansa at redhat.com <mailto:rvansa at redhat.com>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     infinispan-dev at lists.jboss.org <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team