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

How to retrieve the status of a consumer. #1620

Open
qyzxcswbll opened this issue Apr 22, 2024 · 6 comments
Open

How to retrieve the status of a consumer. #1620

qyzxcswbll opened this issue Apr 22, 2024 · 6 comments
Labels
defect Suspected defect such as a bug or regression

Comments

@qyzxcswbll
Copy link

Observed behavior

During usage, we discovered that certain topics within the consumer were not functioning properly. Although we attempted to reconnect, we were uncertain when a topic became unavailable.

Expected behavior

We hope for an interface or method that can monitor the consumer's status, ideally providing information on the status of each individual topic.

Server and client version

nats-server :2.10.14
nats.go :1.34.1

Host environment

No response

Steps to reproduce

No response

@qyzxcswbll qyzxcswbll added the defect Suspected defect such as a bug or regression label Apr 22, 2024
@Jarema
Copy link
Member

Jarema commented Apr 22, 2024

You can call Info() on a consumer instance, which is equivalent of CLI's nats consumer info. This is all the info you have for a consumer.

To check what subjects (topics) are in stream, you need to check stream subjects. Keep in mind tht Consumer is just a "view" into the stream. Consumers do not store the messages.

What you mean by topic being unavailable, or not acting properly?

@qyzxcswbll
Copy link
Author

I had six topics previously. Due to unknown reasons, a reconnection was triggered, and I'm unsure why the disconnection occurred in the first place. After reconnecting, all topics were supposed to be subscribed to again, but only five were subscribed to. One particular topic consistently failed to consume properly. This occurrence is sporadic, but unfortunately, we are unable to perceive the subscription status of this topic.

@qyzxcswbll
Copy link
Author

Using consumer's info() did not provide the method to check the subscription topic status that I want.

@Jarema
Copy link
Member

Jarema commented Apr 22, 2024

When consumer is consuming messages, it does not subscribe separately to subjects.
It consumes all messages for given filter(s) leveraging only one subscription.

Maybe the messages were about to be redelivered due to reconnect?
Could you describe the behavior you see that is invalid and share consumer/stream info?

@qyzxcswbll
Copy link
Author

Because the names of the topics are all different, and no * or > is used, there are 6 similar subscriptions in a loop. Therefore, in case of disconnection, I will reconnect. I use the CreateOrUpdateConsumer method.

The reason for considering it ineffective is that subscriptions can be received normally on other nodes, but cannot be received properly on this reconnected node.

Based on your description, I checked the info method and did not find a method to obtain the status of the topic.

@Jarema
Copy link
Member

Jarema commented Apr 22, 2024

You do not have to do anything if client disconnects. It will automatically reconnect on it's own and resume all subscriptions and consumers. What you mean that you do reconnect? Maybe this is source of a problem.

Regarding the subscriptions:
Even if you have a consumer with multiple subjects, like this:

ConsumerConfig {
  Durable: "Consumer",
  FilterSubjects: []string{"foo.>", "bar.>", "baz.*"},
}

its still one subscription because of how JetStream consumer API works and why you will get messages in order.

Can you please share your Consumer and Stream configs, so we can better understand your config the issue you're facing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
defect Suspected defect such as a bug or regression
Projects
None yet
Development

No branches or pull requests

2 participants