On Tue, Mar 29, 2011 at 12:59 PM, John Arbash Meinel <[email protected]> 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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
