Opened 13 years ago
Closed 13 years ago
#16686 closed Bug (fixed)
Race condition in test_view_decorator()
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Core (Cache system) | Version: | 1.3 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
test_view_decorator has this at the bottom:
# And if we wait a few more seconds time.sleep(5) # the custom timeouot cache will miss response = other_with_timeout_view(request, '18') self.assertEqual(response.content, 'Hello World 18')
This fails on the Ubuntu build machines, although it succeeds on local builds. I got it to pass by bumping up the sleep to 5 seconds, but that's just a bandaid.
Judging from other sleeps in this test, I suspect there are more race conditions lurking.
Attachments (1)
Change History (8)
comment:1 by , 13 years ago
comment:2 by , 13 years ago
I noticed yesterday that the CI install at http://ci.django-cms.org/job/Django/ was showing sporadic failures in the same area of tests. They were inconsistent, indicating there is something race-y going on there with timings, but my initial read didn't show up what it was.
comment:3 by , 13 years ago
When the CI server is under heavy load (running 4 instances of the test suite in parallel), I've seen the following failure:
- http://ci.django-cms.org/job/Django/database=sqlite3,python=python2.5/169/testReport/junit/regressiontests.templates.tests/Templates/test_templates/
- http://ci.django-cms.org/job/Django/database=oracle,python=python2.7/183/testReport/regressiontests.templates.tests/Templates/test_templates/
It isn't a race condition, it's just the machine that runs the tests that isn't "fast enough".
comment:5 by , 13 years ago
Component: | Testing framework → Core (Cache system) |
---|---|
Has patch: | set |
Triage Stage: | Unreviewed → Accepted |
I agree with Russel's theory. I think the best way to fix the problem is to set the cache expiry at 3 seconds (3 < 2 + 2). Patch attached.
by , 13 years ago
Attachment: | 16686.patch added |
---|
comment:6 by , 13 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Is this actually a race condition, or just an issue of being a bit more acommodating with timings? The test sets up the "other" cache with a 1 second expiry; the test has a 2 second sleep (line 1452) to make sure that it expires. There is a second sleep at line 1488; the final test you report is of a view with a 4 second timeout. This might be a bit of a lineball check -- technically, (2x2seconds + time to run other tests) should be > 4 seconds, but on a fast box, it might not evaluate like that. A 3 second sleep at line 1452 should be enough to ensure that the 4 second cache has expires (2 + 3 second sleep).
So - if I've understood the problem here, it isn't a race condition -- just a case where a fast box exposes the fact that 2+2+time for extra work may not be enough time to see the cache expire for the last test.