ActiveMQ
  1. ActiveMQ
  2. AMQ-1376

Improperly closed connections preventing message redelivery

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 5.0.0
    • Fix Version/s: AGING_TO_DIE
    • Component/s: Transport
    • Labels:
      None

      Description

      This is a reproducible case of a DEAD Consumer that never gets cleaned up.

      I am using telnet to manually test STOMP message consumption.

      First I put a message into the queue

      I then connect and subscribe to that queue and get the message:

      CONNECT
      login: test
      passcode: test

      ^@
      CONNECTED
      session:ID:jacob-64807-1188509209664-4:3

      SUBSCRIBE
      destination: /queue/Prescriptions
      ack: client

      ^@

      This works and I receive the queued messages.
      They remain in the Q because I am not send ACK

      If I use the DISCONNECT command. I am properly disconnected and I can repeat this process to get the same message again. Good.

      If I disconnect by killing the telnet process I see the following stack trace in MQ. AND I can still repeat the same process of re-retrieving the un-acknowledged messages:
      DEBUG Transport - Transport failed: java.io.EOFException
      java.io.EOFException
      at java.io.DataInputStream.readByte(DataInputStream.java:243)
      at org.apache.activemq.transport.stomp.StompWireFormat.readLine(StompWireFormat.java:186)
      at org.apache.activemq.transport.stomp.StompWireFormat.unmarshal(StompWireFormat.java:94)
      at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:196)
      at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:188)
      at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:176)
      at java.lang.Thread.run(Thread.java:613)
      DEBUG TransportConnection - Stopping connection: /XXXXXXXXXXXXXX:4880
      DEBUG TcpTransport - Stopping transport tcp:///XXXXXXXXXXXXXX:4880
      DEBUG TransportConnection - Stopped connection: /XXXXXXXXXXXXXX:4880
      DEBUG TransportConnection - Cleaning up connection resources: /XXXXXXXXXXXXXX:4880
      DEBUG AMQPersistenceAdapter - Checkpoint started.
      DEBUG AMQPersistenceAdapter - Checkpoint done.

      HOWEVER,
      If I disconnect by repeatedly typing Control-C to close the telnet program I see the following stack trace:
      DEBUG Transport - Transport failed: org.apache.activemq.transport.stomp.ProtocolException: Unable to parser header line [????????????]
      org.apache.activemq.transport.stomp.ProtocolException: Unable to parser header line [????????????]
      at org.apache.activemq.transport.stomp.StompWireFormat.unmarshal(StompWireFormat.java:121)
      at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:196)
      at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:188)
      at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:176)
      at java.lang.Thread.run(Thread.java:613)
      DEBUG TransportConnection - Stopping connection: /XXXXXXXXXXXXXX:64820
      DEBUG TcpTransport - Stopping transport tcp:///XXXXXXXXXXXXXX:64820
      DEBUG AMQPersistenceAdapter - Checkpoint started.
      DEBUG AMQPersistenceAdapter - Checkpoint done.

      AND, I am no longer able to retrieve the queued up messages. Looking at the admin console I see Number Of Consumers = 1, leading me to believe that ActiveMQ didn't properly handle the disconnection. In the other 2 cases (DISCONNECT and kill) the "Number Of Consumers" drops to zero on connection termination.

      I believe the correct behavior should be to properly handle and clean-up the connection on bad data. Or perhaps periodically check each of the supposed "Consumers" to make sure that they are still alive. This is clearly a reproducible case of a DEAD Consumer that never gets cleaned up.

      Comparing the DEBUG output the follows the 2 stack traces, it is clear in the second case that ActiveMQ fails to clean up the connections resources for the unexpectedly disconnected consumer.

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Hiram Chirino
            Reporter:
            Jacob Burkhart
          • Votes:
            8 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development