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

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