gunli commented on code in PR #1333:
URL: https://github.com/apache/pulsar-client-go/pull/1333#discussion_r1960838523


##########
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:
   > Actually, I'm thinking that before a message enters the `pendingQueue`, 
even if the user is using the `sendAsync` method, we should block the user's 
call.
   > 
   > This way, on the user side, the timeout should be calculated from when the 
sendAsync method call succeeds; otherwise, it should block at this point.
   
   I have thought about that, but that will be a breaking change. If we change 
it that way, SendAsync will sometimes become SendSync and the config 
`MaxPendingMessages` will become meaningless.



-- 
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]

Reply via email to