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

Reply via email to