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
