qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: Proton-j settle modes
Date Mon, 03 Mar 2014 20:32:26 GMT
Hi Piotr,

The AMQP model for settlement is based on the lifecycle of a delivery at an
endpoint. At each end of a link, a delivery is created, it exists for some
period of time, and finally it is forgotten, aka settled. Note that because
this lifecycle happens independently at both the sender and the receiver,
there are actually four events of interest in the combined lifecycle of a
given delivery:

  created at sender, created at receiver, settled at sender, settled at

Now because the sender and receiver are operating concurrently, these
events can occur in a variety of different orders, and the order of these
events impacts the types of failures that may occur when transferring a
delivery. Eliminating scenarios where the receiver creates the delivery
first, we have the following possibilities:

  Sender presettles (aka at-most-once):

      created at sender, settled at sender, created at receiver, settled at

  In this configuration the sender settles (i.e. forgets about) the
delivery before it even reaches the receiver, and if anything should happen
to the delivery in-flight, there is no way to recover, hence the "at most
once" semantics.

  Receiver settles first (aka at-least-once):

    created at sender, created at receiver, settled at receiver, settled at

  In this configuration the receiver settles the delivery first, and the
sender settles once it sees the receiver has settled. Should anything
happen to the delivery in-flight, the sender can resend, however the
receiver may have already forgotten the delivery and so it could interpret
the resend as a new delivery, hence the "at least once" semantics.

  Receiver settles second (aka exactly-once):

    created at sender, created at receiver, settled at sender, settled at

  In this configuration the receiver settles only once it has seen that the
sender has settled. This provides the sender the option to retransmit, and
the receiver has the option to recognize (and discard) duplicates, allowing
for exactly once semantics.

Note that in the last scenario the sender needs some way to know when it is
safe to settle. This is where delivery state comes in. In addition to these
lifecycle related events surrounding deliveries there is also the notion of
a delivery state that can change over the lifetime of a delivery, e.g. it
might start out as nothing, transition to RECEIVED and then transition to
ACCEPTED. In the first two scenarios the delivery state isn't required,
however in final scenario the sender would typically trigger settlement
based on seeing the delivery state transition to a terminal state like
ACCEPTED or REJECTED. In practice settlement is controlled by application
policy, so there may well be more options here, e.g. a sender might not
settle strictly based on what has happened at the receiver, it might also
choose to impose some time limit and settle after that period has expired,
or it could simply have a sliding window of the last N deliveries and
settle the oldest whenever a new one comes along.

So getting back to your initial question, the settlement modes are used to
indicate what can be expected of the settlement behaviour of an endpoint. A
sender settle mode of "mixed" means that the sender has the full range of
flexibility in its behaviour, it might presettle certain deliveries and not
others. A sender settle mode of "settled" means all deliveries from that
sender must be presettled. A receiver settle mode of "first" means that the
receiver will settle the message as soon as it is done processing it,
whereas a receiver settle mode of "second" means that the receiver will
wait to settle until it hears that the sender has already settled.

Hopefully this answers your question, but please let me know if I've just
confused things further. ;-)


On Mon, Mar 3, 2014 at 9:59 AM, Piotr Kliczewski <piotr.kliczewski@gmail.com
> wrote:

> Rafael.
> I have simple communication up and running using engine api. When I
> send a message by calling send method on Sender object I need to wait
> on reply and then I can settle. My communication is asynchronous so I
> do not want to wait. I suspect that it is related to the settle modes
> that I set on sender and receiver. In my case it is: "unsettled" for
> sender and "second" for receiver.
> Can you tell me which modes to set and what different modes mean?
> Thanks,
> Piotr
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message