+1
This would make sense to me. It seems like it
1. does not break the messenger model
2. keeps the interface simple
3. allows more visibility in whether the messenger is "falling behind"
4. gives new capability -- throttling
5. still hides all fancy stuff about links & credit distribution
under the messenger covers.
----- Original Message -----
From: "Ken Giusti" <kgiu...@redhat.com>
To: proton@qpid.apache.org
Sent: Tuesday, February 26, 2013 3:18:22 PM
Subject: Re: messenger credit concern
Hi Mick
----- Original Message -----
>
> One hole that I feel like I'm seeing in the messenger
> interface concerns credit.
>
> I have a way of using credit to set a max number of
> messages that a recv call should return in one gulp,
> or a way of doing ... something that I'm still figuring
> out ... by setting credit=-1.
>
> What I don't have is any way of getting guidance about
> what effect my credit allocation is having.
>
> A messenger app might have some flexibility in how
> much time it spends servicing incoming messages vs.
> time it spends doing its own processing, and it might
> be able to allocate more time to servicing incoming
> messages if it knows more about what's happening.
>
> Alternatively, it might want to set the credit allocated
> per recv call based on the number of current incoming
> links. ( And assume that the credit will be distributed
> round-robin across all incoming links. )
>
> Would it be practical / desirable / catastrophic
> to expose current backlog or number of incoming links,
> or both, at the messenger level ?
>
> Or would that violate part of the messenger API philosophy?
> ( And if so, what is that philosophy? I want to be able
> to explain it. )
>
I feel your pain - the more I use the "recv(n)" interface, the more I think
it's an awkward approach to the credit/flow issue.
>From what I understand, Messenger's model is based on two queues - one for
>incoming messages and one for outgoing messages.
For flow control, the recv(n) method indicates how many messages are allowed on
the incoming queue (max n). But recv(n) is also used as the "pend for incoming
messages" call. So every time my app needs to fetch some messages, it also
needs to compute flow control. It's that dual use that I don't like.
Since Messenger models a queue of incoming messages, I'd rather see flow
control configured as thresholds on that queue, and recv() not take any
arguments at all.
Something like this:
Messenger m;
...
m.set_flow_stop( 10000 )
m.set_flow_resume( 9000 )
...
for (;;) {
m.recv()
while (m.incoming())
....
IMHO, this is a lot "cleaner" than the current approach. Of course, some may
find my sample names too cryptic :)
>From an implementation point of view, the "flow stop" threshold is really just
>a suggestion for how much credit should be distributed across the links. We
>could distribute more, as we would need to if the number of links is greater
>than the flow stop threshold. Or less, assume a point of diminishing returns.
Once the flow stop threshold is hit, credit would be drained from all links.
No further credit would be granted until the number of "queued" messages drops
below "flow resume".
This is the same model we use for queue flow control in the C++ broker.
-K
