You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org> on 2010/09/07 12:53:40 UTC
[jira] Created: (AMQ-2901) Repeating error of client on reconnect
Repeating error of client on reconnect
--------------------------------------
Key: AMQ-2901
URL: https://issues.apache.org/activemq/browse/AMQ-2901
Project: ActiveMQ
Issue Type: Bug
Affects Versions: 5.4.0
Environment: redhat linux; java 1.6
Reporter: Dirk Alexander Schäfer
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.
[jira] Issue Comment Edited: (AMQ-2901) Repeating error of client
on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ 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 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. 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
> 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.
[jira] Commented: (AMQ-2901) Repeating error of client on reconnect
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61750#action_61750 ]
Gary Tully commented on AMQ-2901:
---------------------------------
are you using the failover: transport on the Mule side to connect to activemq?
> 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.
[jira] Issue Comment Edited: (AMQ-2901) Repeating error of client
on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Issue Comment Edited: (AMQ-2901) Repeating error of client
on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ 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:47 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. 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
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.
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.
[jira] Updated: (AMQ-2901) Repeating error of client on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dirk Alexander Schäfer updated AMQ-2901:
----------------------------------------
Component/s: Broker
JMS client
> 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
>
> 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.
[jira] Issue Comment Edited: (AMQ-2901) Repeating error of client
on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61787#action_61787 ]
Dirk Alexander Schäfer edited comment on AMQ-2901 at 10/25/10 5:43 AM:
-----------------------------------------------------------------------
no we don't. mule implements its own reconnect strategy by using the mul retryPolicies construct.
was (Author: dialsc):
no we don't. mule implements its own reconnect strategy by using the mul eretryPolicies construct.
> 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.
[jira] Commented: (AMQ-2901) Repeating error of client on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61717#action_61717 ]
Dirk Alexander Schäfer commented on AMQ-2901:
---------------------------------------------
here is an example error logged at one of our mule instances. it's allways the same error that gets logged:
ERROR 2010-09-07 04:03:26,844 [ActiveMQ Connection Executor: tcp:///w.x.y.z:61616] [] [] org.mule.retry.notifiers.ConnectNotifier: Failed to connect/reconnect: jms://topic:my.app.topic
Root Exception was: Channel was inactive for too long: /w.x.y.z:61616. Type: class org.apache.activemq.transport.InactivityIOException
i cannot find any error log entry in the logs of the activemq brokers that look to be related to this problem. the xml config of the broker is attached. for the client i do not have one beside the mule configuration. do you want to see this, too?
> 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
>
> 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.
[jira] Updated: (AMQ-2901) Repeating error of client on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dirk Alexander Schäfer updated AMQ-2901:
----------------------------------------
Attachment: activemq.xml
> 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.
[jira] Commented: (AMQ-2901) Repeating error of client on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61787#action_61787 ]
Dirk Alexander Schäfer commented on AMQ-2901:
---------------------------------------------
no we don't. mule implements its own reconnect strategy by using the mul eretryPolicies construct.
> 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.
[jira] Commented: (AMQ-2901) Repeating error of client on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ 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 commented on AMQ-2901:
---------------------------------------------
the following looks interessting to me, too. we've got a durable topic cosnumer 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.
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.
[jira] Commented: (AMQ-2901) Repeating error of client on reconnect
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61711#action_61711 ]
Gary Tully commented on AMQ-2901:
---------------------------------
can you attach the relevant broker and client logs and xml configuration?
> 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
>
> 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.
[jira] Issue Comment Edited: (AMQ-2901) Repeating error of client
on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ 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:50 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 are used for connections to the first broker.
of course the ids used are unique through all instances that are running. 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. 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 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.
[jira] Updated: (AMQ-2901) Repeating error of client on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dirk Alexander Schäfer updated AMQ-2901:
----------------------------------------
Priority: Blocker (was: Major)
facing this problem we are not able to use activeMq as a reliable jms infrastructure....
> 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
> Priority: Blocker
> 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.
[jira] Issue Comment Edited: (AMQ-2901) Repeating error of client
on reconnect
Posted by "Dirk Alexander Schäfer (JIRA)" <ji...@apache.org>.
[ 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:46 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.
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 cosnumer 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.
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.