Here's the telemetry log, with the relevant bits bolded. Once the server responds with an incoming window set to 0, adding a new delivery won't trigger a renegotiated flow.Connected to 127.0.0.1:6053[0000006F6E3311D0]: -> AMQP[0000006F6E3311D0]:0 -> @open(16) [container-id="TOMM-DT2", hostname="127.0.0.1"][0000006F6E3311D0]:0 -> @begin(17) [next-outgoing-id=0, incoming-window=2147483647, outgoing-window=0][0000006F6E3311D0]:0 -> @attach(18) [name="sender", handle=0, role=false, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="TESTING", durable=0, timeout=0, dynamic=false], initial-delivery-count=0][0000006F6E3311D0]:0 -> @attach(18) [name="receiver", handle=1, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [address="TESTING", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0][0000006F6E3311D0]:0 -> @flow(19) [incoming-window=2147483647, next-outgoing-id=0, outgoing-window=0, handle=1, delivery-count=0, link-credit=1, drain=false][0000006F6E3311D0]: <- AMQP[0000006F6E3311D0]:0 <- @open(16) [container-id="M2099774168P21368", max-frame-size=65536, channel-max=10000][0000006F6E3311D0]:0 <- @begin(17) [remote-channel=0, next-outgoing-id=1, incoming-window=0, outgoing-window=5000][0000006F6E3311D0]:0 <- @attach(18) [name="sender", handle=0, role=true, snd-settle-mode=2, rcv-settle-mode=0, source=@source(40) [durable=0, timeout=0, dynamic=false], target=@target(41) [address="TESTING", durable=0, timeout=0, dynamic=false], max-message-size=18446744073709551615][0000006F6E3311D0]:0 <- @flow(19) [next-incoming-id=0, incoming-window=0, next-outgoing-id=1, outgoing-window=5000, handle=0, delivery-count=0, link-credit=1000, available=0, echo=false]sent delivery: 0[0000006F6E3311D0]:0 <- @attach(18) [name="receiver", handle=1, role=false, snd-settle-mode=1, source=@source(40) [address="TESTING", durable=0, timeout=0, dynamic=false], target=@target(41) [durable=0, timeout=0, dynamic=false], initial-delivery-count=0, max-message-size=18446744073709551615]
> Date: Fri, 6 Jun 2014 09:47:55 -0400 > Subject: Re: The waiting game [client sends 0 outgoing size] > From: [email protected] > To: [email protected] > > 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
