[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