Rafael, I am using code from trunk so I can pick up the changes quickly. You are correct that I can pump bytes in and out but I have no knowledge what I am transferring and how the bytes change internal state.
Currently I hacked FrameHandler but it would be great to have event API. Thanks, Piotr On Wed, Mar 5, 2014 at 4:38 PM, Rafael Schloming <r...@alum.mit.edu> wrote: > 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.kliczew...@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.kliczew...@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 <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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
