Re: Anyone Written a ReconnectingProxy Object?

Irmen de Jong <[email protected]>
Newsgroups gmane.comp.python.pyro
Message-ID <[email protected]>
On 2013-07-02 13:55, Kent Borg wrote:
> On 06/30/2013 06:10 PM, Irmen de Jong wrote:
>> Alternatively, posted earlier on this mailing list, here is one that
>> should work with older versions of Pyro as well because it doesn't 
>> use
>> MSG_PING: https://gist.github.com/irmen/5787860 It requires your Pyro
>> object to have a 'ping' method though.
> 
> Finally got a chance to look at this (day job and all...), and I like
> it. (Looks like I was subclassing the slightly wrong object and I 
> didn't
> know about _pyroInvoke, a very nice bottleneck for this.)

Even though the underscore suggests it is an internal method and 
"should not be messed with",
it is VERY unlikely that this API will ever change in Pyro 4.x (because 
it is so
fundamental to the way the proxy works). So go ahead and override it :)

> But I have another question: Instead of the "try" doing a ping method,
> why not use the actual desired method instead of the ping--if it works
> we charge on with our work, and only if we get the "except" do we
> reconnect and attempt the same desired method again?

That is certainly more efficient (it avoids the initial ping message).
But this will only work safely 100% with method calls that are 
idempotent.
Most operations don't have this property and calling the method more 
than once
will often result in undesired results.

Why is this a risk: a failure of the initial method call does not
always indicate that the call wasn't processed. It could have been a 
problem with
processing the response message. It is up to you to decide if you want 
to
take this risk. (or design all your remote methods to be idempotent).


Regards
Irmen de Jong


------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.