You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Roger Hoover (JIRA)" <ji...@apache.org> on 2008/03/04 03:41:17 UTC
[jira] Commented: (AMQ-1376) Improperly closed connections
preventing message redelivery
[ https://issues.apache.org/activemq/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=41499#action_41499 ]
Roger Hoover commented on AMQ-1376:
-----------------------------------
This problem doesn't just prevent redelivery. The thread assigned to that STOMP connection never gets released. Over time, these unused threads build up until some limit is reached and broker becomes unresponsive.
> Improperly closed connections preventing message redelivery
> -----------------------------------------------------------
>
> Key: AMQ-1376
> URL: https://issues.apache.org/activemq/browse/AMQ-1376
> Project: ActiveMQ
> Issue Type: Bug
> Components: Transport
> Affects Versions: 5.0.0
> Reporter: Jacob Burkhart
>
> 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.