Description
Before Creating the Enhancement Request
- I have confirmed that this should be classified as an enhancement rather than a bug/feature.
Summary
org.apache.rocketmq.broker.transaction.queue.TransactionalMessageServiceImpl#check
Motivation
Long removedOpOffset;
if ((removedOpOffset = removeMap.remove(i)) != null){
log.debug("Half offset {} has been committed/rolled back", i);
opMsgMap.get(removedOpOffset).remove(i);
if (opMsgMap.get(removedOpOffset).size() == 0) {
opMsgMap.remove(removedOpOffset);
doneOpOffset.add(removedOpOffset);
}
}
Describe the Solution You'd Like
Long removedOpOffset;
if ((removedOpOffset = removeMap.remove(i)) != null){
log.debug("Half offset {} has been committed/rolled back", i);
opMsgMap.get(removedOpOffset).remove(i);
if (opMsgMap.get(removedOpOffset).size() == 0) {
opMsgMap.remove(removedOpOffset);
doneOpOffset.add(removedOpOffset);
}
}
Describe Alternatives You've Considered
事务消息， 回查判断RMQ_SYS_TRANS_HALF_TOPIC消息是否在RMQ_SYS_TRANS_OP_HALF_TOPIC 中，优化判断方式。
之前代码是先判断Map.containsKey，然后进行removeKey，新的方式是直接removeKey ！= null。之前如果Map.containsKey为真，还需要进行额外的一步removeKey操作，新的方式removeKey！= null，即判断了Map是否存在key，又移出了对应的key，提升了一点点性能。
Transactional messages: The process involves checking whether messages in RMQ_SYS_TRANS_HALF_TOPIC exist in RMQ_SYS_TRANS_OP_HALF_TOPIC, with an optimized approach for verification. Previously, the code first used Map.containsKey to check existence and then performed removeKey. The new approach directly uses removeKey != null.
In the previous method, if Map.containsKey returned true, an additional removeKey operation was required. In contrast, the new approach both checks if the key exists in the Map and removes the corresponding key in one step, offering a slight performance improvement.
Additional Context
No response