[jira] [Assigned] (ARTEMIS-90) ClassNotFoundException when a backup server fails over after having failed back

["Justin Bertram (JIRA)" <ji...@apache.org>]

     [ 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)