Skip to content
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

Unable to set the link-credit to zero without setting the drain flag #390

Open
BenRoberts86 opened this issue Nov 11, 2019 · 3 comments
Open

Comments

@BenRoberts86
Copy link

Currently within ReceiverLink.SetCredit the only way to explicitly set this zero is to use CreditMode.Drain. Is it possible to add a way to allow setting credit to zero without setting the drain flag?

CreditMode.Manual increments the credit, and using a negative value would then cause the wrong flow to be sent due to the cast to uint later in the method. CreditMode.Auto seems to only allow incrementing of the credit.

@xinchen10
Copy link
Member

Are you trying to stop the remote endpoint by sending a flow with 0 credit? Do you issue more credits later on when condition changes? If yes, this is exactly what drain does.
The negative credit in manual mode seems to be an issue. We can fix it by not letting it go negative. That should also enable what you want to do.

@BenRoberts86
Copy link
Author

Sorry for the delayed response. We are trying to stop the remote endpoint by setting credit to 0, however it may also be the case that active MQ doesn't utilise the drain flag in the way you would expect. We've definitely noticed a different behaviour when sending a flow of 0 with drain set vs unset, in the case of slow producers but fast consumers (so the queue may actually be empty some of the time).

Ideally we'd also like to be able to switch back to auto mode afterwards.

I do have a solution that I'm happy to share to see if it would be accepted into this library, however it does change the behaviour of ReceiverLink a little. In particular if OnDelivery is called when credit is 0 or lower then no exception is thrown. This then opens up the possibility of decreasing the credit (along with a few other changes). Without this change, the credit may be reduced with message in-flight, and this exception would then be hit.

@xinchen10
Copy link
Member

The credit check should be enforced as that is defined by the protocol. Right now at least in auto-mode, the total credit can be decreased. We remember that but keep the running credit as is to handle in-flight deliveries. The only thing missing for your case is sending a flow with reduced credit. The flow is only sent when credit is increased because as long as messages are coming in the credit will be consumed and only restored to the previously set limit. If we also send a flow for reduced credit, the existing logic should still work and it will make your scenario work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants