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, 12 Jun 2014 18:34:56 GMT
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 <darkphibre@hotmail.com> 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: rhs@alum.mit.edu
> > To: users@qpid.apache.org
> >
> > 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