Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Not A Problem
-
5.5.1, 5.6.0
-
None
-
None
-
Red Hat Enterprise Linux Server 5.8
Description
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.