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 Wed, 05 Mar 2014 15:38:23 GMT
Hi Piotr,

You can actually send a message whenever you want, the engine will just
buffer it until it is allowed to send it over the wire. The easiest way to
tell if a message will actually get written to the wire prior to sending it
is to check that the link credit is > 0.

There is an event API for the C engine that allows you to be notified when
credit changes and link endpoint states change, however it has not been
ported to Java yet. Strictly speaking you don't need this API since you
have full control over the I/O. You know that nothing can possibly change
unless you pump bytes into/out of the transport, and whenever you do this
you can check the credit on links, or check whatever else you are
interested in. The event API makes it a lot simpler to program against
though since it provides a convenient way of knowing exactly what has
changed rather than requiring you to check everything you are interested in.

If working from trunk is an option for you I can probably get you a Java
version of the events stuff pretty quickly. It's a fairly simple extension
to the API, but it can be pretty convenient depending on what you're trying
to do. FYI, I'm expecting to cut an RC for 0.7 by next week, so you'd have
a released version to work from before long.

--Rafael



On Wed, Mar 5, 2014 at 9:55 AM, Piotr Kliczewski <piotr.kliczewski@gmail.com
> wrote:

> 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
> <piotr.kliczewski@gmail.com> 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 <rhs@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.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
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

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