fix issue 650,different handle sequence value #651
Conversation
|
@merlimat @freeznet @wolfstudy PTAL |
| @@ -784,57 +784,57 @@ func (p *partitionProducer) ReceivedSendReceipt(response *pb.CommandSendReceipt) | |||
| return | |||
| } | |||
|
|
|||
| if pi.sequenceID != response.GetSequenceId() { | |||
| if pi.sequenceID < response.GetSequenceId() { | |||
There was a problem hiding this comment.
What happens if the response sequence id is greater than the pi.sequenceID? Is that case handled anywhere and does it need to be? How does this change reduce the number of closed connections?
There was a problem hiding this comment.
response sequence id greater than the pi.sequenceID is error case, response sequence id must be equal or less than pi.sequenceID in one connection
There was a problem hiding this comment.
I understand that. The previous code would return an error and close the connection when the sequenceId did not match. So the sequence id could be greater or less than. Unless I'm missing something this change seems to only return an error when the sequenceId is less.
Does the client need to handle the case when the sequence id is greater? Can that happen?
Also, for my own understanding does this change reduce the number of reconnections mentioned in the issue?
There was a problem hiding this comment.
this change will be reduce the number of reconnections only. this is very important.
There was a problem hiding this comment.
Now there are 2000 pod to consume one topic, mean there are 2000 consumers for one partitions, if this code is not bean changed , many times consumers need to be restarted.
Another words , this handle way is different with java sdk.
There was a problem hiding this comment.
@cckellogg It seems that in some scenarios, the condition of pi.sequenceID <response.GetSequenceId() will be true, causing the connection to be closed. And @baomingyu they have more consumer objects under one connection, so when the reconnection happens, the impact on their business itself is magnified?
There was a problem hiding this comment.
pi.sequenceID < response.GetSequenceId() is error case，the channel must be closed when it has happed. And
pi.sequenceID > response.GetSequenceId() case should not do close way.
There was a problem hiding this comment.
So are you suggesting we follow the logic of the java client and handle the 3 cases this way?
1 - pi.sequenceID > response.GetSequenceId() => return (could there ever be a pending item in the queue that gets left around?)
2 - pi.sequenceID < response.GetSequenceId() => error close connection
3 - pi.sequenceID == response.GetSequenceId() => process
There was a problem hiding this comment.
yes， @cckellogg
Client should reduce close connection.
There was a problem hiding this comment.
Can we add a log for the last condition pi.sequenceID > response.GetSequenceId() just to track if we ever see it?
Also, if this condition ever happens do we leak pending items?
Fixes #650
Modify handle CommandSendReceipt command way same with java client ,
and when response's sequenceID is less than max sequenceID in pendingQueue will not close cnx.
Master Issue: #650