ZJRui opened a new issue #4086:
URL: https://github.com/apache/rocketmq/issues/4086


   
   **BUG REPORT**   maybe
   
   1. Please describe the issue you observed:
   
   For sequential message consumption, the release of the ProcessQueue lock is 
more suitable after the consume offset is submitted, not just after the 
listener has consumed the message
   
   When the consumer that consumes sequentially releases the lock of the 
MessageQueue, it will check whether there is currently a message being consumed 
through the lock of the ProcessQueue.
   
   
   When the consumer that consumes sequentially releases the lock of the 
MessageQueue, it will check whether there is currently a message being consumed 
through the lock of the ProcessQueue.
   
   If there is, in order to avoid the repeated consumption of sequential 
messages after the MessageQueue is reassigned, it is necessary to wait for the 
ProcessQueue lock to be released before releasing the MessageQueue lock.
   
   In the current implementation, the lock is released after the Listener has 
finished consuming the message, and the consume offset has not yet been 
submitted. If the MessageQueue is released at this time, there will still be 
other consumers repeatedly consuming the message for which the  offset  has not 
been submitted.
   
   Is this logic correct and Is it necessary to place the release of the 
ProcessQueue lock after the consumption displacement is committed?
   
   [current 
implemention](https://github.com/apache/rocketmq/blob/e3b67484b0ea3172cf0555e39efe36c0030c53b3/client/src/main/java/org/apache/rocketmq/client/impl/consumer/ConsumeMessageOrderlyService.java#L490-L508)
   
   2. Please tell us about your environment:
   4.9.3
   
   
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


Reply via email to