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
