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

Implement slow consumer detection in Nats.js #191

Open
alphara opened this issue Sep 1, 2021 · 3 comments
Open

Implement slow consumer detection in Nats.js #191

alphara opened this issue Sep 1, 2021 · 3 comments

Comments

@alphara
Copy link

alphara commented Sep 1, 2021

We often experience slow consumers in our real-time system based on NATS. It is useful if the service would be able to detect itself as a slow consumer.

According to nats_admin/slow_consumers, there is a way to detect slow consumers with the NATS client on Go. The same feature is not implemented for the NATS client on Node.js.

Could you implement slow consumer detection in the Nats.js?

@aricart
Copy link
Member

aricart commented Sep 1, 2021

@alphara this is a good idea. The javascript clients are more prone to this type of problem as they have a single thread to process inbound/outbound and user code.

@aricart aricart transferred this issue from nats-io/nats.js Sep 1, 2021
@alphara
Copy link
Author

alphara commented Sep 1, 2021

That's right. That's why we want to detect it.

The following graph shows how often we experienced slow consumers in our real-time system in the last 30 days.
image

We have Node.js and Java clients in our system.

@aricart
Copy link
Member

aricart commented May 13, 2022

@alphara trying to study how to reflect this - effectively if you are using callbacks, the messages are in the execution path of the socket read - the data read from the socket is parsed, and as parsed, it invokes subscriptions - there's no buffering here, on the particular data read from the network gets processed. If you are using iterators, that is a different story, because function that feeds messages into an iterator, buffer, so at that point it is possible to determine if there are messages pending. The subscription's getPending() actually has an approximation of how many messages have queued up for the subscription.

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

No branches or pull requests

2 participants