activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Markus Gerstel (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-6697) Aborting a STOMP 1.1 transaction after ACK/NACK leads to invalid state
Date Fri, 02 Jun 2017 16:44:04 GMT

     [ https://issues.apache.org/jira/browse/AMQ-6697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Markus Gerstel updated AMQ-6697:
--------------------------------
    Description: 
Reproducing the problem:
* Receive a message via STOMP (+EDIT: on a subscription with ack:client-individual+)
* Start a transaction
* ACK (or NACK) the message within the transaction
* Abort the transaction
* ACK (or NACK) the message

Expected behaviour:
* The message is according to step #5 either ACKed or NACKed.

Observed behaviour:
* The message is neither ACKed nor NACKed, but stays in unacknowledged state
* An exception is raised:
 org.apache.activemq.transport.stomp.ProtocolException: Unexpected ACK received for message-id
[ID:(...)]
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompAck(ProtocolConverter.java:475)
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:250)
        at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:85)
        at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
        at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)
        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)
        at java.lang.Thread.run(Thread.java:745)
* an ERROR message is sent to the client

As far as I can tell this is caused by code in both onStompAck() and onStompNack():
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=blob;f=activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java;h=b25860bf6895240c33a8643b6fcc731af126d32e;hb=refs/heads/master#l440

With a STOMP 1.1 ACK/NACK, ackId == null, so the message entry is taken out of this.pedingAcks
(sic!).
When the transaction is aborted the message entry is then not put back into this.pedingAcks,
so any subsequent ACK/NACK will find pendingAck==null, therefore acked==false, raising an
exception.

  was:
Reproducing the problem:
* Receive a message via STOMP
* Start a transaction
* ACK (or NACK) the message within the transaction
* Abort the transaction
* ACK (or NACK) the message

Expected behaviour:
* The message is according to step #5 either ACKed or NACKed.

Observed behaviour:
* The message is neither ACKed nor NACKed, but stays in unacknowledged state
* An exception is raised:
 org.apache.activemq.transport.stomp.ProtocolException: Unexpected ACK received for message-id
[ID:(...)]
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompAck(ProtocolConverter.java:475)
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:250)
        at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:85)
        at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
        at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)
        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)
        at java.lang.Thread.run(Thread.java:745)
* an ERROR message is sent to the client

As far as I can tell this is caused by code in both onStompAck() and onStompNack():
https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=blob;f=activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java;h=b25860bf6895240c33a8643b6fcc731af126d32e;hb=refs/heads/master#l440

With a STOMP 1.1 ACK/NACK, ackId == null, so the message entry is taken out of this.pedingAcks
(sic!).
When the transaction is aborted the message entry is then not put back into this.pedingAcks,
so any subsequent ACK/NACK will find pendingAck==null, therefore acked==false, raising an
exception.


> Aborting a STOMP 1.1 transaction after ACK/NACK leads to invalid state
> ----------------------------------------------------------------------
>
>                 Key: AMQ-6697
>                 URL: https://issues.apache.org/jira/browse/AMQ-6697
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: stomp
>    Affects Versions: 5.14.5
>            Reporter: Markus Gerstel
>
> Reproducing the problem:
> * Receive a message via STOMP (+EDIT: on a subscription with ack:client-individual+)
> * Start a transaction
> * ACK (or NACK) the message within the transaction
> * Abort the transaction
> * ACK (or NACK) the message
> Expected behaviour:
> * The message is according to step #5 either ACKed or NACKed.
> Observed behaviour:
> * The message is neither ACKed nor NACKed, but stays in unacknowledged state
> * An exception is raised:
>  org.apache.activemq.transport.stomp.ProtocolException: Unexpected ACK received for message-id
[ID:(...)]
>         at org.apache.activemq.transport.stomp.ProtocolConverter.onStompAck(ProtocolConverter.java:475)
>         at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:250)
>         at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:85)
>         at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
>         at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:233)
>         at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:215)
>         at java.lang.Thread.run(Thread.java:745)
> * an ERROR message is sent to the client
> As far as I can tell this is caused by code in both onStompAck() and onStompNack():
> https://git-wip-us.apache.org/repos/asf?p=activemq.git;a=blob;f=activemq-stomp/src/main/java/org/apache/activemq/transport/stomp/ProtocolConverter.java;h=b25860bf6895240c33a8643b6fcc731af126d32e;hb=refs/heads/master#l440
> With a STOMP 1.1 ACK/NACK, ackId == null, so the message entry is taken out of this.pedingAcks
(sic!).
> When the transaction is aborted the message entry is then not put back into this.pedingAcks,
so any subsequent ACK/NACK will find pendingAck==null, therefore acked==false, raising an
exception.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Mime
View raw message