[AMQ-1376] Improperly closed connections preventing message redelivery

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Affects Version/s: 5.0.0
• Fix Version/s: AGING_TO_DIE
• Component/s: Transport
• Assignee: Hiram R. Chirino
• Reporter: Jacob Burkhart
• Created: 30/Aug/07 21:43
• Updated: 05/Jul/11 18:41
• Resolved: 05/Jul/11 18:41

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.