Rafael, Thank you for the explanation is clearer for me now.
Can you tell me what is the best way to get notifications after the state transition frames are processed (openFrame, beginFrame, transferFrame etc.)? I would like to understand when I can perform an action like send a message. Piotr On Mon, Mar 3, 2014 at 9:32 PM, Rafael Schloming <r...@alum.mit.edu> wrote: > 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 > receiver > > 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 > receiver > > 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 > sender > > 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 > receiver > > 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. ;-) > > --Rafael > > > > On Mon, Mar 3, 2014 at 9:59 AM, Piotr Kliczewski <piotr.kliczew...@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-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
