-
Notifications
You must be signed in to change notification settings - Fork 836
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
azservice bus can over-issue receiving link credit #19965
Comments
Our basic issue here is that we don't know (at start) what the credit limit should be. |
It's not the arbitrarily high value, it's issuing more credit than the link has been configured to handle. In the current design, when the receiver is constructed, you specify a max credit its link can handle. This max is used to create the buffered |
Sounds like the channel size is really the only thing that grows, so I think I'll do two things:
|
I'll also add that if this current design is too restrictive, we can consider changing it so there's no max. |
I was thinking that too, but it doesn't seem too bad really. SB has manual credits to avoid over-caching messages and having them expire while caught in some internal buffer. As part of this there's also a cap to the amount of messages that are returned in one batch. I'll set it high just to avoid having too much trouble, no issues. For EH we just use the go-amqp auto-flow stuff so we can take advantage of the prefetching. So it won't be so bad. The other stack I've used (rhea, js) has a similar issue with an internal circular buffer so it's not unheard of. |
Over-issuing of credit can cause a receiver to hang in some circumstances. This has been fixed in later versions of
go-amqp
to return an error, so SB will need to update to handle this (unsure about EH).The text was updated successfully, but these errors were encountered: