launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Tue, Mar 29, 2011 at 12:59 PM, John Arbash Meinel
<john@xxxxxxxxxxxxxxxxx> wrote:
> ...
>>> I believe there are things like Failure.trap() and xmlrpc.trap_fault()
>>> that can do a bare 'raise' to re-raise the original exception because it
>>> doesn't match the exact type that the error handler can handle.
>>
>> Neither of those is a problem, although I had to check earlier today to
>> be sure :)
>>
>> Failure.trap() will re-raise the original Failure (it's an old-style
>> class, which Python allows to be raised, like how it allows you to raise
>> strs).  Calling Failure() when the active exception is a Failure does
>> some magic that ends up setting self.__dict__ = raised_failure.__dict__,
>> so the result of Failure() in that case doesn't have self.tb set if the
>> original failure didn't either.
>>
>> lp.services.twistedsupport.xmlrpc.trap_fault is the same: the only thing
>> it raises is the failure given to it (either via Failure.trap or
>> directly).  So it's ok too.
>>
>
> Right. So I added the tracing with
> "mutter(''.join(traceback.format_stack()))" whenever Failure has a tb.
> And it looks like it is always happening in the DeferredBlockingProxy
> case. I think we can easily trap that one.
>
> However, the timings I see make me wonder if the same thing is also
> happening in the XMLRPC *server*. Because with your patch, I thought the
> xmlrpc times were actually too high, and re-ran it about 10 times to
> make sure I wasn't seeing things.
>
> So doing "Failure.__init__ tb=None" was also having an effect on the
> xmlrpc side, I just don't see that from the bzr-forker log file. I'll
> try to update my instrumentation and see if I see anything on the xmlrpc
> side.
>

I'm confused. The XML-RPC server isn't using Deferreds at all.

jml