On 28/04/17 09:23 AM, Julien Danjou wrote: > On Fri, Apr 28 2017, gordon chung wrote: > >> what if we just don't lock ever on delete, but if we still check lock to >> see if it's processed. at that point, the janitor knows that metric(s) >> is deleted, and since no one else is working on sack, any metricd that >> follows will also know that the metric(s) are deleted and therefore, >> won't work on it. > > I did not understand your whole idea, can you detail a bit more? > Though the "check lock" approach usually does not work and is a source > of race condition, but again, I did not get the whole picture. :) >
my thinking is that, when the janitor goes to process a sack, it means it has indexer state from time 00:00:00. if the sack is locked, then it means a processing worker is looking at sack and has indexer state from time <= 00:00:00. if the sack is unlocked, then it means a processing worker isn't looking at the sack, and when it does lock the sack, it first has to check sack for existing measures to process and then check indexer to validate that they are still active. because it checks indexer later, even if both janitor and processing worker check lock at same time, we can guarantee it will have indexer state processing worker sees is > 00:00:00 since janitor has state before getting lock, while processing worker as state sometime after getting lock. -- gord __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
