[GitHub] [rocketmq] mz0113 opened a new issue, #4742: 消费者consumer调用 resetOffset 时pullRequest没清理导致可能存在的一个概率性BUG

Sun, 31 Jul 2022 04:08:30 -0700 


mz0113 opened a new issue, #4742:
URL: https://github.com/apache/rocketmq/issues/4742

   
   
   版本：v4.9.3和v4.9.4 都存在
   代码位置：org.apache.rocketmq.client.impl.factory.MQClientInstance#resetOffset
   
   
![image](https://user-images.githubusercontent.com/42512469/182022748-ae056af9-5555-401a-947d-b0a75ac7e80a.png)
   
   我调用上述API希望重置消费端位移,但是我感觉有2个概率性BUG
   第一个：
   consumer.updateConsumeOffset(mq, offset); 
   
这一句执行完毕后,会把提交位移重置为我传入的位移参数,但是问题就出现了,如果当时消费线程A已经走到了updateConsumeOffset()这段代码，在刚才设置processQueue.drpped(true)时候就已经过了那个下图220行的卡控了,那么消费线程A就会提交位移把我自己传入的位移覆盖掉！
   
![image](https://user-images.githubusercontent.com/42512469/182023058-1c1a9fac-01a3-47c9-af1e-ddd05c1b6c28.png)
   所以我认为在消费线程设置完位移之后应该在此判断是否dropped了,如果为true,应该撤销位移的提交,当然这个也不是完全准确。理论上要加锁处理
   
   
   第二个：
   还是第一张图上,虽然调用了 iterator.remove(); 
把processQueue移除掉了,但是此时可能还有pullRequest正在拉取消息（同样的也是先拉取消息的路上了，才设置suspend标记或者dropped
 
processQueue，此时因为卡控已经代码走过去了，所以卡控无效）。然后消息拉取回来以后在callBack中又会继续拉取消息，但其实这个pullRequest不应该反复再去拉消息了，因为它拉消息用的nextBeginOffset是重置offset之前的那个。
   
![image](https://user-images.githubusercontent.com/42512469/182023258-bccbf4eb-3f46-49ae-b96d-e7991b9e9928.png)
   
   


-- 
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