On Thu, Jun 5, 2014 at 8:15 PM, Tom Mathews <[email protected]> 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
