Page MenuHomePhabricator

When search indexers contend for a lock, just yield
ClosedPublic

Authored by epriestley on Jun 22 2018, 5:05 PM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, Mar 5, 4:24 AM
Unknown Object (File)
Feb 21 2024, 9:18 PM
Unknown Object (File)
Feb 13 2024, 6:23 PM
Unknown Object (File)
Jan 13 2024, 3:30 AM
Unknown Object (File)
Jan 7 2024, 5:48 PM
Unknown Object (File)
Jan 3 2024, 7:30 PM
Unknown Object (File)
Dec 30 2023, 6:11 PM
Unknown Object (File)
Dec 30 2023, 6:11 PM
Subscribers
None

Details

Summary

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

Repository
rP Phabricator
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

amckinley added inline comments.
src/applications/search/worker/PhabricatorSearchWorker.php
48

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.