[
https://issues.apache.org/jira/browse/ARTEMIS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram closed ARTEMIS-90.
---------------------------------
Resolution: Fixed
> ClassNotFoundException when a backup server fails over after having failed
> back
> -------------------------------------------------------------------------------
>
> Key: ARTEMIS-90
> URL: https://issues.apache.org/jira/browse/ARTEMIS-90
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Affects Versions: 1.0.0
> Reporter: Jeff Mesnil
> Assignee: Justin Bertram
> Fix For: 1.0.1
>
>
> 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)
