qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudalla Kai (INST/ECS4)" <kai.huda...@bosch-si.com>
Subject Re: Meaning of linkCapacity
Date Mon, 24 Jul 2017 14:36:19 GMT
Ted,

thank you for your hints and the pointer to the issue regarding the new concept for handing
out credits.
However, with the current mechanism in place, i.e. the Dispatch Router flowing credits to
senders based on the "linkCapacity" property, I find it hard to believe that it is completely
unrelated to the session window size. Consider the following example:

We have configured the router with a session window of 200 frames of 1000 bytes each.
We now connect a slow consumer to the router which, lets say, can process 50 messages of 1000
bytes per second and flows 100 credits to the router on link establishment. We then connect
a fast sender to the router which is capable of sending 500 messages of 1000 bytes per sec
to the router.

Now the router flows 250 credits (the default) to the sender and the sender immediately sends
its first 200 messages to the router which now needs to buffer most of these messages because
of the slow consumer. I reckon that the router does now adapts its flowing of new credit to
the sender according to the rate at which the buffered messages get settled instead of simply
issuing another fixed amount of credits to the sender, i.e. the buffer's fill ratio should
be a factor in determining how many credits are flown to the sender(s), or am I mistaken?

Mit freundlichen Grüßen / Best regards

Kai Hudalla
Chief Software Architect

Bosch Software Innovations GmbH
Schöneberger Ufer 89-91
10785 Berlin
GERMANY
www.bosch-si.com

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn

________________________________________
From: Ted Ross <tross@redhat.com>
Sent: Friday, July 21, 2017 17:13
To: users@qpid.apache.org
Subject: Re: Meaning of linkCapacity

Kai,

Please take a look at https://issues.apache.org/jira/browse/DISPATCH-781
for insight into how link capacity is used for end-to-end flow control and
a prototyped new way to use it.

A quick summary is that synchronizing credit across a network is
impractical at scale.  Instead, we use link capacity to establish local
credit loops (between endpoint and connected router) and then use delivery
settlement as the control for end-to-end flow control (and load balancing).

maxFrameSize and maxSessionFrames are for session flow control and are
completely unrelated to link/credit flow control.  linkCapacity is
therefore not related to maxFrameSize/maxSessionFrames.

-Ted

On Fri, Jul 21, 2017 at 10:27 AM, Hudalla Kai (INST/ECS4) <
kai.hudalla@bosch-si.com> wrote:

> Hi,
>
> I am wondering what the (practical) meaning of the "linkCapacity"
> configuration property on listeners is and in particular, how it is related
> to the "maxFrameSize" and "maxSessionFrames" properties. Do the latter ones
> pose a limit on the former one? My experience is that if I do not specify
> any value for "linkCapacity" then the Dispatch Router flows 250 credits to
> a sender link connecting to it (assuming that a consumer has connected with
> a receiver link interested in the relevant address). This number, however,
> seems to be unrelated to the number of credits the consumer has flowed to
> Dispatch Router, which lets me assume that the credits to flow to a sender
> are mainly related to, well, what exactly?
>
> Can somebody shed some light on this?
>
> Mit freundlichen Grüßen / Best regards
>
> Kai Hudalla
> Chief Software Architect
>
> Bosch Software Innovations GmbH
> Schöneberger Ufer 89-91
> 10785 Berlin
> GERMANY
> www.bosch-si.com
>
> Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
> 148411 B;
> Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

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


Mime
View raw message