qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tom Mathews <darkphi...@hotmail.com>
Subject RE: The waiting game [client sends 0 outgoing size]
Date Fri, 06 Jun 2014 16:29:46 GMT
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