[Bug] Unexpected decrement of lmq counter
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 65/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- java
- Domain
- databases, distributed-systems
Research direction
Search the repository for RocksDBConsumeQueueOffsetTable, lmqCounter, topicQueueMaxCqOffset, and removeHeapMaxCqOffset to trace the non-existent LMQ path. Add or update a regression test covering creation, deletion, and counter behavior for an LMQ represented by -1L; done means deleting it no longer underflows lmqCounter.
Written by the indexing model from the issue text.
Description
Before Creating the Bug Report
-
I found a bug, not just asking a question, which should be created in GitHub Discussions.
-
I have searched the GitHub Issues and GitHub Discussions of this repository and believe that this is not a duplicate.
-
I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ.
Runtime platform environment
.
RocketMQ version
.
JDK Version
.
Describe the Bug
We previously implemented an LMQ counting mechanism and have now discovered an unexpected counter underflow issue in RocksDBConsumeQueueOffsetTable.
Steps to Reproduce
When specific get* operation is called for a non-existent LMQ topic, a sentinel value -1L is placed into topicQueueMaxCqOffset without incrementing lmqCounter. However, if this topic is later deleted, removeHeapMaxCqOffset unconditionally decrements lmqCounter, causing the counter to underflow.
What Did You Expect to See?
lmqCounter should not be decremented for entries that were never actually counted.
What Did You See Instead?
.
Additional Context
.
- Dominant language
- Java
- Stars
- 22.6k
- Forks
- 12k
- Avg merge
- 3d 12h
- Merged PRs (30d)
- 25
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/rocketmq
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
[Bug] TopicValidator rejects V2 retry topic names containing `+` separator introduced by KeyBuilder Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
infinispan/infinispan#18150 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
opensearch-project/k-NN#3597 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100