[
https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62803#action_62803
]
Dirk Alexander Schäfer edited comment on AMQ-2901 at 10/25/10 5:48 AM:
-----------------------------------------------------------------------
the following looks interessting to me, too. we've got a durable topic consumer
configured in our muleInstanze. once the broker dies the durable topic consumer
is connected to, the consumer tries to reconnect and gets forwarded to the
second broker by the load balancer. the second broker than refuses the
connection because it thinks that there is allready a client using the specific
durable topic consumer id. this looks to me like the second broker does not
know that the first one has died and therefore does not clean up the clientIds
which it knows that are used for connections to the first broker.
heres the log entry from our mule instance:
ERROR 2010-10-25 08:46:35,081 [ActiveMQ Connection Executor:
tcp:///w.x.y.z:61616] [] [] org.mule.retry.notifiers.ConnectNotifier: Failed to
connect/reconnect: jms://topic:our.cool.topic. Root Exception was: Durable
consumer is in use for client:
ourSystem.activemq-connector.f542389b-624a-4eec-85a7-cecadb5ec4ae and
subscriptionName:
our.durable.topic.consumer#f542399b-624a-4eec-85a7-cecadb2ec4ae(JMS Code:
null). Type: class javax.jms.JMSException
was (Author: dialsc):
the following looks interessting to me, too. we've got a durable topic
consumer configured in our muleInstanze. once the broker dies the durable topic
consumer is connected to, the consumer tries to reconnect and gets forwarded to
the second broker by the load balancer. the second broker than refuses the
connection because it thinks that there is allready a client using the specific
durable topic consumer id. for me this looks like the second broker does not
know that the first one has died and therefore does not clean up the clientIds
which it knows that are used for connections to the first broker.
heres the log entry from our mule instance:
ERROR 2010-10-25 08:46:35,081 [ActiveMQ Connection Executor:
tcp:///w.x.y.z:61616] [] [] org.mule.retry.notifiers.ConnectNotifier: Failed to
connect/reconnect: jms://topic:our.cool.topic. Root Exception was: Durable
consumer is in use for client:
ourSystem.activemq-connector.f542389b-624a-4eec-85a7-cecadb5ec4ae and
subscriptionName:
our.durable.topic.consumer#f542399b-624a-4eec-85a7-cecadb2ec4ae(JMS Code:
null). Type: class javax.jms.JMSException
> Repeating error of client on reconnect
> --------------------------------------
>
> Key: AMQ-2901
> URL: https://issues.apache.org/activemq/browse/AMQ-2901
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMS client
> Affects Versions: 5.4.0
> Environment: redhat linux; java 1.6
> Reporter: Dirk Alexander Schäfer
> Attachments: activemq.xml
>
>
> recently we upgraded our activeMq instanzes from 5.3.1 to 5.4.0. we also
> upgraded the client API used in our mule-based services. since that upgrade
> we are facing with strange reconnet errors. we have a network of brokers with
> two instances. they are located behinde a hardware loadbalancer over which
> our clients connect to the brokers. if we restart one of the brokers, the
> clients connected to it perform a reconnect and are getting linked to the
> other broker. in our services we use a lot of queues and topics.
> it seems that some topics are unable to reconnect randomly. on one of our
> client machines the reconnect to a durable topic wasn't possible anymore
> (Root Exception was: Durable consumer is in use for client:
> myUniqueConnectorName and subscriptionName: myDurableSubscriberName(JMS Code:
> null). Type: class javax.jms.JMSException ). on the other machine a reconnect
> to another, non-durable topic (Root Exception was: Channel was inactive for
> too long: /w.x.y.z:61616. Type: class
> org.apache.activemq.transport.InactivityIOException ). they did not reconnect
> at all until the services were restarted.
> we were not having this problems with the version 5.3.1.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
