[ https://issues.apache.org/jira/browse/ARTEMIS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Justin Bertram reassigned ARTEMIS-90: ------------------------------------- Assignee: Justin Bertram > 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)