Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <20083798.159331294229449593.JavaMail.jira@thor>
Date: Wed, 5 Jan 2011 07:10:49 -0500 (EST)
From: "Martin Rehder (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Commented: (AMQ-1376) Improperly closed connections
 preventing message redelivery
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12977751#action_12977751 ] 

Martin Rehder commented on AMQ-1376:
------------------------------------

It also exists in 5.4.1.

The exception is constantly printed in the console window where AMQ is started from.

> Improperly closed connections preventing message redelivery
> -----------------------------------------------------------
>
>                 Key: AMQ-1376
>                 URL: https://issues.apache.org/jira/browse/AMQ-1376
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.0.0
>            Reporter: Jacob Burkhart
>            Assignee: Hiram Chirino
>             Fix For: AGING_TO_DIE
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.