fracasula commented on code in PR #1310:
URL: https://github.com/apache/pulsar-client-go/pull/1310#discussion_r1851963713
##########
pulsar/consumer_partition.go:
##########
@@ -949,6 +949,11 @@ func (pc *partitionConsumer) Close() {
// wait for request to finish
<-req.doneCh
+
+ // It will close `queueCh.in`. If `MessageReceived` was called after
that, it will panic because new messages
+ // will be sent to a closed channel. However, generally it's impossible
because the broker will not be able to
+ // dispatch messages to this consumer after receiving the close request.
+ pc.queueCh.stop()
Review Comment:
I see that you're not closing `closeCh` here but you're just closing `inCh`
and `outCh`.
Beware because `closeCh` is an unbuffered channel and once you call `stop`
the first time the listener of that channel will return so any subsequent
`c.closeCh <- struct{}{}` is going to block forever and it will be hard to
detect.
Wouldn't it be better to just close `closeCh`? It will have the same side
effect but at least if you `stop` twice, you'll catch it instead of silently
being stuck. Given that you're not planning to call `stop` multiple times,
wouldn't it be better to close `closeCh` then? Wdyt?
--
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]
