[Twisted-Python] Dealing with an intermittent PB server

Jp Calderone exarkun at divmod.com
Tue Feb 15 23:28:32 EST 2005


On Tue, 15 Feb 2005 19:56:15 -0800, Dave Cook <daverz at gmail.com> wrote:
>I'm rendering the results of a remote method call:
> 
>     def data_tableList(self, ctx, data):
>         ...
>         d =   self.pbClientFactory.login(creds)
>         d.addCallback(lambda object: object.callRemote("foo"))
>         return d

  Always always always use errbacks.  *Especially* for Deferreds that can 
fail due to transient network conditions.

    def _cbLogin(self, object):
        return object.callRemote("foo")

    def _ebLogin(self, failure):
        return "Sorry, couldn't log in!  (Try hitting ^R maybe)"

    def _ebCallFoo(self, failure):
        return "Sorry, calling foo failed! (Try hitting ^R maybe)"

    def data_tableList(self, ctx, data):
        ...
        d = self.pbClientFactory.login(creds)
        d.addCallbacks(self._cbLogin, self._ebLogin)
        d.addErrback(self._ebCallFoo)
        return d

  These errbacks are lame, but they cause the page to be renderable 
(and more generally, they let the asynchronous operation come to some 
kind of logical conclusion, instead of hanging forever, waiting for 
an error handler which will never arrive).

  Better ones could automatically retry the call, or inform an 
administrator of a possible misconfiguration, or some combination, or
something even smarter.

> [snip]
> but seems like a hack.  Also, ideally, I'd like to attempt a
> reconnection to the PB server at this point if it's not running. 
> What's the best way to do that?

    clientConnectionFailed will be called on the ClientFactory, you
should notice this and attempt to reconnect.  Whether you fail any
outstanding Deferreds which were waiting on the existing connection or
let them survive to possibly succeed over the new one is up to you.

  Jp




More information about the Twisted-Python mailing list