← Back to team overview

launchpad-dev team mailing list archive

Re: help with yuixhr_fixture tests in my useoops branch

 

On Sun, Oct 30, 2011 at 10:07 AM, Robert Collins
<robertc@xxxxxxxxxxxxxxxxx> wrote:
> Awesome, thanks Gary.
>
> This highlights a race condition I think:
>  - the ErrorReportingUtility is configured and this is True:
> config.error_reports.error_exchange and rabbit.is_configured()
>  - the config is changed, invalidating rabbit configuration
>  - the first oops generated by the yuixhr tests causes the exception
> you captured
>  - [should it be a worry that they are generating OOPS?]
>
> Now, in production we don't dynamically alter our configuration, so
> this is a testing only issue (which also explains why its not
> affecting all yuixhr using tests, only the tests of the fixtures).

Oh, in response to "
So...maybe error_queue_key needs to be set somewhere else?  Or maybe
we need to do a dance like the one in TestCaptureOopsNoRabbit to make
sure that rabbit is not used in yuixhr?  I bet changes to yuixhr might
need to be mirrored for the appserver layer.

I'm not sure what would be better, making sure rabbit is set up
correctly, or making sure that rabbit is not used at all.  What do you
think?
"

the routing key is optional; I suspect we'll want to be able to get
OOPses from the appserver in yuixhr tests so running without rabbit
isn't ideal - in fact we need *the same rabbit* for yuixhr that the
parent environment has. I haven't [yet] looked at the plumbing holding
this together (I've been chasing wonderful glitches like 'why is
testing.TestCase.setUp called twice()' instead).

Given you have big branches pending, perhaps the best way to approach
this is a two step: permit this branch to land by doing a workaround
(e.g. wrapping the connect() function with a catch
MessagingUnavailable: raise IOError("Socket closed") [pretending to be
an amqlib error]; and then once things have settled down, we can make
sure that the RabbitFixture brought up in the parent environment is
reused in the slave. [whether that is a thread or a subprocess I don't
know yet... see under haven't climbed through the guts yet].

So, pending further feedback from you, I'm going to file a bug about
the race condition this has exposed, implement the workaround
referencing that bug, and wait to catch up with you in 2 weeks :)

-Rob


References