[infinispan-dev] NPE from invokeRemotely on stopped cache

[Sanne Grinovero]

2010/7/26 Galder Zamarreño <galder at redhat.com>:
>
> On Jul 26, 2010, at 5:37 PM, Sanne Grinovero wrote:
>
>> 2010/7/26 Manik Surtani <manik at 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.

Opened: ISPN-551
As described on the issue, setting @Stop(priority=9) on the
ReplicationQueue appears to solve it, but I didn't test it
thoughtfully.

thanks,
Sanne

>
>> 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 at 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 at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>> --
>>> Manik Surtani
>>> manik at jboss.org
>>> Lead, Infinispan
>>> Lead, JBoss Cache
>>> http://www.infinispan.org
>>> http://www.jbosscache.org
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>