Ronny H. Ringen created AMQ-4348:
------------------------------------
Summary: Consumer not detecting broker restart
Key: AMQ-4348
URL: https://issues.apache.org/jira/browse/AMQ-4348
Project: ActiveMQ
Issue Type: Bug
Components: Connector
Affects Versions: 5.6.0, 5.5.1
Environment: Red Hat Enterprise Linux Server 5.8
Reporter: Ronny H. Ringen
This seems to be more or less identical to AMQ-1722
We run the AMQ 5.5.1 broker and our JEE/Spring application runs in Jboss 7.1.1
and uses the 5.6.0 version of the activemq-all/activemq-core packages.
(also Spring 3.0.5 and Bitronix 2.1.3 for transactions)
I start up the broker, then Jboss, once everything is up, I use mbeans to start
the application picking matching rows from the DB and creating messages (there
are 14 queues and associated DLQ queues working in a chain where the consumer
of one queue is the producer for the next.)
In order to test how it handles errors I shut the broker down, then after some
time (from a few seconds to a few minutes).
Startup (tried with inactivity monitor due to suggestions in AMQ-1722, it had
no effect)
[org.apache.activemq.transport.failover.FailoverTransport] [JBOSS_AS]
Successfully connected to
tcp://<host>:14421?wireFormat.maxInactivityDuration=30000
Stopped AMQ
[ActiveMQ Transport: tcp://<host>/<ip>:14421]
[org.apache.activemq.transport.failover.FailoverTransport] [JBOSS_AS] Transport
(tcp://<ip>:14421) failed, reason: java.io.EOFException, attempting to
automatically reconnect
the bitronix transactions time out
3 minutes later, and
org.apache.activemq.SimplePriorityMessageDispatchChannel.closed is still false
start amq again
[ActiveMQ Task-29] [org.apache.activemq.transport.failover.FailoverTransport]
[JBOSS_AS] Successfully connected to
tcp://<host>:14421?wireFormat.maxInactivityDuration=30000
[bitronix-recovery-thread] [bitronix.tm.recovery.Recoverer] [JBOSS_AS]
recoverer is already running, abandoning this recovery request
Then the system handles 55 messages before stopping (assume these are
prefetched messages), more AMQ restarts makes it handle a variable amount of
messages (tried 2 more restarts, first one was 13 messages, then 2)
After these the
org.springframework.jms.listener.DefaultMessageListenerContainer stops
recieving message events and the SimplePriorityMessageDispatchChannel
unconsumedMessages in ActiveMQMessageConsumer insists all the queues are of
size 0, while jconsole shows that they have plenty messages.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira