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.
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