-
Notifications
You must be signed in to change notification settings - Fork 170
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
Support custom capacity per subscription #1276
Comments
Sure, we can have this option, however keep in mind, we count messages, not bytes, as that relies on underlying |
I understand, this is why it is important to be able to customize it since with domain-specific knowledge developer may have a better understanding what message sizes to expect and what capacity is appropriate. |
We have to think about it. |
It doesn't, but maybe it is expected that for some channels messages are like 1M in size, so default limit will result in 65G of buffered messages, while other messages are a few bytes and buffering more of them is fine. Implementing size limit will be challenging, but allowing to customize number of messages with domain-specific knowledge is much less difficult. I just don't think there is one size fits all in this case. |
Yes, I understand the use case. In some languages, like rust nats client, that is quite simple task (where the only challenge is to have least possible performance impact). However, features like this need to land in every nats client for parity, so it needs some discussions before moving forward. |
Proposed change
I'd like to see something like
Client::subscribe_with_options()
, specifically for ability to customizing subscription capacity. This is especially important because some subscriptions might have larger messages and others might have smaller messages, hence one size fits all doesn't work well here.The text was updated successfully, but these errors were encountered: