You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Jacob Burkhart (JIRA)" <ji...@apache.org> on 2007/08/30 23:45:22 UTC
[jira] Created: (AMQ-1376) Improperly closed connections preventing
message redelivery
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.
[jira] Commented: (AMQ-1376) Improperly closed connections
preventing message redelivery
Posted by "Vipul Kothiyal (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=56329#action_56329 ]
Vipul Kothiyal commented on AMQ-1376:
-------------------------------------
This problem still persists with 5.3.0, MQ doesn't close teh connection cleanly.
2009-12-08 17:00:07,762 | DEBUG | Stopped transport: /10.52.68.200:37123 | org.apache.activemq.broker.TransportConnection | ActiveMQ Transport Stopper: /10.52.68.200:37123
2009-12-08 17:00:07,762 | DEBUG | Cleaning up connection resources: /10.52.68.200:37123 | org.apache.activemq.broker.TransportConnection | ActiveMQ Transport Stopper: /10.52.68.200:37123
2009-12-08 17:00:07,762 | DEBUG | Connection Stopped: /10.52.68.200:37123 | org.apache.activemq.broker.TransportConnection | ActiveMQ Transport Stopper: /10.52.68.200:37123
2009-12-08 17:00:07,763 | DEBUG | Transport failed: java.io.EOFException | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: tcp:///10.52.68.200:37122
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:210)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:202)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:185)
at java.lang.Thread.run(Thread.java:595)
> 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
> 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.
[jira] Commented: (AMQ-1376) Improperly closed connections
preventing message redelivery
Posted by "Roger Hoover (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Assigned: (AMQ-1376) Improperly closed connections
preventing message redelivery
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hiram Chirino reassigned AMQ-1376:
----------------------------------
Assignee: Hiram Chirino
> 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
> Assignee: Hiram Chirino
>
> 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.
[jira] Commented: (AMQ-1376) Improperly closed connections
preventing message redelivery
Posted by "Bruce Snyder (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=55645#action_55645 ]
Bruce Snyder commented on AMQ-1376:
-----------------------------------
Please provide feedback regarding this issue and whether it been fixed in the latest release of ActiveMQ (5.3). If there is no feedback, this issue will be closed.
> 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
> 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.
[jira] Commented: (AMQ-1376) Improperly closed connections
preventing message redelivery
Posted by "Hiram Chirino (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=42112#action_42112 ]
Hiram Chirino commented on AMQ-1376:
------------------------------------
I believe that the improved connection shutdown code in the current trunk should resolve this issue. Could you re-test against trunk and let me know if you still see the same thing?
> 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.
[jira] Commented: (AMQ-1376) Improperly closed connections
preventing message redelivery
Posted by "Sergey Rem (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=62332#action_62332 ]
Sergey Rem commented on AMQ-1376:
---------------------------------
May be it exists also in 5.4.0 and in 5.4.1. After one wrong action this exception will be written in log without stop: but all messages will be processed in the same time also... only log file is growing!
2010-10-04 18:17:57,649 | INFO | Transport failed: java.io.EOFException | org.apache.activemq.broker.TransportConnection.Transport | ActiveMQ Transport: tcp:///172.16.1.25:24396
java.io.EOFException
at java.io.DataInputStream.readByte(DataInputStream.java:243)
at org.apache.activemq.transport.stomp.StompWireFormat.readLine(StompWireFormat.java:146)
at org.apache.activemq.transport.stomp.StompWireFormat.parseAction(StompWireFormat.java:162)
at org.apache.activemq.transport.stomp.StompWireFormat.unmarshal(StompWireFormat.java:92)
at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:226)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:218)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:201)
at java.lang.Thread.run(Thread.java:595)
> 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
> 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.