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

JetStream WorkQueue consumer behaving ambiguous (droping, delay picking messages) #5799

Closed
zakk616 opened this issue Aug 18, 2024 · 4 comments
Labels
defect Suspected defect such as a bug or regression

Comments

@zakk616
Copy link

zakk616 commented Aug 18, 2024

Observed behavior

We are using nats-server v2.10.16, a cluster of three nodes configured.
image

We have a workqueue stream that has multiple subjects and consumers below:
image

image

We have seen messages being dropped by nats and consumer are not picking those messages, also in some cases a delay of exactly "AckWait" duration has been noticed while messages being picked by the consumer.
Ex: messages from below consumers are being picked after 10 minutes which is its AckWait.
image

Expected behavior

Message count of published and picked should be the same, while deference has been noticed in numbers.

Subject Publishsed Picked Lost
OTHER_TRANS.ICM_REQ 27 25 2
OTHER_TRANS.NRT_SWIFT 9 9 0
OTHER_TRANS.NRT_DC_DATABASE 1 1 0
OTHER_TRANS.DNS_SWIFT 928 911 17

Server and client version

Server: 2.10.16
Client: nats.net client for C# v4.0.30319

Host environment

OS: Ubuntu 22.04.1 LTS

Steps to reproduce

No response

@zakk616 zakk616 added the defect Suspected defect such as a bug or regression label Aug 18, 2024
@zakk616
Copy link
Author

zakk616 commented Sep 4, 2024

Issue is similar to #5638, #5612 and #5705 which were likely fixed in #5639 and released with 2.10.19.
We upgraded 2.10.16 to 2.10.19. so far we couldn't reproduce this issue.

@zakk616 zakk616 closed this as completed Sep 4, 2024
@derekcollison
Copy link
Member

We suggest upgrading to 2.10.20, we had a small regression on R1 KV CAS operations.

@zakk616
Copy link
Author

zakk616 commented Sep 4, 2024

Upgrading to 2.10.20 would require repeating much of the effort we’ve already invested in upgrading to 2.10.19. Additionally, we are currently running R3.

@derekcollison
Copy link
Member

Only one bug fix in 2.10.20 vs 2.10.19, so drop in replacement..

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