[infinispan-dev] rehashing hazard

Manik Surtani manik at jboss.org
Fri Oct 22 08:40:44 EDT 2010


On 22 Oct 2010, at 12:14, Mircea Markus wrote:

> 
> On 22 Oct 2010, at 12:07, Manik Surtani wrote:
> 
>> 
>> On 21 Oct 2010, at 22:54, Mircea Markus wrote:
>> 
>>> Hi,
>>> 
>>> ISPN-180 requires some significant code changes around re-hashing, so I've decided to make the rehashing-related test suite more stable before changing the code.
>>> I've fixed some, but transactional rehash tests are still failing. Here is why:
>>> 
>>> {A,B,C, D}, num owners= 2. A's state is {(k,v)} and a transactions is prepared with {(k, otherValue)} on A.
>>> B crashes.
>>> two things happen with A's state: 
>>> 1. on C an thread pulls state from A
>>> 2. A sends transaction state to C on another thread
>>> 
>>> Whit the right timing:
>>> - 2 executes first (tx log is drained)
>>> - tx commits - this applies the changes on C as well 
>>> - 1 executes last 
>>> Data ends up inconsistent:
>>> A's states is {(k, otherValue)} while C's state is  {(k,v)} 
>>> 
>>> State transfer and tx log needs to be sequential (not parallel).
>> 
>> But it is sequential.
>> 
>> http://fisheye.jboss.org/browse/Infinispan/branches/4.2.x/core/src/main/java/org/infinispan/distribution/InvertedLeaveTask.java?r=2351#l83
> no :) 
> 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?

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