Uploaded image for project: 'ActiveMQ'
  1. ActiveMQ
  2. AMQ-4348

Consumer not detecting broker restart



    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Not A Problem
    • Affects Version/s: 5.5.1, 5.6.0
    • Fix Version/s: None
    • Component/s: Connector
    • Labels:
    • Environment:

      Red Hat Enterprise Linux Server 5.8


      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.




            • Assignee:
              moridin Ronny H. Ringen
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: