Hi Juha I had a look, essentially it is only the 2 eviction-enabled tests that fail. And this is because you do not have a cache store configured. The eviction thread will kick in and pull stuff out of memory - and at this point you will need to have this overflow into a cache store. When using DIST and the key is mapped to the local node, the DistributionManager will *not* attempt a remote lookup as the key is assumed to be available locally (either in memory or in a cache store).

On 7 Dec 2009, at 15:50, Juha Heljoranta wrote: > Hi, > > Thanks for clarifying. The eviction policy seems to make sense. > > I still get test failure when running a test with L1 cache disabled. I > added an assertion check for the cache put/get operations to detect > timeout. And this is what I'm constantly getting: > java.lang.AssertionError: Cache get took 15002 milliseconds > (timeout=2000) key=L1DisabledAsymmetricClusterTest-28. > > Could you try to re-run the test? I've enclosed an improved version of > the patch. Also, if you still cannot reproduce the issue, please try to > increase cacheEntriesNum in AbstractAsymmetricClusterTest. I too have changed the patch a bit to work better in the test framework - care to have a look and merge with your changes?

Hi, I improved the patch slightly. The tests pass now just fine (tested with trunk r1296). Test suite will now print a warning if cache put()/get() takes longer than 2 s and fails if they take longer than 20 s. I usually see few warnings about get() taking 15 s, an issue which might warrant some investigating. Could you apply the patch? Regards, Juha Heljoranta

Hi Juha I saw the JIRA you created, thanks for this - I'll take a closer look this week. Cheers Manik On 17 Dec 2009, at 12:52, Juha Heljoranta wrote: > Hi, > > In case the my previous mail didn't get through I'd still hope to get my patch > getting merged. > > The test should highlight an issue where cache.get() "fails" by taking 15 > second to execute. > > When I enable trace level logging this here is what jgroups says: > 14:52:36.206 [main] TRACE org.jgroups.blocks.GroupRequest - call did not > execute correctly, request is [req_id=1260622341191 > caller=nine-22069 > entries: > nine-12394: sender=nine-12394, retval=null, received=false, suspected=false > nine-39772: sender=nine-39772, retval=SuccessfulResponse, received=true, > suspected=false > > I've tried to locate where things go wrong but failed to nail it down. I > suspect that either there is some sort of race condition in infinispan or the > bug is in jgroups. > > Regards, > Juha Heljoranta > > > On Friday 11 December 2009 21:20:34 Juha Heljoranta wrote: >> Hi, >> >> I improved the patch slightly. The tests pass now just fine (tested with >> trunk r1296). >> >> Test suite will now print a warning if cache put()/get() takes longer than >> 2 s and fails if they take longer than 20 s. I usually see few warnings >> about get() taking 15 s, an issue which might warrant some investigating. >> >> Could you apply the patch? >> >> Regards, >> Juha Heljoranta >> -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev