Hi Tom, Can you post the protocol trace from your reproducer? You should be able to turn on tracing like so:
shell$ export PN_TRACE_FRM=1 shell$ proton -c 127.0.0.1 -a TESTING ... With the help of the protocol trace, we should be able to figure out what is going on and hopefully answer your question. --Rafael On Thu, Jun 5, 2014 at 2:19 PM, Tom Mathews <[email protected]> wrote: > > > 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 > >
