Page MenuHomePhabricator

When search indexers contend for a lock, just yield

Authored by epriestley on Jun 22 2018, 5:05 PM.



Depends on D19503. Ref T13151. See PHI719. If you have something like a script which updates an object in a loop, we can end up queueing many search reindex tasks.

These tasks may reasonably contend for the lock, especially if the object is larger (lots of text and/or lots of comments) and indexing takes a few seconds.

This isn't concerning, and the indexers should converge to good behavior quickly once the updates stop.

Today, they'll spew a bunch of serious-looking lock exceptions into the log. Instead, just yield so it's more clear that there's (normally) no cause for concern here.

Test Plan

Ran bin/search index Txxx --force on a large object in multiple windows with a 0 second lock, saw an explicit yield instead of a lock exception.

Diff Detail

rP Phabricator
Lint Not Applicable
Tests Not Applicable

Event Timeline

amckinley added inline comments.

I guess doing anything more complicated like exponential backoff would be overkill, and this at least ensures the indexing will happen within 15 seconds of the update torrent from stopping.

This revision is now accepted and ready to land.Jun 22 2018, 11:22 PM
This revision was automatically updated to reflect the committed changes.