On Thu, Jan 19, 2017 at 11:13 AM Radim Vansa <rva...@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 <rva...@redhat.com> > JBoss Performance Team > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
