TODOs in code
by Manik Surtani
As a part of a cleanup process, could you guys please have a look at
any TODOs you have in the src tree and address what can be addressed?
I see a number of minor things that should be small code changes or
fixes. Would be good to have these cleaned up prior to another CR or
GA.
Thanks
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
15 years, 11 months
race condition in AsyncStore
by Mircea Markus
Hi Galder,
This is following an email sent this morning on an infinit loop in
AsyncTest. I've found what was[1] causing the infinite loop. Here it
is (see comments in the code):
Let's say we do put(k1, v1) and put(k1, v2) in this order
void run0() throws InterruptedException {
if (trace) log.trace("Checking for modifications");
boolean unlock = false;
try {
acquireLock(write);
unlock = true;
swap = state;
state = newStateMap();
} finally {
if (unlock) write.unlock();
}
//thread ONE comes here and is processing (k1, v1); it releases the
write lock. Immediately, thread TWO acquires write lock, and takes
(k1,v2) from the store into its swap.
// the race condition happens when thread TWO executes (i.e. persists)
before thread one, and as a result in the store the final value
persisted is v1 (not v2).
// This is known to be an async (i.e. best effort store), so this
situation might be considered as normal behavior. Still, I think this
induces unwanted errors/behavior.
// A possible solution is to only release the WL after put(swap).
if (trace) log.trace("About to insert the swap: " + swap);
int size = swap.size();
if (size == 0)
awaitNotEmpty();
else
decrementAndGet(size);
if (trace) log.trace("Calling put(List) with {0}
modifications", size);
put(swap);
}
Cheers,
Mircea
[1] I say 'was' because I modified the test to fail (intermittently)
rather than hang
15 years, 11 months
AsyncStore.testMultiplePutsOnSameKey - endless loop
by Mircea Markus
Hi,
There is an endless loop in this method.
the test puts multiple values on the same key in a cache store and
expects (forever) until the store contains the very last value added.
I'm being able to reproduce this on my Mac quite easily (< 10 runs).
If anyone feels like taking a look, otherwise I can approach it once
I'm done with ISPN-236 cache.putIfAbsent() is not atomic
Cheers,
Mircea
15 years, 11 months
put if absent not atomic: https://jira.jboss.org/jira/browse/ISPN-236
by Mircea Markus
Hi Manik,
While the fix I made for EntityWrapper fixed the cache in local mode,
the replicated mode[1] (pretty sure dist is the same) is far from
working.
The issue is the following:
node1.put(k,v2) :: WL(k1) -> releaseLock(k1) -> replicate(k1) ->
incoming_thread_performs put (k, *v2*)
node2.put(k,v2) :: WL(k2) -> releaseLock(k2) -> replicate(k2) ->
incoming_thread_performs put (k, *v1*)
now in this scenario both operation succeed! This is caused by the
fact that lock interceptor is *after* repl interceptor in the chain,
so when repl is triggered the key is no longer locked.
In other words, if the puts happen at the same time, on the same key
then both might succeed, leaving the cluster in an inconsistent state.
IMO, the correct approach would be to keep the lock while doing the
replication. This would reduce the concurrency though, as locks would
be held for longer amounts of time. But the data consistency would
increase. (this would be an easy fix for Repl, but dist relies on
interceptor's order).
I've also tried doing the call within a tx, but there's a deadlock -
I'll investigate this on Mon.
[1] I know disyt is what we'll use but problem exists for repl as well
Cheers,
Mircea
15 years, 11 months
EntryFactory in the wrong package (?)
by Mircea Markus
Hi,
EntryFactory is in the org.infinispan.factories package.
My understanding of this package is that it contains factories for the
dependency injection fwk's components. I've just noticed that it
contains this general-purpose factory objects: EntryFactory. I think
this should be placed in the container package, as according to its
functionality there is where it belongs. E.g. if I want to enable
trace in container related stuff(like I want now :) ), I change the
log level for package org.infinispan.container and not for package
org.infinispan.factory. Wdyt?
Cheers.
Mircea
15 years, 11 months
atomic operations for Lucene's LockManager on Infinispan
by Sanne Grinovero
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 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
15 years, 11 months
Re: [infinispan-dev] ${java.io.tmpdir}
by Vladimir Blagojevic
Mircea,
Have a look at TypedPropertiesAdapter. It handles replacement for
<property> elements. All those nagging and failing replacement tests
pass now.
I found string-property-replaced.xml that indicates intention to support
replacement for all values in all configuration elements? Do we want this?
On 09-10-19 1:23 PM, Mircea Markus wrote:
> Hey mate.
> Can we have a chat on this one tomorrow? We're getting close to a CR
> just to see how this can be solved.
> I'm in the office from 8 am to about 6 am tomorrow, gmt+1.
> Btw, I'm writing from lon :)
>
> Cheers,
> Mircea
>
> On Oct 19, 2009, at 7:00 PM, Mircea Markus wrote:
>
>> Hi there,
>> There was code doing the replacement but got lost during migration to
>> JAXB. The code that did the magic is in
>> org.jboss.util.StringPropertyReplacer from jboss-common-core.
>> Before setting any value on a property this had to be first. In JBC
>> this was quite straight forward, but don't know the hooks for
>> interfering with JAXB.
>>
>> Cheers,
>> Mircea
>>
>>
>> On Oct 19, 2009, at 6:49 PM, Vladimir Blagojevic wrote:
>>
>>> Mircea,
>>>
>>> Are we replacing these placement tokens? I cannot find code where we
>>> do this.
>>> Any ideas?
>>>
>>> Regards,
>>> Vladimir
>>
>
15 years, 11 months
