Re: [infinispan-dev] NPE from invokeRemotely on stopped cache

On 26 Jul 2010, at 09:33, Galder Zamarreño wrote: > Looks to me that this is an issue with stoppage priorities. ReplicationQueue.stop() should happen before JGroupsTransport.stop() > > At the moment, both @Stop methods are defined without priority (JGroupsTransport's @Stop is on Transport interface), so they assumed default which is 10. > > It's unclear from @Stop how the priorities work (javadoc needs to be clearer cos at the moment it's a copy/paste of @Start), but I think (without looking at the code) that higher priorities (= lower numbers) would be stopped first. > > So, you could try setting RQ's stop to 9 and @Stop in transport to 10 (default) and  and see if it works. +1, that should do it for you.

> > On Jul 25, 2010, at 7:15 PM, Sanne Grinovero wrote: > >> Hello, >> I got the following stacktrace using CR2: >>    [exec] java.lang.NullPointerException >>    [exec]    at >> org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:92) >>    [exec]    at >> org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:128) >>    [exec]    at >> org.infinispan.remoting.ReplicationQueue.flush(ReplicationQueue.java:147) >>    [exec]    at >> org.infinispan.remoting.ReplicationQueue$1.run(ReplicationQueue.java:99) >>    [exec]    at >> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >>    [exec]    at >> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) >>    [exec]    at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) >>    [exec]    at >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) >>    [exec]    at >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) >>    [exec]    at >> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) >>    [exec]    at >> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >>    [exec]    at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >>    [exec]    at java.lang.Thread.run(Thread.java:619) >> >>> From which I went to inspect >> org.infinispan.remoting.transport.jgroups.JGroupsTransport; in this >> class the "members" field is initialized as Collections.emptyList() >> and it appears that the only way to become null is by stopping the >> cache. >> Also it seems that in many points the check "members!=null" is >> performed, but not in RpcManagerImpl. >> >> Could the stop() method be changed to set this value to emptyList() >> too, so that all those "!=null" checks could be avoided, or if you see >> good reasons to throw an error then what would be a better one than >> NPE. >> >> I'm also wondering if this is supposed to happen: isn't this a race >> condition during the stop process of the cache? I'd like to stop it >> after all replications have been sent, seems cleaner. >> >> Regards, >> Sanne >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- 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