activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1431) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec
Date Mon, 25 Sep 2017 14:36:00 GMT

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

ASF subversion and git services commented on ARTEMIS-1431:
----------------------------------------------------------

Commit 492022618dfd7ef5410c564f4f23c33f0ba33ccb in activemq-artemis's branch refs/heads/1.x
from [~jmesnil]
[ https://git-wip-us.apache.org/repos/asf?p=activemq-artemis.git;h=4920226 ]

[ARTMIS-1431] Adapt transport configuration in ClientProtocolManagerFactory

add the adaptTransportConfiguration() method to the
ClientProtocolManagerFactory so that transport configurations used by
the ClientProtocolManager have an opportunity to adapt their transport
configuration.

This allows the HornetQClientProtocolManagerFactory to adapt the
transport configuration received by remote HornetQ broker to replace the
HornetQ-based NettyConnectorFactory by the Artemis-based one.

JIRA: https://issues.apache.org/jira/browse/ARTEMIS-1431


> AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec
> -------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-1431
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1431
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 1.5.5
>            Reporter: Jeff Mesnil
>
> Use case:
> Artemis 1.5.x Resource adapter that connects to a remote HornetQ broker.
> The RA is configured to use the protocol-manager-factory for HornetQ (protocol-manager-factory="org.apache.activemq.artemis.core.protocol.hornetq.client.HornetQClientProtocolManagerFactory")
and use Artemis remote connector to connect to HornetQ.
> When the RA is activated and its JMS resources are setup, it creates 15 ClientSessions.
> The first one is created without any issue and manage to connect to HornetQ broker.
> However in org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl#getConnection,
it will subscribes to cluster topology from the remote HornetQ broker.
> The HornetQ boker will send back its topology with the remote connector information (that
uses the org.hornetq.core.remoting.impl.netty.NettyConnectorFactory).
> The ServerLocator will be updated to use this topology info instead of the initialConnectors
and 
> subsequent creations of Connection will fail because of the ClassCastException at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl#instantiateConnectorFactory:
> {code}
> 2017-09-18 09:05:14,006 ERROR [org.apache.activemq.artemis.ra] (default-threads - 1)
AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter@3ca2957
destination=inQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null
user=null maxSession=15): java.lang.ClassCastException: org.hornetq.core.remoting.impl.netty.NettyConnectorFactory
cannot be cast to org.apache.activemq.artemis.spi.core.remoting.ConnectorFactory
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$2.run(ClientSessionFactoryImpl.java:952)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl$2.run(ClientSessionFactoryImpl.java:950)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.instantiateConnectorFactory(ClientSessionFactoryImpl.java:950)
> 	at org.apache.activemq.artemis.core.client.impl.ClientSessionFactoryImpl.<init>(ClientSessionFactoryImpl.java:179)
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:757)
> 	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:316)
> 	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:681)
> 	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$SetupActivation.run(ActiveMQActivation.java:725)
> 	at org.jboss.jca.core.workmanager.WorkWrapper.run(WorkWrapper.java:223)
> 	at org.jboss.threads.SimpleDirectExecutor.execute(SimpleDirectExecutor.java:33)
> 	at org.jboss.threads.QueueExecutor.runTask(QueueExecutor.java:808)
> 	at org.jboss.threads.QueueExecutor.access$100(QueueExecutor.java:45)
> 	at org.jboss.threads.QueueExecutor$Worker.run(QueueExecutor.java:828)
> 	at java.lang.Thread.run(Thread.java:748)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> I propose that we enhance the ClientProtocolManagerFactory to handle this case. When
it receives topology (and TransportConfiguration), it should be possible to "adapt" the transport
configuration.
> This would be a no-op for Artemis ClientProtocolManagerFactory but it would allow the
HornetQClientProtocolManagerFactory to adapt its transport configuration to replace the use
of the HornetQ NettyConnectorFactory by the use of the Netty one.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message