[
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)
