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

Support custom capacity per subscription #1276

Open
nazar-pc opened this issue Jun 7, 2024 · 5 comments
Open

Support custom capacity per subscription #1276

nazar-pc opened this issue Jun 7, 2024 · 5 comments
Labels
proposal Enhancement idea or proposal

Comments

@nazar-pc
Copy link
Contributor

nazar-pc commented Jun 7, 2024

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.

@nazar-pc nazar-pc added the proposal Enhancement idea or proposal label Jun 7, 2024
@Jarema
Copy link
Member

Jarema commented Jun 7, 2024

Sure, we can have this option, however keep in mind, we count messages, not bytes, as that relies on underlying mpsc capacity.

@nazar-pc
Copy link
Contributor Author

nazar-pc commented Jun 7, 2024

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.

@Jarema
Copy link
Member

Jarema commented Jun 20, 2024

We have to think about it.
Adding additional restriction (not only on message count, but also on message size) means that client will likely drop more messages and cause client side slow consumer. Such limit does not restrict client from receiving the message from the server in the first place.

@nazar-pc
Copy link
Contributor Author

nazar-pc commented Jun 20, 2024

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.

@Jarema
Copy link
Member

Jarema commented Jun 20, 2024

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.

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

No branches or pull requests

2 participants