qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Birdsall <jb...@microsoft.com>
Subject RE: AMQP 1.0 session outgoing-window usage / meaning
Date Wed, 01 Jul 2015 19:54:55 GMT
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.gemmell@gmail.com] 
Sent: Wednesday, July 1, 2015 7:48 AM
To: users@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.



To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message