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

Multi-ack can block consumption when rate limitation is enabled #332

Closed
acogoluegnes opened this issue May 13, 2022 · 1 comment
Closed
Assignees
Labels
Milestone

Comments

@acogoluegnes
Copy link
Collaborator

To reproduce:

# fill up a queue
perf-test -x 1 -y 0 -c 3000 -C 100000 -r 10000 -qq -u qq
# consume... or not
perf-test -x 0 -y 1 -A 1000 -q 1000 -R 10000 -qq -u qq

The consumer stops at some point, because it does not ack at the appropriate time and the number of un-acked messages reaches the QoS.

} else if (currentMessageCount % multiAckEvery == 0) {

@acogoluegnes acogoluegnes self-assigned this May 13, 2022
@acogoluegnes acogoluegnes added this to the 2.18.0 milestone May 13, 2022
@acogoluegnes
Copy link
Collaborator Author

There should be 3 message counts:

  • one to choose when to ack or commit (to be reset when recovery takes place)
  • one for rate limitation (because it needs to be reset sometimes)
  • one for absolute count (used to stop the consumer when it reaches its limit)

pivotal-rabbitmq-ci pushed a commit that referenced this issue Jun 8, 2022
Otherwise the different features interleave with 1 counter.

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

No branches or pull requests

1 participant