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

Consumer not detecting broker restart

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Not A Problem
    • 5.5.1, 5.6.0
    • None
    • Connector
    • 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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            moridin Ronny H. Ringen
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: