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 [] 
Sent: Wednesday, July 1, 2015 7:48 AM
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.



Reply via email to