Gleiphir2769 opened a new issue, #918: URL: https://github.com/apache/pulsar-client-go/issues/918
Now, there are two channels related to clearing messages from `queueCh` and `messageCh` when consume position is reset in the `consumer.dispatcher()`. https://github.com/apache/pulsar-client-go/blob/d92fb1407d3d39c8a498dd7c7abdc0bbb3fc7e1a/pulsar/consumer_partition.go#L1150-L1164 https://github.com/apache/pulsar-client-go/blob/d92fb1407d3d39c8a498dd7c7abdc0bbb3fc7e1a/pulsar/consumer_partition.go#L1168-L1175 The first channel `clearQueueCh` is used to clear legacy messages `queueCh` when connection to broker is rebuild. This clear will reset the `startMessage`. The second channel `clearMessageQueuesCh` is used to clear legacy messages in `queueCh` and `messageCh` when `Seek` is invoked. There are some problems. - The `clearQueueCh` and `clearMessageQueuesCh` have the same effect. It's enough to keep one. - `clearQueueCh` does not clear the legacy messages in `messageCh`, which users can may get the legacy messages after reconnecting to broker. - `clearMessageQueuesCh` is no need to send a flow rpc after clear. Because the permits in broker will not be clear after `Seek`. - `clearMessageQueuesCh` does not reset the `startMessage`, which causes the behavior of `Seek()` is different with Java client. Overall, I think it's a good idea to refactor this part of code. Hi @RobertIndie @nodece , if you think it's need to be refactor, could you assign me for it? -- 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]
