[GitHub] [rocketmq] ZJRui commented on issue #4086: the release of the ProcessQueue lock is more suitable after the consume offset is submitted, not just after the listener has consumed the message

[GitBox <gi...@apache.org>]

ZJRui commented on issue #4086:
URL: https://github.com/apache/rocketmq/issues/4086#issuecomment-1086543695


   > I'm not sure about the purpose of `comsumeLock` when consuming message. It seems like the `objLock` is enough. @guyinyou @panzhi33 can you help confirm this?
   > 
   > [use of comsumeLock](https://github.com/apache/rocketmq/blob/e3b67484b0ea3172cf0555e39efe36c0030c53b3/client/src/main/java/org/apache/rocketmq/client/impl/consumer/ConsumeMessageOrderlyService.java#L490-L508)
   
   
   First ： i mean " other consumer process ", not "other consume thread in one consumer "
   
   Second :  I am wrong . my proposal is wrong. 
   
   There is no need to place the release of the ProcessQueue lock after the commit consume offset. Because the offset  submitted in ConsumeRequest is only submitted to the local memory, the offset is not actually submitted to the Broker.
   
   Therefore, there is no essential difference between the release of the ProcessQueue lock after the listener processes the message and after the offset is submitted in the ConsumeRequest. Neither case actually commits the offset to the Broker.  
   
   
   Third, I think ProcessQueue lock does the following:
   The lock of ProcessQueue is used to represent a state: that is, there are messages being processed in the current ProcessQueue. 
   
   When RebalanceImpl thread  reassigns the MessageQueue, if the MessageQueue no longer belongs to the sequential consumer ,
   Then you need to send a request to the Broker to release the lock of the MessageQueue, but if a message is being consumed by the current consumer, after the MessageQueue is released, the consumers of other processes obtain the MessageQueue, and then pull the message consumption from it, which will
   Causes a MessageQueue to be consumed by two process Consumers at the same time. 
   
   When we have ProcessQueue lock, after the reallocation, the current Consumer will check the lock status of the ProcessQueue when releasing the lock of the MessageQueue. If the ProcessQueue is locked, the release of the lock of the current MessageQueue will be delayed.
   
   
   Fourth: Based on the third point of discussion, I am more puzzled about why we use consumeLock(ReentranceLock) in ProcessQueue to represent this state, instead of simply using volatile boolean
   
   


-- 
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: dev-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org