Whenever debugging my code, I've noticed that the following code block from TcpConnectionPool.js can trigger an infinite "self called" setTimeout loop :
realSend(message) {
const self = this;
if(this.connected === true) {
this.connection.write(message)
} else {
const timeout = setTimeout(() => {
self.realSend(message);
clearTimeout(timeout);
}, this.connectionNotReadyRetryInterval);
}
}
I guess it can occur in edge case situations (maybe due to debugging) when :
- the connexion is not yet established whenever the
realSend is called first
- but it fails to be established after the first Timeout is setup, and thus, the
self.connected = true; lamda in the TcpConnectionWrapper will never be triggered, and the loop will goes on forever
Calling the destroy method should raise a flag or a notification, a way or another, that could either break the Timeout loop, or even better, break it AND retry to establish a connection to send the message
Can't imagine (yet ?) a scenario that could trigger this case in production (I.E. without debugging interfering), but I feel like it would be much better been conservative and manage this potential bug anyway.
Whenever debugging my code, I've noticed that the following code block from
TcpConnectionPool.jscan trigger an infinite "self called"setTimeoutloop :I guess it can occur in edge case situations (maybe due to debugging) when :
realSendis called firstself.connected = true;lamda in theTcpConnectionWrapperwill never be triggered, and the loop will goes on foreverCalling the
destroymethod should raise a flag or a notification, a way or another, that could either break the Timeout loop, or even better, break it AND retry to establish a connection to send the messageCan't imagine (yet ?) a scenario that could trigger this case in production (I.E. without debugging interfering), but I feel like it would be much better been conservative and manage this potential bug anyway.