activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Mesnil (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-90) ClassNotFoundException when a backup server fails over after having failed back
Date Tue, 16 Jun 2015 09:10:01 GMT


Jeff Mesnil commented on ARTEMIS-90:

I don't think that dealing with class loader is appropriate.

For the lifetime of Artemis server, it will always use the same type of NettyAcceptorFactory.
Artemis should get a reference on its instance and keep it.
In my opinion, the threads should really be using the injected executor service. I don't understand
why Artemis can not use the injected ExecutorService. As long as I have not called start on
the server, it should be possible to set the executor service in the service registry so that
when Artemis is started, it checks if there is an executor service before creating any thread.

> ClassNotFoundException when a backup server fails over after having failed back
> -------------------------------------------------------------------------------
>                 Key: ARTEMIS-90
>                 URL:
>             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
> {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 "" 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(
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(
>         at org.jboss.modules.ConcurrentClassLoader.performLoadClass(
>         at org.jboss.modules.ConcurrentClassLoader.loadClass(
>         at org.apache.activemq.core.remoting.server.impl.RemotingServiceImpl.start(
>         at org.apache.activemq.core.server.impl.ActiveMQServerImpl.initialisePart2(
>         at
>         at
> {noformat}
> The CFNE occurs because WildFly uses a modular class loader.
> The SharedNothingBackupActivation runnable is run by creating a new backupActivationThread
> In a modular environment this thread's module has not knowledge of the NettyAcceptorFactory
> 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

View raw message