On 22/03/2019 23:26, Chris Satterthwaite wrote:
Hi Chris,
The files I attached (with the full classes) made it through to my email, but I wondered if they would they go through to everyone.
Here's a gist with the same scripts: https://gist.github.com/codingadvocate/f732da79ddf6cef4b7a0b6b3679f519f
And yep, as you mentioned, a 'sleep' is definitely blocking. That's not in the production version; I just dropped it in here for the test script to simulate something.
Observations: - Your super call at https://gist.github.com/codingadvocate/f732da79ddf6cef4b7a0b6b3679f519f#file..., I'd expect that to be super(ServiceClientFactory, self).__init__(), but your spelling may be a python 3 only thing that works? - Those sleeps are going to cause you more problems than they solve. - What does this seek to achieve? https://gist.github.com/codingadvocate/f732da79ddf6cef4b7a0b6b3679f519f#file... - Why not use twisted logging instead of print? By setting it to debug, you'll get lots of into about what twisted is doing, and by using logging you won't need to do all that manual traceback printing. - when you say "When the client hits a problem, it calls transport.loseConnection()", where is that call to transport.loseConnection? - when you noticed some Twisted source code that works off factory.numPorts, where is that code? Can you provide a link? This doesn't sound right... Now, as to what your problem is, I suspect it's this call to stopTrying: https://gist.github.com/codingadvocate/f732da79ddf6cef4b7a0b6b3679f519f#file... The factory is stopped and started again by ReconnectingClientFactory, so you don't want that there as it means you stop trying every time there's a disconnection. cheers, Chris