[infinispan-dev] rehashing hazard

Manik Surtani manik at jboss.org
Mon Oct 25 07:31:43 EDT 2010


On 25 Oct 2010, at 12:26, Mircea Markus wrote:

> 
> 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?).

Umm, nope.  :)  One is a push and one is a pull.  Very different.  Anyway, have a look if you have the time in future, but for now I reckon we either stick with a lock or an ack message to make sure the 2 processes happen sequentially.

Cheers
Manik
--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list