[infinispan-dev] atomic operations for Lucene's LockManager on Infinispan

[Mircea Markus]

I've fixed it for the local cache mode (concurrency issue).
There are still problems for the distributed mode, most likely caused  
by a different thing. Looking into it.

On Oct 22, 2009, at 6:01 PM, Mircea Markus wrote:

>
> On Oct 21, 2009, at 9:50 PM, Sanne Grinovero wrote:
>
>> Hello,
>> I've spoken with Manik in IRC about this, so wanted to share this,
>> especially because he mentioned to ask someone to help me.
> I've applied the patch and reproduced the failure. Looking into it  
> right now.
>>
>>
>> I've been busy writing a lock-stress-test for our implementation for
>> Lucene's Lock and Lockfactory, and got some trouble using
>>
>> cache.putIfAbsent(Object key, Object value);
>>
>> It appears to not behave atomically as it should.
>> I've confirmed the test is working when mocking the cache with a  
>> plain
>> ConcurrentHashMap, so next step for me is having someone
>> with better knowledge of Infinispan core have a look into the code; I
>> might have some configuration problem.
>>
>> My test is attached to ISPN-227, here are some instructions:
>> the test to run is
>> org.infinispan.lucene.InfinispanLockFactoryStressTest, which creates
>> and uses several org.infinispan.lucene.InfinispanLock.
>>
>> mvn test -Dtest=org.infinispan.lucene.InfinispanLockFactoryStressTest
>> -Dbind.address=127.0.0.1 -Djava.net.preferIPv4Stack=true
>>
>> The test defines 3 different cacheFactory, only one is not commented,
>> so please edit the code to try against a different ConcurrentMap
>> implementation and see what happens.
>> Some status will be sent to system.out.
>>
>>  * MultiNodeTestCacheFactory emulates different nodes sharing state,
>> and each node is having n threads (using Core Infinispan's
>> MultipleCacheManagersTest)
>>
>>  * ConcurrentHashMapCacheTestFactory uses Java's ConcurrentHashMap
>>
>>  * LocalISPNCacheTestFactory (using
>> TestCacheManagerFactory.createLocalCacheManager(false))
>>
>> This is not intended to be committed for now, just to find out what's
>> wrong. Also this is not the Lock implementation as we need it, but
>> first this step should be fixed.
>>
>> thanks,
>>
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>