Gleiphir2769 commented on code in PR #921:
URL: https://github.com/apache/pulsar-client-go/pull/921#discussion_r1057178056
##########
pulsar/consumer_partition.go:
##########
@@ -1134,37 +1144,19 @@ func (pc *partitionConsumer) dispatcher() {
go func() {
pc.queueCh <- nil
}()
+
for m := range pc.queueCh {
// the queue has been drained
if m == nil {
break
} else if nextMessageInQueue.Undefined() {
- nextMessageInQueue =
m[0].msgID.(trackingMessageID)
+ nextMessageInQueue, _ =
toTrackingMessageID(m[0].msgID)
}
}
- clearQueueCb(nextMessageInQueue)
-
- case doneCh := <-pc.clearMessageQueuesCh:
- for len(pc.queueCh) > 0 {
- <-pc.queueCh
- }
- for len(pc.messageCh) > 0 {
- <-pc.messageCh
- }
messages = nil
- // reset available permits
- pc.availablePermits.reset()
- initialPermits := uint32(pc.queueSize)
-
- pc.log.Debugf("dispatcher requesting initial
permits=%d", initialPermits)
- // send initial permits
- if err := pc.internalFlow(initialPermits); err != nil {
- pc.log.WithError(err).Error("unable to send
initial permits to broker")
- }
-
- close(doneCh)
+ clearQueueCb(nextMessageInQueue)
Review Comment:
> Do you forget the reset available permits?
Hi. @nodece, I don't think it's necessary to reset available permits. In the
user side, if permits over the threshold, `internalFlow` will be invoked.
https://github.com/apache/pulsar-client-go/blob/1d3499a18d526b4b1aef0bdbbc54ac812b8ae0c0/pulsar/consumer_partition.go#L196-L208
In the broker side, I checked the relative code and doesn't find any need to
reset it. The Java Client does not reset it too.
So I think it's no need to reset the available permits. I don't understand
why should reset it in the legacy code and I guess it's just a mearsure taken
for safe.
--
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]
