Code

Opened 3 years ago

Closed 3 years ago

#16686 closed Bug (fixed)

Race condition in test_view_decorator()

Reported by: barry@… 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 aaugustin)

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)

16686.patch (679 bytes) - added by aaugustin 3 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 3 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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.

comment:2 Changed 3 years ago by mtredinnick

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 Changed 3 years ago by aaugustin

When the CI server is under heavy load (running 4 instances of the test suite in parallel), I've seen the following failure:

It isn't a race condition, it's just the machine that runs the tests that isn't "fast enough".

comment:4 Changed 3 years ago by aaugustin

  • Description modified (diff)

Fixed formatting.

comment:5 Changed 3 years ago by aaugustin

  • Component changed from Testing framework to Core (Cache system)
  • Has patch set
  • Triage Stage changed from Unreviewed to 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.

Changed 3 years ago by aaugustin

comment:6 Changed 3 years ago by russellm

  • Triage Stage changed from Accepted to Ready for checkin

comment:7 Changed 3 years ago by jezdez

  • Resolution set to fixed
  • Status changed from new to closed

In [16728]:

Fixed #16686 -- Reduced time to wait for cache expiration in a test to alleviate race-condition-y effects.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.