Bozo Dragojevic commented on PROTON-200:

For us we could not do anything except 1:1 until we fixed this.

There is one other implication that is spread over time:

1) messenger (say a broker) hands out all it's credit (using whatever 
algorithm) to set of current peers,
2) these peers choose to not send messages to the broker (consider services 
registered with a broker, waiting for requests)
3) then a future peer (a client trying to send a request message via the broker 
to the service) will not be able to send, since the broker has handed out all 
of it's credit.

My solution was to severely limit the credit given out to any link so that 
messenger always has some credit on hand.
Not pretty, but it at least allows us to use proton in a hub-and-spokes 
The fix seems only a band-aid, tho. 
Even if each link gets just one credit, and assuming the code uses a constant 
value for the pn_messenger_recv() call, it's easy to DOS such a broker by just 
connecting enough clients that do nothing.

> [Proton-c] Credit distribution by messenger is not balanced across all links
> ----------------------------------------------------------------------------
>                 Key: PROTON-200
>                 URL: https://issues.apache.org/jira/browse/PROTON-200
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c
>    Affects Versions: 0.3
>            Reporter: Ken Giusti
>            Assignee: Ken Giusti
>             Fix For: 0.4
> The method used to distribute credit to receiving links may lead to 
> starvation when the number of receiving links is > the available credit.
> The distribution algorithm always starts with the same link - see 
> messenger.c::pn_messenger_flow()

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to