Rafael, I found ProtocolTracker but it is run before not after a frame handler. Is there any other mechanism?
Thanks, Piotr On Wed, Mar 5, 2014 at 2:43 PM, Piotr Kliczewski <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected] >>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
