[jboss-user] [JBoss Cache: Core Edition] - Re: is it possible for MVCCInvocationContext to have null mv

[dukehoops]

aha!

So there *is* another thread at work - at least in this test environment. Look in createCache():

createCache(UnitTestConfigurationFactory.createConfiguration(Configuration.CacheMode.LOCAL, true); //true==some eviction policy

That's why when I break in ctx.lookUpNode, I see the following stack running on a thread called "EvictionTimer-0". this certainly explains why stepping through with a debugger alters results:


anonymous wrote : org.jboss.cache.invocation.MVCCInvocationContext.lookUpNode(MVCCInvocationContext.java:76)
  | org.jboss.cache.commands.write.EvictCommand.lookupForEviction(EvictCommand.java:168)
  | org.jboss.cache.commands.write.EvictCommand.perform(EvictCommand.java:93)
  | org.jboss.cache.interceptors.CallInterceptor.invokeCommand(CallInterceptor.java:108)
  | org.jboss.cache.interceptors.CallInterceptor.handleDefault(CallInterceptor.java:99)
  | org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:85)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | org.jboss.cache.interceptors.EvictionInterceptor.visitEvictFqnCommand(EvictionInterceptor.java:80)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | org.jboss.cache.interceptors.MVCCLockingInterceptor.handleEvictFqnCommand(MVCCLockingInterceptor.java:141)
  | org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitEvictFqnCommand(PrePostProcessingCommandInterceptor.java:185)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
  | org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:85)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | org.jboss.cache.interceptors.TxInterceptor.attachGtxAndPassUpChain(TxInterceptor.java:261)
  | org.jboss.cache.interceptors.TxInterceptor.handleDefault(TxInterceptor.java:250)
  | org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:85)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | org.jboss.cache.interceptors.CacheMgmtInterceptor.visitEvictFqnCommand(CacheMgmtInterceptor.java:65)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
  | org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
  | org.jboss.cache.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:130)
  | org.jboss.cache.commands.AbstractVisitor.visitEvictFqnCommand(AbstractVisitor.java:85)
  | org.jboss.cache.commands.write.EvictCommand.acceptVisitor(EvictCommand.java:173)
  | org.jboss.cache.interceptors.InterceptorChain.invoke(InterceptorChain.java:287)
  | org.jboss.cache.invocation.CacheInvocationDelegate.evict(CacheInvocationDelegate.java:370)
  | org.jboss.cache.invocation.CacheInvocationDelegate.evict(CacheInvocationDelegate.java:374)
  | org.jboss.cache.eviction.DefaultEvictionActionPolicy.evict(DefaultEvictionActionPolicy.java:50)
  | org.jboss.cache.eviction.BaseEvictionAlgorithm.evictCacheNode(BaseEvictionAlgorithm.java:265)
  | org.jboss.cache.eviction.LRUAlgorithm.evict(LRUAlgorithm.java:121)
  | org.jboss.cache.eviction.LRUAlgorithm.prune(LRUAlgorithm.java:153)
  | org.jboss.cache.eviction.BaseEvictionAlgorithm.process(BaseEvictionAlgorithm.java:146)
  | org.jboss.cache.RegionImpl.processEvictionQueues(RegionImpl.java:128)
  | org.jboss.cache.eviction.EvictionTimerTask.handleRegion(EvictionTimerTask.java:115)
  | org.jboss.cache.eviction.EvictionTimerTask.processRegions(EvictionTimerTask.java:107)
  | org.jboss.cache.eviction.EvictionTimerTask.access$100(EvictionTimerTask.java:42)
  | org.jboss.cache.eviction.EvictionTimerTask$Task.run(EvictionTimerTask.java:133)
  | java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
  | java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
  | java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
  | java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
  | java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
  | java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
  | java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
  | java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
  | java.lang.Thread.run(Thread.java:619)

Now, i'll try to see what happens if I don't use an eviction policy (as, i think, is the case in our app)..

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4217097#4217097

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4217097