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 Fri, 06 Jun 2014 13:47:55 GMT
On Thu, Jun 5, 2014 at 8:15 PM, Tom Mathews <darkphibre@hotmail.com> wrote:

>
>
>
> We are indeed planning on handling a large number of clients (millions of
> concurrent connections, multiple links per connection, distributed of
> course across load-balanced servers).
> What would set_offer look like?  I see pn_link_offered, but I can't tell
> that it does anything effective (link->available doesn't seem to be used).
>

I don't think any sort of offering should be necessary in your situation,
both for the reasons I explained in my reply to Ted, but also because the
test program you're using (assuming it is the same proton.c I'm looking at)
is actually creating a delivery and attempting to send it.

The offer API is intended for situations where you *may* have messages
available, but you don't know for sure. For example, say you have a queue
with competing consumers. You can use the offer API to provide a hint to
your consumers that you have messages available for transfer, but by the
time any given consumer acts upon the hint, its competitors may have
already eaten up the messages you were offering. A simple client should
never need to use the API since they will usually just be supplying the
messages directly.

I believe what you're seeing is either a bug, or an interop issue, or
possibly both. It's hard to be sure without seeing the protocol trace, but
I think the fact that the outgoing window is initially zero shouldn't
matter. When a delivery is available the window should be recomputed/resent
regardless.

--Rafael

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