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

Reply via email to