qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: proton server (azure SB) limit the incoming_window=5000
Date Thu, 10 Aug 2017 19:03:17 GMT
On 10/08/17 19:47, Pankaj Bhagra wrote:
> Gordon,
> what is the meaning of "more" flags. I assume this means that server
> doesn't have more data to flush ? correct ?

No, it means is there any more data to be transferred for that specific 
delivery i.e. that specific message.

> [0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=0, delivery-tag=b"",
> message-format=0, settled=true, more=false, batchable=true] (1220)
> [0x24b0cd0]:0 <- @transfer(20) [handle=0, delivery-id=1, delivery-tag=b"",
> message-format=0, settled=true, more=false, batchable=true] (1231)
> If so, it appears that SB only caches 16K of data and doesn't refill this
> cache unless there is a new fetch request (which is painfully take the
> RTT).

What is triggering the next batch isn't really a fetch, since there was 
already existing credit.

I think I may have misunderstood what you wanted to do in the previous 
mail btw. Did you want to disable sending the flow? If you you can set 
prefetch to 0, but then you have to do a receiver.flow(10000) (or 
similar) when you first create the receiver, to give it credit. That way 
it will not send a flow again after receiving the first set of 
transfers, and you can see what effect that has, if any.

> Does it make sense to keep sending a prefetch request every few msec to
> keep the server busy and pulling data from whatever its backend store ?

The flow is already being sent back as soon as it has processed the 
messages you have. The client is single threaded so while it is 
processing the incoming transfers it won't be sending anything out. 
However from the timestamps that seems to take very few millisecs.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message