Jeff Mesnil created ACTIVEMQ6-90:
------------------------------------
Summary: ClassNotFoundException when a backup server fails over
after having failed back
Key: ACTIVEMQ6-90
URL: https://issues.apache.org/jira/browse/ACTIVEMQ6-90
Project: Apache ActiveMQ 6
Issue Type: Bug
Affects Versions: 6.0.0
Reporter: Jeff Mesnil
I'm integrating ActiveMQ 6 in WildFly and testing out its failover features.
My use case is:
2 servers:
* server #1 with replicated master HA (check-for-live-serve=true)
* server #2 with replicated slave HA (restart-backup=true)
* both servers are started
=> #1 is master
=> #2 announces it is a backup
* server #1 is stopped
=> #2 fails over and becomes live
* server #1 is restarted
=> #2 detects the live is up again and fails back
* server #1 is stopped again
=> I was expecting server #2 to becomes live again but instead, I got the
following exception:
{noformat}
16:27:07,528 WARN [org.apache.activemq.core.server] (AMQ119000: Activation for
server ActiveMQServerImpl::serverUUID=null) AMQ222080: Error instantiating
remoting acceptor
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory:
java.lang.ClassNotFoundException:
org.apache.activemq.core.remoting.impl.netty.NettyAcceptorFactory from [Module
"org.wildfly.extension.io:main" from local module loader @6e32bb55 (finder:
local module finder @44a901f8 (roots:
/Users/jmesnil/Developer/wildfly/dist/target/slave/modules,/Users/jmesnil/Developer/wildfly/dist/target/slave/modules/system/layers/base))]
at
org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:216)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
at
org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
at
org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
at
org.apache.activemq.core.remoting.server.impl.RemotingServiceImpl.start(RemotingServiceImpl.java:235)
at
org.apache.activemq.core.server.impl.ActiveMQServerImpl.initialisePart2(ActiveMQServerImpl.java:1778)
at
org.apache.activemq.core.server.impl.SharedNothingBackupActivation.run(SharedNothingBackupActivation.java:280)
at java.lang.Thread.run(Thread.java:744)
{noformat}
The CFNE occurs because WildFly uses a modular class loader.
The SharedNothingBackupActivation runnable is run by creating a new
backupActivationThread (ActiveMQServerImpl.java:425).
In a modular environment this thread's module has not knowledge of the
NettyAcceptorFactory class.
To prevent this CFNE, this thread should use the TCCL before loading the
acceptor factory from its class names.
Additionally, I'm not sure it's a good idea to create new Thread like this.
ActiveMQ has a threadPool executorService that could be used to run such code.
Since ActiveMQ supports injection of this threadPool (through the
serviceRegistry), WildFly could ensure that any code run by this thread pool
will be using the correct module class loader.
Is there a good reason to use a separate thread for the backup activation?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
