Re: [Twisted-Python] Properly handling Connection Refused
That small script worked as it should. The traceback is exactly the same as in my application. I just wonder where the '[Uninitialized]' is coming from. How is it ending up like that? Is it getting garbage collected for some reason? I can't catch the state of the port fast enough to see if it's anything else in the stack. I am using the poll reactor. I will change it back to the default select reactor and see if I see a problem with it again and see what other tracing I can do. ----- Original Message ---- From: Jean-Paul Calderone <exarkun@divmod.com> To: Twisted general discussion <twisted-python@twistedmatrix.com> Sent: Wednesday, September 5, 2007 12:54:31 PM Subject: Re: [Twisted-Python] Properly handling Connection Refused On Wed, 5 Sep 2007 12:37:16 -0700 (PDT), Beau Hargis <beau@subobscur.us> wrote:
Well, it subclasses 'protocol.ClientFactory'. I did not try 'ReconnectingClientFactory' yet as I wanted a little bit more control of the reconnecting process at some point. In any case, these functions are defined in the class as such:
def clientConnectionFailed(self, connector, reason): print 'Connection failed. Reason: ', reason reactor.callLater(random.randint(10,91), connector.connect)
def clientConnectionLost(self, connector, reason): print 'Connection Lost. Reason: ', reason reactor.callLater(random.randint(10,91), connector.connect)
Works ok for every other problem except Connection Refused. When I first started testing reconnect, the seconds argument to callLater was constant like 3 or 4 seconds and it did the same thing. Even immediate reconnection caused the same problem with Connection Refused: 111.
This looks as though it should work. If I run a similar test program, like this: from twisted.internet.protocol import ClientFactory, Protocol from twisted.internet import reactor class Reconnecter(ClientFactory): def clientConnectionFailed(self, connector, reason): print reason reactor.callLater(5, connector.connect) reactor.connectTCP('localhost', 12345, Reconnecter()) reactor.run() where nothing is bound to localhost:12345, then I see a connection refused message every five seconds for as long as I allow it to run. Can you see if this simple program exhibits the same behavior as your application? It would also be worth determining if your application is receiving the clientConnectionFailed notification but then failing to attempt another connection (ie, some problem with the callLater), if it is attempting the next connection but that is never happening (ie, some problem with the connector.connect), or if clientConnectionFailed isn't even being called for the connection which is failing (some problem inside the reactor with failed connection detection/notification). If you can, it would also be useful to know what the operating system thinks the state of the socket used for the connection attempt is. On Linux, you can get this with a tool like netstat. Jean-Paul _______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
On Wed, 5 Sep 2007 13:24:44 -0700 (PDT), Beau Hargis <beau@subobscur.us> wrote:
That small script worked as it should. The traceback is exactly the same as in my application. I just wonder where the '[Uninitialized]' is coming from. How is it ending up like that? Is it getting garbage collected for some reason? I can't catch the state of the port fast enough to see if it's anything else in the stack. I am using the poll reactor. I will change it back to the default select reactor and see if I see a problem with it again and see what other tracing I can do.
The "Uninitialized" probably isn't something to worry about. It's just the Twisted logging system noticing no one has given it a name for the event source producing log messages. I think someone even filed a ticket today to fix one case which results in this. In any case, it's just the logging system, it shouldn't affect anything else. Jean-Paul
participants (2)
-
Beau Hargis
-
Jean-Paul Calderone