[infinispan-dev] rehashing hazard

[Mircea Markus]

On 25 Oct 2010, at 12:00, Manik Surtani wrote:

> 
> 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.
Can't we factorize the code common Leave and Join code and still use a single thread to do all the action? There's no point in using two threads that run in sequence (unless they do some parallel processing?).
> 
> 
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
> 
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev