What happened?
While packaging ZMQ connections in the project to ensure high availability, the code uses dialEventSockLoop for constant proactive reconnection to ZMQ, which usually doesn't cause any issues.
However, if ZMQ disconnects during operation, and then we try to close the process, the goroutine becomes stuck here,
|
if err := b.dialEventSock(); err != nil { |
|
log.WithError(err).Error("backend/concentratord: event socket dial error") |
|
time.Sleep(time.Second) |
|
continue |
|
} |
continuously trying to reconnect, hence preventing the process from exiting. It may be necessary to introduce an exit channel here to monitor the exit signals from the main program, thereby facilitating a smooth exit of the goroutine.
Moreover, it seems that the zmq package has some configurations like zmq4.WithAutomaticReconnect and zmq4.WithDialerMaxRetries... Would it be unnecessary, then, to attempt reconnections manually here?
What happened?
While packaging ZMQ connections in the project to ensure high availability, the code uses
dialEventSockLoopfor constant proactive reconnection to ZMQ, which usually doesn't cause any issues.However, if ZMQ disconnects during operation, and then we try to close the process, the goroutine becomes stuck here,
chirpstack-gateway-bridge/internal/backend/concentratord/concentratord.go
Lines 109 to 113 in dfbaf37
continuously trying to reconnect, hence preventing the process from exiting. It may be necessary to introduce an exit channel here to monitor the exit signals from the main program, thereby facilitating a smooth exit of the goroutine.
Moreover, it seems that the zmq package has some configurations like
zmq4.WithAutomaticReconnectandzmq4.WithDialerMaxRetries... Would it be unnecessary, then, to attempt reconnections manually here?