Duncan Doyle created ISPN-4762:
----------------------------------
Summary: Provide hooks in NettyTransport to verify if the masterGroup and
workGroup have completely shut down
Key: ISPN-4762
URL:
https://issues.jboss.org/browse/ISPN-4762
Project: Infinispan
Issue Type: Enhancement
Components: Remote Protocols
Affects Versions: 7.0.0.Beta2
Environment: Mac OS X 10.9.4, Oracle Hotspot 1.7.0_67, Infinispan 7.0.0.Beta2 in
'Hybrid-mode', JBoss EAP 6.3.0
Reporter: Duncan Doyle
Assignee: Galder ZamarreƱo
Priority: Minor
For various reasons, I run ISPN in, what I call, HybridMode. I basically run ISPN in
lib-mode in a WAR file and bootstrap a HotRodServer from a @WebListener. This allows me to
startup the system on ServletContextListener.contextInitialized and cleanly shutdown the
system on ServletContextListener.contextDestroyed. The app runs on JBoss EAP 6.3.0.
The problem I face is that, when I undeploy my application, I shutdown the HotRodServer
using the stop() method, the HotRodServerWorker threads are stopped asynchronously
(non-blocking). However, there is no hook into the NettyTransport class to actually check
whether the WorkerGroup has completely stopped. JBoss EAP starts undeploying the app,
removing classloaders, etc. while the HotRodServerWorker threads are still active. This
eventually results in ClassNotFoundExceptions on some Netty classes:
{quote}
09:38:10,315 ERROR [stderr] (HotRodServerWorker-3-39) java.lang.NoClassDefFoundError:
io/netty/util/concurrent/DefaultPromise$3
09:38:10,316 ERROR [stderr] (HotRodServerWorker-3-39) at
io.netty.util.concurrent.DefaultPromise.notifyListeners(DefaultPromise.java:593)
09:38:10,316 ERROR [stderr] (HotRodServerWorker-3-39) at
io.netty.util.concurrent.DefaultPromise.setSuccess(DefaultPromise.java:404)
09:38:10,324 ERROR [stderr] (HotRodServerWorker-3-39) at
io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:155)
09:38:10,324 ERROR [stderr] (HotRodServerWorker-3-39) at
java.lang.Thread.run(Thread.java:745)
{quote}
I've currently solved this problem by putting a Thread.sleep in my shutdown code to
give the threads some time to cleanly stop, but that's obviously not ideal. It would
be nice to be able to somehow check whether the NettyTransport 'masterGroup' and
'workerGroup' have stopped, so I can check that in my shutdown sequence.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)