-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
[NATS Jetstream] Do not take message retries into account when scaling #3787
Comments
Hi @toniopelo , |
Hi @JorTurFer, thanks for you reactivity! I'm not an expert on NATS either but I stumble across this issue so I guess this is a limitation of the current implementation. |
Nice! Of course, you can ask us and we will help you (by github or by KEDA slack channels) |
Report
Messages that have already been delivered once but need to be redelivered (did not reach the max number of delivery attempt) are not counted by the scaler and the deployment is not scaled up.
Expected Behavior
Messages in a redelivery state should be taken into account when computing the number of pending messages to be processed by a consumer.
Actual Behavior
These messages are not taken into account.
Steps to Reproduce the Problem
nats
along withkeda
(repo: https://nats-io.github.io/k8s/helm/charts/, chart: nats)natsbox
pod (deployed with the nats chart) to create astream
and apull consumer
via nats clikubectl exec -it natsbox-pod-name -- sh
nats stream add
(interactive)nats consumer add
(interactive) (choose a subject that is covered by the stream you created and setup the consumer so it can redeliver a message several times, having a low ackwait time will also help)ScaledObject
with anats-jetstream
trigger depending on the stream and consumer we just created.nats pub my-subject-name 'test' && nats consumer next my-stream-name my-consumer-name --no-ack
AckWait
time you setup on the consumer is reached, the message should be available for redelivery on next pull of the consumer. (You can test it withnats consumer next my-stream-name my-consumer-name --no-ack
again to see it is redelivered, but you'll have to wait forAckWait
time again).Logs from KEDA operator
KEDA Version
2.8.1
Kubernetes Version
1.25
Platform
No response
Scaler Details
NATS Jetstream
Anything else?
I'm pretty sure the problem is located on this line, we should probably use a different prop or combine several props returned by the nats metrics endpoint to have the desired count of messages. I don't know what is the set of props returned by the nats monitoring endpoint but I might take a look if I have some time.
The text was updated successfully, but these errors were encountered: