[jira] [Commented] (ARTEMIS-1983) Usage of STOMP NACK command leads to data loss

["Justin Bertram (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550882#comment-16550882 ] 

Justin Bertram commented on ARTEMIS-1983:
-----------------------------------------

As far as I can tell, the broker's behavior here is in accordance with the STOMP [1.1|https://stomp.github.io/stomp-specification-1.1.html#NACK] & [1.2|https://stomp.github.io/stomp-specification-1.2.html#NACK] specifications which state:
{quote}NACK is the opposite of ACK. It is used to tell the server that the client did not consume the message. The server can then either send the message to a different client, discard it, or put it in a dead letter queue. The exact behavior is server specific.
{quote}
Artemis chooses to discard the message which is valid per the specification.

> Usage of STOMP NACK command leads to data loss
> ----------------------------------------------
>
>                 Key: ARTEMIS-1983
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-1983
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>          Components: STOMP
>    Affects Versions: 2.6.2
>            Reporter: Miroslav Minárik
>            Assignee: Justin Bertram
>            Priority: Major
>
> Implementation of NACK command of STOMP protocol v1.1 and 1.2 causes message(s) loss. Bug is in source code in apache-artemis-2.6.2/artemis-protocols/artemis-stomp-protocol/src/main/java/org/apache/activemq/artemis/core/protocol/stomp/v11/StompFrameHandlerV11.java in this part:
> {code}
>   public StompFrame onNack(StompFrame request) {
>       //this eventually means discard the message (it never be redelivered again).
>       //we can consider supporting redeliver to a different sub.
>       return onAck(request);
>    }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)