[Twisted-Python] Properly handling Connection Refused

[Jean-Paul Calderone]

On Wed, 5 Sep 2007 12:37:16 -0700 (PDT), Beau Hargis <beau at 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