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
