On Thu, Mar 17, 2005 at 02:28:06PM +0000, Jp Calderone wrote:
For some reason unfathomable to me, ReconnectingClientFactory _stops_ trying to reconnect if a UserError is the cause of failed connection. Further, for some reason, error.TimeoutError subclasses UserError. This has bitten at least one other project (buildbot).
Ok great that you could explain it so quickly!
I'm inclined to say that it is indeed a bug. I think ReconnectingClientFactory should always retry the connection, regardless of the exception with which the previous attempt fails. If a program wants to allow a user to interrupt the retry logic, there is a "stopTrying" method.
Definitely agreed. I think at very least the error.TimeoutError should not stop the reconnection (dunno about the others subclassing UserError). For sure I'd rather prefer that it tries to reconnect no matter what.
If you look at twisted/internet/protocol.py for the definition of ReconnectingClientFactory.clientConnectionFailed, it should be pretty obvious how you want to redefine clientConnectionFailed to avoid the behavior you're seeing.
I'll look into a workaround.
It's generated internally by Twisted when the alloted connection time has elapsed without a connection being created.
Most likely it _is_ network related problems that caused the connection to fail, but Twisted is certainly responsible for the decision to cease further reconnection attempts.
Ok.