Oops, I thought I had replied to this...
On Thu, Jan 19, 2017 at 6:11 PM, 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. > I see this exactly the opposite way: state transfer is the actual transfer of the data, and the rebalance is the whole process of adding a "pending" consistent hash, starting the state transfer, confirming the transfer of state, and finally replacing the "current" consistent hash with the pending one. > 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 problem I was trying to solve with the "rebalance" name in 5.2 is that before we had two different concepts: 1. State transfer applied only to replicated caches, and it meant transferring state from the coordinator to a joiner. 2. Rehashing meant computing a new consistent hash based on the JGroups view, receiving state from old owners based on the consistent hash of the old JGroups view, and removing state no longer owned in the new consistent hash. The coordinator didn't have a special role. Rebalancing was meant to be an extension of rehashing to cover both distributed and replicated caches (now with replicated caches also being able to receive state from multiple members in parallel). Some of the components (StateTransferManager) and events (DataRehashEvent) kept their names, however. > 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
