activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "clebert suconic (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-90) ClassNotFoundException when a backup server fails over after having failed back
Date Tue, 16 Jun 2015 22:28:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14588912#comment-14588912
] 

clebert suconic commented on ARTEMIS-90:
----------------------------------------

I would create a method to getTransportFactory on the ServiceRegistry, and cache previous
instances on our implementation.

Any modular classLoader application server could then decide how to deal with it.

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

Mime
View raw message