Support for AMQPv1 modified outcome

[motmot80]

We are using QPID with the AMQPv1 plugin which is the default JAVA JMS + RMQ combination.
When QPID uses the AMQPv1 "modified" outcome RMQ cuts the connection.
While there's no need for full modified state support the RabbitMQ should not cut off a consumer which use a standardized AMQPv1 frame combination.

Description

Using amqpv1 with classic queues and a high message througput combined with TTL causes protocol errors with QPID.
The default implementation of QPID uses the modified state in the disposition frame to tell RMQ that the TTL has expired after TRANSFER.

OASIS AMQPv1 this state:

http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-modified

Reproduction

1. Send disposition frame in modified state
2. Use QPID consumer on high message througput with a short message TTL

Error

{'v1_0.disposition',true,
                                     {uint,0},
                                     {uint,0},
                                     true,
                                     {'v1_0.modified',true,true,undefined},
                                     undefined} [condition = amqp:invalid-field]

Workaround

Disable QPID expiry feature

jms.localMessageExpiry=false

Details

AMQPv1 trace:

RECV: Transfer{handle=0, deliveryId=0, deliveryTag=\x00\x00\x00\x00\x00\x00\x00\x01, messageFormat=0, settled=false, more=false, rcvSettleMode=null, state=null, resume=false, aborted=false, batchable=false} (429) "..."

SENT: Flow{nextIncomingId=1, incomingWindow=2047, nextOutgoingId=1, outgoingWindow=2147483647, handle=0, deliveryCount=1, linkCredit=1, available=null, drain=false, echo=false, properties=null}

SENT: Disposition{role=RECEIVER, first=0, last=0, settled=true, state=Modified{deliveryFailed=true, undeliverableHere=true, messageAnnotations=null}, batchable=false}

[kjnilsson]

so we should treat the modified state the same as the accepted state? And complete the message? At least for now.

[kjnilsson]

Do you know what QPid does when it receives the modified settlement?

[motmot80]

@kjnilsson I assume qpid tries to tell the broker that the message has already expired and it does not expect to get expired messages.

"At the target, the modified outcome is used to indicate that a given transfer was not and will not be acted upon, and that the message SHOULD be modified in the specified ways at the node. "

Because it only happens in high load scenarios this qpid result might be wrong - I think these messages are expiring within qpid processing (amqpv1 receive => OnMessage).

But following the robustness principle "be conservative in what you do, be liberal in what you accept from others"

[kjnilsson]

The main question is what RabbitMQ should do with the message when receiving a modified outcome. In this case we have mapped it to accepted. But it could equally be mapped to rejected and thus be subject to any dead lettering configured in the source queue. There isn’t really a spec to say what should be done.

On Sun, 30 Oct 2022 at 11:06, Thomas Stollenwerk ***@***.***> wrote: @kjnilsson <https://github.com/kjnilsson> I assume qpid tries to tell the broker that the message has already expired and it does not expect to get expired messages. *"At the target, the modified outcome is used to indicate that a given transfer was not and will not be acted upon, and that the message SHOULD be modified in the specified ways at the node. "* Because it only happens in high load scenarios this qpid result might be wrong - I think these messages are expiring within qpid processing (amqpv1 receive => OnMessage). But following the robustness principle *"be conservative in what you do, be liberal in what you accept from others"* — Reply to this email directly, view it on GitHub <#6121 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJAHFGZVRYKL44YZHDU4KDWFZCDBANCNFSM6AAAAAARETLEAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Karl Nilsson*

[kjnilsson]

Having re-read the spec and thought about this it feels clear that mapping the modified outcome to accepted is wrong. Instead we should map it as released (i.e. return{requeue=true}). At least when delivery_failed=true. What we can't quite achieve is if (As above) undeliverable_here=true - that is we can't guarantee that the message won't be re-delivered to the consumer that modified it. In this case we could consider mapping it as rejected (return{requeue=false}).