You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by James Strachan <ja...@gmail.com> on 2006/08/25 10:24:53 UTC
Re: Connection lost in JMS to JMS Bridge scenario.
On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
>
> Hello and sorry for the previous message, it seems I pressed the wrong
> button.
>
>
> I'm using ActiveMQ JMS to JMS Bridge functionality to connect to a SunMQ
> JMS Broker (3.6 SP3 (Build 02-A)). I'm using two queues, an input and an
> output one, with the following configuration:
>
>
> <jmsBridgeConnectors>
> <jmsQueueConnector
> outboundQueueConnectionFactory="#REMOTE">
> <outboundQueueBridges>
> <outboundQueueBridge outboundQueueName="SUNRECV"/>
> </outboundQueueBridges>
> <inboundQueueBridges>
> <inboundQueueBridge inboundQueueName="SUNSEND"/>
> </inboundQueueBridges>
> </jmsQueueConnector>
> </jmsBridgeConnectors>
>
> under ActiveMQ 4.0.1
>
> The system works really well until the SunMQ broker needed to be restarted.
> This is what I found:
> 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a
> while, but no log on ActiveMQ indicates knowledge about the new situation.
> 2.-When I send a message to the output queue SUNRECV, ActiveMQ complains
> that the producer is closed:
>
> [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to forward
> message: ActiveMQTextMessage {commandId = 5, responseRequired = false,
> messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1,
> originalDestination = null, originalTransactionId = null, producerId =
> ID:trabucco-43457-1156491843149-3:4:1:1, destination =
> queue://SUNRECV, transactionId = null, expiration = 0, timestamp =
> 1156492032027, arrival = 0, correlationId = null, replyTo = null, persistent
> = false, type = null, priority = 0, groupID = null, groupSequence = 0,
> targetConsumerId = null, compressed = false, userID = null, content = null,
> marshalledProperties = null, dataStructure = null, redeliveryCounter = 0,
> size = 2, properties = null, readOnlyProperties = true, readOnlyBody = true,
> text = 1}([C4064]: Cannot perform operation, producer is closed.)
>
> After this, it is automatically queueing messages without sending them,
> showing the log:
>
> [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No
> subscriptions registered, will not dispatch message at this time.
>
> Even if SunMQ is started again, ActiveMQ is not detecting the new
> situation, and continues queueing messages sent to SUNRECV.
>
> 3.-Once I restart ActiveMQ broker (with SunMQ previously restarted) two
> things can happen:
> a.-ActiveMQ sends the previously queued messages to SunMQ. I can find
> SUNRECV queue in the 'queues' section of the jmx console with the correct
> number of dequeued messages.
> b.-ActiveMQ sends nothing to SunMQ. The jmx console doesn't show the
> bridged queue, however, there's an advisory topic called:
> ActiveMQ.Advisory.Consumer.Queue.SUNRECV.
> When a new message is sent to SUNRECV, the queue is created in
> ActiveMQ, but the old messages seems to be lost (The jmx console shows 1 for
> the Enqueue and Dequeue count and SunMQ shows one message in its queue).
>
>
> This situation is far from desired. So, I would like to know:
> -Is there any way to make ActiveMQ broker test the bridge connection state?
No not really
> Is there any way to force a reconnection?
If a send fails we should tear down and reconnect the producer. Could
you raise a JIRA for this please?
> -Should ActiveMQ detect the remote side shutdown?
It can't really - all it can do is respond to the send/consume failing
--
James
-------
http://radio.weblogs.com/0112098/
Re: Connection lost in JMS to JMS Bridge scenario.
Posted by James Strachan <ja...@gmail.com>.
On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
> James Strachan escribió:
> > So a few things going on here.
> >
> > * on a restart not all queues appear in JMX until they are actually
> > used. This page describes why along with explaining how to work around
> > this
> > http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html
> >
> Anyway, it seems that if there are messages in the database for the
> SUNRECV queue, it is created by ActiveMQ on restart. With the cases:
> 1.-The messages are sent to the bridged broker.
> 2.-The messages are not sent to the bridged broker, and on a new message
> arriving, older are dropped.
>
> I find (2) to be a problem.
I don't understand what (2) means. Could you try explain that again please?
> > * the database is not always in sync with the broker as we use a high
> > performance journal; so the database is checkpointed periodically and
> > is usually a bit behind the broker. You can avoid this by disabling
> > the high performance journal (but its pretty slow to do that). Here's
> > an example config if you want
> > http://incubator.apache.org/activemq/jdbc-master-slave.html
>
> Well, I've found the reason for this. It's because messages sent with
> the JMX sendTextMessage operation are not persistent, and that's the
> reason they're not inserted in the database (I think).
I don't follow. Persistence is defined not by the type of the message
but by the deliveryMode of the MessageProducer
> > BTW I looked at the code for the JMS bridge and if a connection is
> > lost with the remote broker, the bridge just stops - so no messages
> > should be lost. Though it will require a bounce of the broker to
> > reconnect.
> I'm going to open a JIRA for this.
Great
--
James
-------
http://radio.weblogs.com/0112098/
Re: Connection lost in JMS to JMS Bridge scenario.
Posted by Manuel Teira <mt...@tid.es>.
James Strachan escribió:
> So a few things going on here.
>
> * on a restart not all queues appear in JMX until they are actually
> used. This page describes why along with explaining how to work around
> this
> http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html
>
Anyway, it seems that if there are messages in the database for the
SUNRECV queue, it is created by ActiveMQ on restart. With the cases:
1.-The messages are sent to the bridged broker.
2.-The messages are not sent to the bridged broker, and on a new message
arriving, older are dropped.
I find (2) to be a problem.
>
> * the database is not always in sync with the broker as we use a high
> performance journal; so the database is checkpointed periodically and
> is usually a bit behind the broker. You can avoid this by disabling
> the high performance journal (but its pretty slow to do that). Here's
> an example config if you want
> http://incubator.apache.org/activemq/jdbc-master-slave.html
Well, I've found the reason for this. It's because messages sent with
the JMX sendTextMessage operation are not persistent, and that's the
reason they're not inserted in the database (I think).
>
> BTW I looked at the code for the JMS bridge and if a connection is
> lost with the remote broker, the bridge just stops - so no messages
> should be lost. Though it will require a bounce of the broker to
> reconnect.
I'm going to open a JIRA for this.
Thanks a lot.
>
>
> On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
>> Thanks for your fast answer. Looking further into my problem, I was
>> inspecting the ACTIVEMQ_MSGS database table used as persistence for
>> messages:
>>
>> Starting with the remote SunMQ down:
>>
>> In the beginning:
>>
>> SQL> select count(*) from ACTIVEMQ_MSGS where
>> container='queue://SUNRECV';
>>
>> COUNT(*)
>> ----------
>> 0
>>
>> When I send a message to the queue using the JMX console queue operation
>> sendTextMessage, I can see the logs talking about trying to send the
>> message. The JMX console shows a QueueSize of 1 for SUNRECV queue, but
>> in the Database, I still have the same count of zero messages.
>>
>> If I send a message to the queue using an external client:
>>
>> SQL> select count(*) from ACTIVEMQ_MSGS where
>> container='queue://SUNRECV';
>>
>> COUNT(*)
>> ----------
>> 1
>>
>>
>> And the JMX console is now showing a QueueSize of 2.
>>
>>
>> Therefore, on restarting the two brokers, I find these cases:
>> 1.-SUNRECV queue doesn't exist in ActiveMQ. This seems to be related
>> with the fact to have sent the messages using the JMX console.
>> 2.-SUNRECV queue exists in ActiveMQ with the same number of messages the
>> DB was holding on restart. For whatever reason these messages are not
>> sent to SunMQ broker. When a new message hits this queue, old messages
>> are lost and the new one reaches SunMQ (the DequeueCount shown in the
>> JMX console is however right (old + new)).
>> 3.-SUNRECV queue exists in ActiveMQ and all the messages where sent to
>> the SunMQ broker.
>>
>>
>> Should we consider this a different problem or the same one?
>> Do you think one JIRA is enough for this?
>>
>> Regards.
>>
>>
>>
>>
>> James Strachan escribió:
>> > On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
>> >>
>> >> Hello and sorry for the previous message, it seems I pressed the
>> wrong
>> >> button.
>> >>
>> >>
>> >> I'm using ActiveMQ JMS to JMS Bridge functionality to connect to a
>> >> SunMQ
>> >> JMS Broker (3.6 SP3 (Build 02-A)). I'm using two queues, an input
>> >> and an
>> >> output one, with the following configuration:
>> >>
>> >>
>> >> <jmsBridgeConnectors>
>> >> <jmsQueueConnector
>> >> outboundQueueConnectionFactory="#REMOTE">
>> >> <outboundQueueBridges>
>> >> <outboundQueueBridge outboundQueueName="SUNRECV"/>
>> >> </outboundQueueBridges>
>> >> <inboundQueueBridges>
>> >> <inboundQueueBridge inboundQueueName="SUNSEND"/>
>> >> </inboundQueueBridges>
>> >> </jmsQueueConnector>
>> >> </jmsBridgeConnectors>
>> >>
>> >> under ActiveMQ 4.0.1
>> >>
>> >> The system works really well until the SunMQ broker needed to be
>> >> restarted.
>> >> This is what I found:
>> >> 1.-ActiveMQ is not aware of the remote broker shutdown. I waited
>> for a
>> >> while, but no log on ActiveMQ indicates knowledge about the new
>> >> situation.
>> >> 2.-When I send a message to the output queue SUNRECV, ActiveMQ
>> >> complains
>> >> that the producer is closed:
>> >>
>> >> [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to
>> >> forward
>> >> message: ActiveMQTextMessage {commandId = 5, responseRequired =
>> false,
>> >> messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1,
>> >> originalDestination = null, originalTransactionId = null,
>> producerId =
>> >> ID:trabucco-43457-1156491843149-3:4:1:1, destination =
>> >> queue://SUNRECV, transactionId = null, expiration = 0, timestamp =
>> >> 1156492032027, arrival = 0, correlationId = null, replyTo = null,
>> >> persistent
>> >> = false, type = null, priority = 0, groupID = null, groupSequence
>> = 0,
>> >> targetConsumerId = null, compressed = false, userID = null, content =
>> >> null,
>> >> marshalledProperties = null, dataStructure = null, redeliveryCounter
>> >> = 0,
>> >> size = 2, properties = null, readOnlyProperties = true, readOnlyBody
>> >> = true,
>> >> text = 1}([C4064]: Cannot perform operation, producer is closed.)
>> >>
>> >> After this, it is automatically queueing messages without sending
>> >> them,
>> >> showing the log:
>> >>
>> >> [DEBUG][2006/08/25.09:47:42.721][RMI TCP
>> Connection(4)-10.95.89.20]No
>> >> subscriptions registered, will not dispatch message at this time.
>> >>
>> >> Even if SunMQ is started again, ActiveMQ is not detecting the new
>> >> situation, and continues queueing messages sent to SUNRECV.
>> >>
>> >> 3.-Once I restart ActiveMQ broker (with SunMQ previously
>> restarted) two
>> >> things can happen:
>> >> a.-ActiveMQ sends the previously queued messages to SunMQ. I
>> can find
>> >> SUNRECV queue in the 'queues' section of the jmx console with the
>> >> correct
>> >> number of dequeued messages.
>> >> b.-ActiveMQ sends nothing to SunMQ. The jmx console doesn't
>> show the
>> >> bridged queue, however, there's an advisory topic called:
>> >> ActiveMQ.Advisory.Consumer.Queue.SUNRECV.
>> >> When a new message is sent to SUNRECV, the queue is created in
>> >> ActiveMQ, but the old messages seems to be lost (The jmx console
>> >> shows 1 for
>> >> the Enqueue and Dequeue count and SunMQ shows one message in its
>> queue).
>> >>
>> >>
>> >> This situation is far from desired. So, I would like to know:
>> >> -Is there any way to make ActiveMQ broker test the bridge connection
>> >> state?
>> >
>> > No not really
>> >
>> >> Is there any way to force a reconnection?
>> >
>> > If a send fails we should tear down and reconnect the producer. Could
>> > you raise a JIRA for this please?
>> >
>> >
>> >> -Should ActiveMQ detect the remote side shutdown?
>> >
>> > It can't really - all it can do is respond to the send/consume failing
>> >
>>
>>
>
>
Re: Connection lost in JMS to JMS Bridge scenario.
Posted by James Strachan <ja...@gmail.com>.
So a few things going on here.
* on a restart not all queues appear in JMX until they are actually
used. This page describes why along with explaining how to work around
this
http://incubator.apache.org/activemq/how-do-i-create-new-destinations.html
* the database is not always in sync with the broker as we use a high
performance journal; so the database is checkpointed periodically and
is usually a bit behind the broker. You can avoid this by disabling
the high performance journal (but its pretty slow to do that). Here's
an example config if you want
http://incubator.apache.org/activemq/jdbc-master-slave.html
BTW I looked at the code for the JMS bridge and if a connection is
lost with the remote broker, the bridge just stops - so no messages
should be lost. Though it will require a bounce of the broker to
reconnect.
On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
> Thanks for your fast answer. Looking further into my problem, I was
> inspecting the ACTIVEMQ_MSGS database table used as persistence for
> messages:
>
> Starting with the remote SunMQ down:
>
> In the beginning:
>
> SQL> select count(*) from ACTIVEMQ_MSGS where container='queue://SUNRECV';
>
> COUNT(*)
> ----------
> 0
>
> When I send a message to the queue using the JMX console queue operation
> sendTextMessage, I can see the logs talking about trying to send the
> message. The JMX console shows a QueueSize of 1 for SUNRECV queue, but
> in the Database, I still have the same count of zero messages.
>
> If I send a message to the queue using an external client:
>
> SQL> select count(*) from ACTIVEMQ_MSGS where container='queue://SUNRECV';
>
> COUNT(*)
> ----------
> 1
>
>
> And the JMX console is now showing a QueueSize of 2.
>
>
> Therefore, on restarting the two brokers, I find these cases:
> 1.-SUNRECV queue doesn't exist in ActiveMQ. This seems to be related
> with the fact to have sent the messages using the JMX console.
> 2.-SUNRECV queue exists in ActiveMQ with the same number of messages the
> DB was holding on restart. For whatever reason these messages are not
> sent to SunMQ broker. When a new message hits this queue, old messages
> are lost and the new one reaches SunMQ (the DequeueCount shown in the
> JMX console is however right (old + new)).
> 3.-SUNRECV queue exists in ActiveMQ and all the messages where sent to
> the SunMQ broker.
>
>
> Should we consider this a different problem or the same one?
> Do you think one JIRA is enough for this?
>
> Regards.
>
>
>
>
> James Strachan escribió:
> > On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
> >>
> >> Hello and sorry for the previous message, it seems I pressed the wrong
> >> button.
> >>
> >>
> >> I'm using ActiveMQ JMS to JMS Bridge functionality to connect to a
> >> SunMQ
> >> JMS Broker (3.6 SP3 (Build 02-A)). I'm using two queues, an input
> >> and an
> >> output one, with the following configuration:
> >>
> >>
> >> <jmsBridgeConnectors>
> >> <jmsQueueConnector
> >> outboundQueueConnectionFactory="#REMOTE">
> >> <outboundQueueBridges>
> >> <outboundQueueBridge outboundQueueName="SUNRECV"/>
> >> </outboundQueueBridges>
> >> <inboundQueueBridges>
> >> <inboundQueueBridge inboundQueueName="SUNSEND"/>
> >> </inboundQueueBridges>
> >> </jmsQueueConnector>
> >> </jmsBridgeConnectors>
> >>
> >> under ActiveMQ 4.0.1
> >>
> >> The system works really well until the SunMQ broker needed to be
> >> restarted.
> >> This is what I found:
> >> 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a
> >> while, but no log on ActiveMQ indicates knowledge about the new
> >> situation.
> >> 2.-When I send a message to the output queue SUNRECV, ActiveMQ
> >> complains
> >> that the producer is closed:
> >>
> >> [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to
> >> forward
> >> message: ActiveMQTextMessage {commandId = 5, responseRequired = false,
> >> messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1,
> >> originalDestination = null, originalTransactionId = null, producerId =
> >> ID:trabucco-43457-1156491843149-3:4:1:1, destination =
> >> queue://SUNRECV, transactionId = null, expiration = 0, timestamp =
> >> 1156492032027, arrival = 0, correlationId = null, replyTo = null,
> >> persistent
> >> = false, type = null, priority = 0, groupID = null, groupSequence = 0,
> >> targetConsumerId = null, compressed = false, userID = null, content =
> >> null,
> >> marshalledProperties = null, dataStructure = null, redeliveryCounter
> >> = 0,
> >> size = 2, properties = null, readOnlyProperties = true, readOnlyBody
> >> = true,
> >> text = 1}([C4064]: Cannot perform operation, producer is closed.)
> >>
> >> After this, it is automatically queueing messages without sending
> >> them,
> >> showing the log:
> >>
> >> [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No
> >> subscriptions registered, will not dispatch message at this time.
> >>
> >> Even if SunMQ is started again, ActiveMQ is not detecting the new
> >> situation, and continues queueing messages sent to SUNRECV.
> >>
> >> 3.-Once I restart ActiveMQ broker (with SunMQ previously restarted) two
> >> things can happen:
> >> a.-ActiveMQ sends the previously queued messages to SunMQ. I can find
> >> SUNRECV queue in the 'queues' section of the jmx console with the
> >> correct
> >> number of dequeued messages.
> >> b.-ActiveMQ sends nothing to SunMQ. The jmx console doesn't show the
> >> bridged queue, however, there's an advisory topic called:
> >> ActiveMQ.Advisory.Consumer.Queue.SUNRECV.
> >> When a new message is sent to SUNRECV, the queue is created in
> >> ActiveMQ, but the old messages seems to be lost (The jmx console
> >> shows 1 for
> >> the Enqueue and Dequeue count and SunMQ shows one message in its queue).
> >>
> >>
> >> This situation is far from desired. So, I would like to know:
> >> -Is there any way to make ActiveMQ broker test the bridge connection
> >> state?
> >
> > No not really
> >
> >> Is there any way to force a reconnection?
> >
> > If a send fails we should tear down and reconnect the producer. Could
> > you raise a JIRA for this please?
> >
> >
> >> -Should ActiveMQ detect the remote side shutdown?
> >
> > It can't really - all it can do is respond to the send/consume failing
> >
>
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: Connection lost in JMS to JMS Bridge scenario.
Posted by Manuel Teira <mt...@tid.es>.
Thanks for your fast answer. Looking further into my problem, I was
inspecting the ACTIVEMQ_MSGS database table used as persistence for
messages:
Starting with the remote SunMQ down:
In the beginning:
SQL> select count(*) from ACTIVEMQ_MSGS where container='queue://SUNRECV';
COUNT(*)
----------
0
When I send a message to the queue using the JMX console queue operation
sendTextMessage, I can see the logs talking about trying to send the
message. The JMX console shows a QueueSize of 1 for SUNRECV queue, but
in the Database, I still have the same count of zero messages.
If I send a message to the queue using an external client:
SQL> select count(*) from ACTIVEMQ_MSGS where container='queue://SUNRECV';
COUNT(*)
----------
1
And the JMX console is now showing a QueueSize of 2.
Therefore, on restarting the two brokers, I find these cases:
1.-SUNRECV queue doesn't exist in ActiveMQ. This seems to be related
with the fact to have sent the messages using the JMX console.
2.-SUNRECV queue exists in ActiveMQ with the same number of messages the
DB was holding on restart. For whatever reason these messages are not
sent to SunMQ broker. When a new message hits this queue, old messages
are lost and the new one reaches SunMQ (the DequeueCount shown in the
JMX console is however right (old + new)).
3.-SUNRECV queue exists in ActiveMQ and all the messages where sent to
the SunMQ broker.
Should we consider this a different problem or the same one?
Do you think one JIRA is enough for this?
Regards.
James Strachan escribió:
> On 8/25/06, Manuel Teira <mt...@tid.es> wrote:
>>
>> Hello and sorry for the previous message, it seems I pressed the wrong
>> button.
>>
>>
>> I'm using ActiveMQ JMS to JMS Bridge functionality to connect to a
>> SunMQ
>> JMS Broker (3.6 SP3 (Build 02-A)). I'm using two queues, an input
>> and an
>> output one, with the following configuration:
>>
>>
>> <jmsBridgeConnectors>
>> <jmsQueueConnector
>> outboundQueueConnectionFactory="#REMOTE">
>> <outboundQueueBridges>
>> <outboundQueueBridge outboundQueueName="SUNRECV"/>
>> </outboundQueueBridges>
>> <inboundQueueBridges>
>> <inboundQueueBridge inboundQueueName="SUNSEND"/>
>> </inboundQueueBridges>
>> </jmsQueueConnector>
>> </jmsBridgeConnectors>
>>
>> under ActiveMQ 4.0.1
>>
>> The system works really well until the SunMQ broker needed to be
>> restarted.
>> This is what I found:
>> 1.-ActiveMQ is not aware of the remote broker shutdown. I waited for a
>> while, but no log on ActiveMQ indicates knowledge about the new
>> situation.
>> 2.-When I send a message to the output queue SUNRECV, ActiveMQ
>> complains
>> that the producer is closed:
>>
>> [ERROR][2006/08/25.09:47:12.039][ActiveMQ Session Task]failed to
>> forward
>> message: ActiveMQTextMessage {commandId = 5, responseRequired = false,
>> messageId = ID:trabucco-43457-1156491843149-3:4:1:1:1,
>> originalDestination = null, originalTransactionId = null, producerId =
>> ID:trabucco-43457-1156491843149-3:4:1:1, destination =
>> queue://SUNRECV, transactionId = null, expiration = 0, timestamp =
>> 1156492032027, arrival = 0, correlationId = null, replyTo = null,
>> persistent
>> = false, type = null, priority = 0, groupID = null, groupSequence = 0,
>> targetConsumerId = null, compressed = false, userID = null, content =
>> null,
>> marshalledProperties = null, dataStructure = null, redeliveryCounter
>> = 0,
>> size = 2, properties = null, readOnlyProperties = true, readOnlyBody
>> = true,
>> text = 1}([C4064]: Cannot perform operation, producer is closed.)
>>
>> After this, it is automatically queueing messages without sending
>> them,
>> showing the log:
>>
>> [DEBUG][2006/08/25.09:47:42.721][RMI TCP Connection(4)-10.95.89.20]No
>> subscriptions registered, will not dispatch message at this time.
>>
>> Even if SunMQ is started again, ActiveMQ is not detecting the new
>> situation, and continues queueing messages sent to SUNRECV.
>>
>> 3.-Once I restart ActiveMQ broker (with SunMQ previously restarted) two
>> things can happen:
>> a.-ActiveMQ sends the previously queued messages to SunMQ. I can find
>> SUNRECV queue in the 'queues' section of the jmx console with the
>> correct
>> number of dequeued messages.
>> b.-ActiveMQ sends nothing to SunMQ. The jmx console doesn't show the
>> bridged queue, however, there's an advisory topic called:
>> ActiveMQ.Advisory.Consumer.Queue.SUNRECV.
>> When a new message is sent to SUNRECV, the queue is created in
>> ActiveMQ, but the old messages seems to be lost (The jmx console
>> shows 1 for
>> the Enqueue and Dequeue count and SunMQ shows one message in its queue).
>>
>>
>> This situation is far from desired. So, I would like to know:
>> -Is there any way to make ActiveMQ broker test the bridge connection
>> state?
>
> No not really
>
>> Is there any way to force a reconnection?
>
> If a send fails we should tear down and reconnect the producer. Could
> you raise a JIRA for this please?
>
>
>> -Should ActiveMQ detect the remote side shutdown?
>
> It can't really - all it can do is respond to the send/consume failing
>