Hi Mikel, many thanks for the excellent reply. Yep, I'm talking about deadlock happening somewhere in the interpreter/cucmber/selenium stack. I can fairly confidently rule out this being a database thing, having done some more poking around since Bo's suggestion last night. (I mean "deadlock" as in philosophers dining, not as in the common SQL database exception message. <grin>)
I'll give your fix a try. Perhaps the key would be to modify my step definitions to always check a call has returned. When you say AJAX call, do you mean AJAX on the actual application's page, or is this something to do with the WebDriver interface? We aren't (deliberately) making any AJAX calls in our app. I'm not sure if this is related, but we have also had very strange things happening with capybara, where it becomes really, really slow (as in, 1 step every 2 minutes or so). Again, causes seem non-deterministic--and it's really degrading the quality of our test suite. I've been treating capybara as a bit of a black box, and I have to confess I really don't know anything about its internals. Is there any way to make browser calls block until they've been executed by the browser, so this can't happen? Muchas gracias, - alex. On 08/10/2010, at 2:57 AM, Mikel Lindsaar wrote: > Hi Alex, > > What is the deadlock, are you talking about an exception being thrown by the > DB deadlocking? > > If you are talking about a cucumber / selenium "deadlock" as in it just sits > there waiting for something to appear, this can happen when the test suite is > moving too fast for updates to happen... > > For example: > > Given I am on the home page > ( this site adds a "login" link once the remote user IP Address is > checked first) > And I follow "login" > Then I should be on my dashboard. > > This will fail if the ajax call does not get the login link to appear before > the test tries to follow the login link. > > A way to solve this is add an explicit expectation before the follow: > > Given I am on the home page > Then I should see "login" > When I follow "login" > Then I should be on my dashboard. > > This way, the system waits for the login link to appear before trying to > follow it. > > Mikel > > > > On 08/10/2010, at 12:32 AM, Alex Cooper wrote: > >> Hi everybody, >> >> I uncovered a rather unnerving race condition at work (GetUp) today, and I'd >> love to know if anyone else has seen this. >> >> I've been getting a erratic, but reproducible lockups under ruby 1.9.2 and >> cucumber/capybara [1]. But under ruby 1.8.7 it's fine. >> >> This sucks, because we'd really like to use 1.9.2 for its much improved >> performance. >> >> The cucumber script does nothing special. Populate the DB, fill in some >> fields, press a button or two. Sometimes cucumber hangs midway through the >> test--but at different locations. This behavior is seen on other features, >> too, but it's mainly in the same few scenarios. >> >> Steps to reproduce: >> rvm use 1.8.7 >> bundle exec cucumber features/example.feature [2] >> observe soothing green output >> rvm use 1.9.2 >> bundle exec cucumber features/example.feature >> tear hair out when deadlock occurs [3] >> >> The kicker is that it happens in different places in the cucumber script, >> and there's no predictable pattern I can discern as to exactly which step >> (or type of step) will hang. >> >> I suspect deadlock, because output halts midway through a scenario, CPU >> drops to zero, memory usage remains stable, and Ruby no longer responds to >> SIGINT (which I think it normally would). >> >> So, my questions for the floor are, in increasing order of importance: >> Has anyone on the list experienced (and hopefully fixed) this problem? >> How would you approach tracking this bad boy down? (Preferably not involving >> MRI source code and gdb.) >> Which particular alcoholic beverage is preferred for drowning one's sorrows >> while debugging bugs like this? >> >> Cheers, and many thanks in advance, >> >> - alex. >> >> Notes: >> The environment is: Rails 3.0, Ruby 1.9.2, cucumber 0.9.0, cucumber-rails >> 0.3.2, webrick 1.3.1, postgres 8.4.4, OSX Snow Leopard >> There really is nothing special about this script--it just fills in inputs >> and pushes buttons. >> On different machines, deadlock occurs with different frequency. On my >> (slow) MBP with 2G memory, it happens about 70% of the time. On a >> colleague's older (but faster) machine, it locks up around 30% of the time. >> >> -- >> Alex Cooper m: 0402 024 304 w: http://acooper.org/ >> t: @kuperov >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby or Rails Oceania" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/rails-oceania?hl=en. > > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. -- Alex Cooper m: 0402 024 304 w: http://acooper.org/ t: @kuperov -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
