gunli commented on code in PR #1333:
URL: https://github.com/apache/pulsar-client-go/pull/1333#discussion_r1961179608
##########
pulsar/producer_partition.go:
##########
@@ -581,7 +581,8 @@ func (p *partitionProducer) runEventsLoop() {
}
case connectionClosed := <-p.connectClosedCh:
p.log.Info("runEventsLoop will reconnect in producer")
- p.reconnectToBroker(connectionClosed)
+ // reconnect to broker in a new goroutine so that it
won't block the event loop, see issue #1332
+ go p.reconnectToBroker(connectionClosed)
Review Comment:
> No, It's still async; it just sends directly when disable the batch (but
doesn't wait for the callback). If I remember correctly, Java implements it
this way too.
>
> I think this is the simplest and most straightforward solution and I not
think there have any break change.
I don't think so. You cannot call it asynchronous when you block the user
from calling SendAsync if the length of the PendingQueue is not equal to or
greater than MaxPendingMessages.
I have read the code of connection.go, I believe it would be better to make
the connection's write methods (connection.SendRequest(),
connection.SendRequestNoWait(), connection.WriteData()) synchronous. Currently,
we are already sending data in a separate goroutine, and starting a new
goroutine again to send data inside the connection itself only makes things
more complicated.
--
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]
