Hi there, after digging a bit I think this is definitely a bug. I would recommend filing a JIRA and attaching the telemetry as a patch. Do you have the option of testing against trunk builds, or do you only work from officially released artifacts?
--Rafael On Fri, Jun 6, 2014 at 12:29 PM, Tom Mathews <[email protected]> wrote: > 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 > >
