Copilot commented on code in PR #142:
URL: https://github.com/apache/dubbo-getty/pull/142#discussion_r3782358854
##########
client.go:
##########
@@ -416,7 +416,28 @@ func (c *client) RunEventLoop(newSession
NewSessionCallback) {
c.Lock()
c.newSession = newSession
c.Unlock()
- c.reConnect()
+ <-c.runReconnect()
+}
+
+func (c *client) runReconnect() <-chan struct{} {
+ done := make(chan struct{})
+ c.Lock()
+ select {
+ case <-c.done:
+ c.Unlock()
+ close(done)
+ return done
+ default:
+ c.wg.Add(1)
+ }
+ c.Unlock()
+
+ go func() {
+ defer c.wg.Done()
+ defer close(done)
+ c.reConnect()
+ }()
Review Comment:
runReconnect starts a new goroutine on every call (go func { ...
c.reConnect() }), but it doesn’t deduplicate concurrent triggers. If multiple
sessions call runReconnect around the same time, multiple reConnect loops can
run concurrently and race to create connections. Because the pool-size check
(sessionNum) and the add to ssMap happen in separate critical sections,
concurrent loops can overshoot c.number and create more sessions than
configured.
Consider guarding reconnect with a single-flight mechanism (e.g., a
reconnectRunning atomic flag / channel) so only one reconnect loop runs at a
time, and subsequent triggers become no-ops while a reconnect is in flight.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
