Description
The broker currently grants credit based on the 'amqpCredit' configuration which default to 1000 using a check on the "remote credit" view which includes messages currently queued into proton but not processed by the protocol head yet. This accounting can lead to a runaway credit situation if the sender is particularly fast or a significant number of small messages are batched into one TCP frame and the broker isn't able to clear the backlog from the proton queue fast enough such that the queue grows to the point that the granting algorithm starts granting "amqpCredit" number of credits on each new messages it processes from proton.
Another smaller issue is that the granting of credit allows for a client to have an outstanding balance of more than the configured "amqpCredits" which may not be what was originally intended by that option and doesn't match what many of the clients do when topping off credit at a low water mark.
Attachments
Issue Links
- links to