On Jul 26, 2010, at 5:37 PM, Sanne Grinovero wrote:
2010/7/26 Manik Surtani <manik(a)jboss.org>:
>
> 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.
>
Thanks for all answers,
I'm trying it but as the exception was showing up very occasionally I
can't tell you if it's fixed (I might be able to tell that it's not
fixed).
Shouldn't this change be applied ? (shall I open an issue?)
Yes please, open an issue for this. If you don't have time to deal with it, feel free
to assign it to myself.
Sanne
>>
>> 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
>
_______________________________________________
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