recaptime.dev / phorge
@recaptime-dev's working patches + fork for Phorge, a community fork of Phabricator. (Upstream dev and stable branches are at upstream/main and upstream/stable respectively.) hq.recaptime.dev/wiki/Phorge
phorge phabricator
1
fork

Configure Feed

Select the types of activity you want to include in your feed.

When search indexers contend for a lock, just yield

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.

Reviewers: amckinley

Reviewed By: amckinley

Maniphest Tasks: T13151

Differential Revision: https://secure.phabricator.com/D19504

epriestley d84f866c 14e911a0

+9 -1
+9 -1
src/applications/search/worker/PhabricatorSearchWorker.php
··· 38 38 $key = "index.{$object_phid}"; 39 39 $lock = PhabricatorGlobalLock::newLock($key); 40 40 41 - $lock->lock(1); 41 + try { 42 + $lock->lock(1); 43 + } catch (PhutilLockException $ex) { 44 + // If we fail to acquire the lock, just yield. It's expected that we may 45 + // contend on this lock occasionally if a large object receives many 46 + // updates in a short period of time, and it's appropriate to just retry 47 + // rebuilding the index later. 48 + throw new PhabricatorWorkerYieldException(15); 49 + } 42 50 43 51 try { 44 52 // Reload the object now that we have a lock, to make sure we have the