Re: [jgroups-dev] ViewHandler and ProtocolStack.timer shutdown

[Vladimir B. <vla...@re...>]

I though about this for a while. We have to either override schedule 
method, submit jobs with isShutdown check or install our own 
RejectedExecutionHandler. 

I am leaning towards installing our own ShutdownRejectedExecutionHandler 
on all our ThreadedPoolExecutor(s) (TPEs). 
ShutdownRejectedExecutionHandler is a decorator on top of provided 
RejectedExecutionHandler. ShutdownRejectedExecutionHandler will check 
status of TPE and if it is shutdown log a warning without throwing a 
runtime exception. In all other cases it will invoke rejectedExecution 
on provided RejectedExecutionHandler.

What do you think?

Cheers.

Brian Stansberry wrote:
> Saw this when scanning through logs from a JBoss AS testsuite run 
> (JGroups 2.6.2). Don't think it led to a problem in the testsuite, but 
> looked ugly so wanted you guys to know about it:
>
> 2008-04-20 00:54:26,550 INFO  [org.jboss.cache.RPCManagerImpl] (RMI TCP 
> Connection(24)-127.0.0.1) Disconnecting and closing the Channel
> 2008-04-20 00:54:26,602 ERROR [org.jgroups.protocols.UDP] (ViewHandler) 
> failed sending message to null (145 bytes)
> java.util.concurrent.RejectedExecutionException
> 	at 
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477)
> 	at 
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384)
> 	at 
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:177)
> 	at 
> java.util.concurrent.ScheduledThreadPoolExecutor.schedule(ScheduledThreadPoolExecutor.java:292)
> 	at org.jgroups.protocols.TP$Bundler.send(TP.java:1777)
> 	at org.jgroups.protocols.TP$Bundler.access$200(TP.java:1750)
> 	at org.jgroups.protocols.TP.send(TP.java:1305)
> 	at org.jgroups.protocols.TP.down(TP.java:1038)
> 	at org.jgroups.protocols.TP$ProtocolAdapter.down(TP.java:2002)
> 	at org.jgroups.protocols.Discovery.down(Discovery.java:350)
> 	at org.jgroups.protocols.MERGE2.down(MERGE2.java:176)
> 	at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:364)
> 	at org.jgroups.protocols.FD.down(FD.java:316)
> 	at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:95)
> 	at org.jgroups.protocols.pbcast.NAKACK.send(NAKACK.java:781)
> 	at org.jgroups.protocols.pbcast.NAKACK.down(NAKACK.java:583)
> 	at org.jgroups.protocols.UNICAST.down(UNICAST.java:452)
> 	at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:317)
> 	at org.jgroups.protocols.pbcast.GMS.castViewChangeWithDest(GMS.java:429)
> 	at 
> org.jgroups.protocols.pbcast.CoordGmsImpl.handleMembershipChange(CoordGmsImpl.java:407)
> 	at org.jgroups.protocols.pbcast.GMS$ViewHandler.process(GMS.java:1386)
> 	at org.jgroups.protocols.pbcast.GMS$ViewHandler.run(GMS.java:1342)
> 	at java.lang.Thread.run(Thread.java:595)
>
> Walking through the stack trace, the interesting bit is 
> java.util.concurrent.ScheduledThreadPoolExecutor.delayedExecute(ScheduledThreadPoolExecutor.java:177), 
> which does this:
>
> private void delayedExecute(Runnable command) {
>     if (isShutdown()) {
>        reject(command);
>
> So, the task is rejected because ProtocolStack.timer has already been 
> shut down. This implies the ViewHandler was trying to send a message 
> after the channel was disconnected.
>
>