On 7 July 2015 at 07:22, Rafael Schloming <r...@alum.mit.edu> wrote: > IIRC, the definition of the outgoing-window was largely motivated by the > need to express to receivers certain conditions under which they may be > required to settle deliveries in order to receive more. For example if an > implementation uses a fixed sized array to store deliveries, and this array > is keyed by the offset of the delivery-id from the smallest unsettled > delivery, then although the sender may have sufficient credit to send more > transfers, it may not actually be capable of doing this because the next > delivery-id would land outside the range of deliveries that are currently > represented within its fixed size array. This could happen for example if > the receiver issues N credits (where N is the size of the sender's fixed > array) and settles deliveries 2 through N. The sender is then stuck with an > unsettled delivery in the first slot of its fixed sized array and cannot > send another delivery until that first delivery is settled. >
I see. I assume things above are slightly simplified by considering a session with a single sending link and, to Gordons point, only using messages with a single transfer frame given link credit and session window handling actually use different units (which actually seems like it might pose an issue in certain cases) > Given this, it's certainly true an outgoing-window of 0 is kind of strange > and useless. It's probably also true that it is never super useful for the > incoming window of the receiver to be larger than the outgoing window of > the sender (or vice versa) since one can't ever exceed the other, so I'd > say your largest-possible-int default and max-frame-like treatment are > fairly appropriate. > > --Rafael I added https://issues.apache.org/jira/browse/PROTON-936 for this, with some initial changes for discussion on https://github.com/apache/qpid-proton/pull/42 (The earlier change I suggested for proton-j which only changed the behviour if the new setter was used is still at https://github.com/gemmellr/qpid-proton/commit/b2b15a617b42bd36eacf9b51fb146223ba516496 though that might get garbase collected at some point as I rebased the repo and orphaned it) > > On Fri, Jul 3, 2015 at 8:57 AM, Robbie Gemmell <robbie.gemm...@gmail.com> > wrote: > >> Rob, Rafi, as authors of the spec and the related code in proton, do >> you have any thoughts to add here? >> >> Barring any discussion otherwise I will be looking to change proton to >> at least optionally allow controlling the outgoing window along the >> lines I mentioned near the end of my original mail. >> >> Robbie >> >> On 2 July 2015 at 00:15, Robbie Gemmell <robbie.gemm...@gmail.com> wrote: >> > Thanks James. Some expansion which may be useful to add. >> > >> > When comparing the older JMS client, proton-c via the Messenger API, >> > and the new JMS client using proton-j, its important to note that they >> > aren't all doing the same thing even where their underlying >> > implementations do seem to share the same behaviour in the cases of >> > proton-c and proton-j. >> > >> > The older JMS client initializes its outgoing window to a fixed number >> > in the session Begin frame and then doesnt seem to ever change it for >> > subsequent Flow frames, and simply manages whether its session can >> > later send transfer frames based on the current value of the remote >> > incoming window. Proton-J and Proton-C similarly only base their >> > session level decision to send transfers on the remote incoming window >> > and not their own outgoing window (which as noted below means they >> > violate their advertised outgoing window, which is often going to be >> > 0). >> > >> > Proton-C and Proton-J both currently look to set the outgoing window >> > at any given time to a calculated value based on either the number of >> > buffered messages or the buffered bytes divided by frame size. If >> > there are no buffered messages at the point the Begin and Flow frames >> > are generated, then the outgoing-window will be set to 0. This appears >> > to function the same for both proton-c and proton-j. A key point >> > though is that I think much of the historic usage of proton-c against >> > Service Bus has been via the Messenger API, which works somewhat >> > differently than many others in that it looks to create a session and >> > a sender and sends the messages in one pipelined sequence of transport >> > output, which means that by the point the Begin frame actually gets >> > generated there are indeed buffered messages to send which means the >> > outgoing-window is initialised to a value greater than zero. Other >> > APIs which create the session as a distinct step thus wont ever have >> > buffered messages when the Begin frame gets created and so the >> > outgoing-window is initialised to 0, which is the behaviour observed >> > with the new JMS client using proton-j and also what I saw when trying >> > proton-c via the Qpid Messaging C++ client (against qpidd). >> > >> > Robbie >> > >> > >> > On 1 July 2015 at 20:54, James Birdsall <jb...@microsoft.com> wrote: >> >> FYI, I have forwarded this and important bits of the preceding >> discussion to our AMQP stack dev within the ServiceBus team. >> >> >> >> Both the Qpid JMS AMQP 1.0 "legacy" client and Proton-C have been >> working fine with Azure SB for years now. Proton-J, however, is not >> something we have explored previously, and obviously there is something >> different about its behavior compared to the other clients. >> >> >> >> The Qpid JMS client is our recommended JMS client for interop with >> ServiceBus, and we would like to keep up with the times and not have to >> direct customers to the legacy client, so we are very interested in >> figuring out the correct resolution to this issue. >> >> >> >> -----Original Message----- >> >> From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] >> >> Sent: Wednesday, July 1, 2015 7:48 AM >> >> To: us...@qpid.apache.org; proton@qpid.apache.org >> >> Subject: AMQP 1.0 session outgoing-window usage / meaning >> >> >> >> Hi all, >> >> >> >> Short intro: >> >> >> >> The way we use the outgoing-window feels wrong, and seems to violate at >> least one bit of the related [and unclear overall] description in the spec. >> The way we use it means we currently can't send messages to ServiceBus in >> many cases (likely anything-but-messenger). >> >> >> >> >> >> Full version: >> >> >> >> A user reported being unable to send messages to Service Bus (Azure or >> Windows variants) using the new JMS client. Investigating that lead me to >> the handling of session outgoing-window in proton (and incoming-window in >> ServiceBus). I'd like to discuss how proton uses this, what the spec >> actually says on how it should be used since its not clear to me these are >> currently in alignment, and possibly changing how we utilise it in proton. >> >> >> >> In Proton the outgoing-window is set based on the amount of outstanding >> outgoing bytes for the session (from buffered sends) and the frame size, >> which leads to many situations where the advertised value is 0, >> particularly in a client that creates sessions entirely independently from >> sending messages (such as a JMS client, or the Qpid Messaging C++ client). >> We then send transfer frames if a link has credit, regardless of the >> session outgoing window, only withholding them if the >> remote-incoming-window hits 0. >> >> >> >> This causes problems against ServiceBus because it seems to base its >> advertised incoming window on the clients [initial] advertised outgoing >> window. If it is 0, then it means we can never send any messages. >> >> >> >> The intent/definition of the outgoing-window seems a bit unclear as a >> whole in the spec to me, to the point you could almost remove it without >> issue given the [remote-]incoming-window seems to govern overall behaviour. >> However, it seems wrong to me that we often set the outgoing-window to 0. >> Doing this means we violate the outgoing window (local and at peer) >> whenever we send a message if the remote-incoming-window allowed it. If we >> tried not to violate it, we would have to flow the new session window >> before every send, which again seems odd. >> >> >> >> It feels to me like it would be better to define initial values for the >> windows, perhaps allowing that to be configurable in the same manner as e.g >> max frame size is. Those that want to impose some limit then could, and >> those that don't can leave/set it to the max values to achieve that effect. >> >> >> >> Thoughts? >> >> >> >> Robbie >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org >> For additional commands, e-mail: users-h...@qpid.apache.org >> >>
