Skip to main content

Transfers

A sender transfers a message only against the receiver's link credit, and the receiver settles each one with a disposition that carries its outcome.

Link credit over time: the receiver grants it, the sender spends it, and the client grants a new window once half has been settledReceiver: the serviceSender: the brokerflowlink-credit 256transfersup to the creditdispositionsfor 128 deliveriesflowlink-credit 256 againtransferscontinueCredit counts transfers from the last flow:a delivery the service still holds does not return it
The diagram as text
  1. Receiver: the service: flow link-credit 256; dispositions for 128 deliveries; flow link-credit 256 again
  2. Sender: the broker: transfers up to the credit; transfers continue
  3. flow link-credit 256 → transfers up to the credit: flow
  4. transfers up to the credit → dispositions for 128 deliveries: transfer
  5. dispositions for 128 deliveries → flow link-credit 256 again: half settled
  6. flow link-credit 256 again → transfers continue: flow
  7. Credit counts transfers from the last flow: a delivery the service still holds does not return it

Credit is the receiver's flow control. The receiver sends a flow frame with a credit, and the sender may make that many transfers before it waits for the next one. A subscription grants 256 by default, and credit sets another count.

The fe2o3-amqp client manages the credit itself. Each time half of the credit has been settled, it grants the full credit again, counted from the transfers received so far. So the sender never runs dry while the service works, and it never runs more than one window ahead of the last grant.

The four outcomes of a disposition and what each leaves the message as on the brokerDispositionBrokeraccepteddone: the messageleaves the queuerejectedinvalid: the broker'sdead-letter policy decidesreleasednot processed: back onthe queue, count unchangedmodifieddelivery-failedfailed: back on thequeue, delivery-count + 1A sender sends unsettled, settled or mixed (the default);a transfer settled on sending is delivered at most once
The diagram as text
  1. Disposition: accepted; rejected; released; modified delivery-failed
  2. Broker: done: the message leaves the queue; invalid: the broker's dead-letter policy decides; not processed: back on the queue, count unchanged; failed: back on the queue, delivery-count + 1
  3. accepted → done: the message leaves the queue
  4. rejected → invalid: the broker's dead-letter policy decides
  5. released → not processed: back on the queue, count unchanged
  6. modified delivery-failed → failed: back on the queue, delivery-count + 1
  7. A sender sends unsettled, settled or mixed (the default); a transfer settled on sending is delivered at most once

A transfer the sender did not settle stays open until the receiver answers with a disposition. Its outcome is one of four. accepted finishes the message. rejected calls it invalid, and the broker's dead-letter policy decides what happens to it. released returns it untouched, and the next delivery carries the same delivery-count. modified with delivery-failed returns it as a failed attempt, and the next delivery counts one more. undeliverable-here on modified asks the broker not to deliver it to this receiver again.

delivery-count lives in the message's header section and counts the earlier attempts that failed. Brokers differ on modified: Artemis counts it, RabbitMQ 4 supports it on quorum queues only, and Azure Service Bus does not use it.

The flow control and the settle modes are the specification's (transport, sections 2.6.7 and 2.8), and so are the outcomes (messaging, section 3.4).