qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <...@alum.mit.edu>
Subject Re: The waiting game [client sends 0 outgoing size]
Date Thu, 05 Jun 2014 18:53:03 GMT
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 <darkphibre@hotmail.com> 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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message