AMQP Qpid sets the outgoing window size (maximum
transfer frames to expect from client) when negotiating the BEGIN of a
session equal to the currently enqueued message count. Our AMQP service honors
this when replying with the initial FLOW message, setting the incoming
window size (maximum transfer frames allowed to be sent) to the same
value.
The problem is that there is rarely a message enqueued when
the session is started, and so the outgoing/incoming window size is set to 0,
which prevents the client from further communication. The developer in charge
of the service points out that they are honoring the expectations of the
client, and I tend to agree with them: it makes sense that they could optimize
a link while it has 0 expected transfers, and wait for an updated flow to
renegotiate a new window.
We're not using the messenger class, we're using the lower-level classes. I
can reproduce this behavior by using the proton project with the commandline
parameters -c 127.0.0.1 -a TESTING against a version of the service running
locally. Diving into the code,
pn_session_outgoing_window looks only at currently pending
session->outgoing_deliveries.That's correctly updated in pn_advance_sender when
I submit a message... but in pn_process_tpwork_sender we have a 0
remote_incoming_window, so we never send a transfer. Naturally, the one place a
pn_post_flow occurs on a sender link is in pn_do_transfer... after a transfer:
// XXX: need better policy for when to refresh window
if (!ssn->state.incoming_window && (int32_t) link->state.local_handle >= 0)
{pn_post_flow(transport, ssn, link);
I can't call pn_link_flow, as that's only for modifying receiver link credits,
and it asserts on a sender. Questions:Am I using AMQP wrong? :)Is there any way
to send a flow for the sending link to set a new anticipated window? How do we
renegotiate as our window shrinks? Thank you very much for your time, -Tom
Mathews
