Re: [infinispan-dev] rehashing hazard

On 25 Oct 2010, at 11:56, Mircea Markus wrote: > > On 25 Oct 2010, at 11:52, Manik Surtani wrote: > >> >> On 22 Oct 2010, at 17:01, Mircea Markus wrote: >> >>> >>> On 22 Oct 2010, at 15:17, Vladimir Blagojevic wrote: >>>> >>>>>> >>>>>> The operations that need to be sequential are state transfer and tx log transfer. >>>>>> State is being *pulled* by C (thread running on C) and tx log is *pushed* by A (thread running on A). Two threads running in different VMs. >>>>> >>>>> Ok, this would be the issue then - this must have changed when Vladimir inverted the leave task to be a pull for the main state. They both used to be pushes and sequential. >>>>> >>>>> Perhaps the sequentiality can be re-established by a lock on the receiver? >>>> >>>> Interested. What if C thread announce that it pulled state and upon reception of this message A drains the logs? >>> >>> Is there any work that can be done in parallel? State transfer and log draining need to happen in sequence. >>> If not what's the point of using two threads? >> >> They are not just 2 threads - they are on 2 separate nodes. State tfr is initiated by the receiver; tx log training by the sender. > Why can't the sender initiate state transfer and then drain tx log? I.e. a thread on the sender write state and then write tx log. No sync needed then. That was the original design. But that was even harder to debug/maintain since the Join and Leave processes were logically similar but implemented completely differently. With the current approach the state transfer is the same for both Join and Leave. The tx log handling is the only bit that is different.

-- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev