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