Lock when archiving and avoid invalidating sites that have archiving in progress #15272
Conversation
diosmosis
added
not-in-changelog
core/ArchiveProcessor/Loader.php
Outdated
| return $idArchive; | ||
| } | ||
| } finally { | ||
| $archivingStatus->archiveFinished($lock); |
There was a problem hiding this comment.
fyi archiveFinished does not take an argument and above the archiveStarted () does not return a value
There was a problem hiding this comment.
@diosmosis left few comments. Be good in general to test this on demo for few days.
core/Archive/ArchiveInvalidator.php
Outdated
| $periodDates = $this->getUniqueDates($periodDates); | ||
|
|
||
| $idSites = $this->removeSitesWithInProgressArchiving($idSites); |
There was a problem hiding this comment.
@diosmosis not sure I understand why we would filter the idSites here and not just invalidate all of them? Is this because we assume they were already invalidated / will be invalidated? Would there be any harm in still invalidating them or the issue that this would cause the remember flag to be removed?
There was a problem hiding this comment.
I wonder maybe we could still invalidate archives for the other idSites as well just not remove the remember flag?
There was a problem hiding this comment.
We remove them because we know they are currently being archived. We also keep the idSites in the remember flags so they will eventually be invalidated when they are not being archiving.
There was a problem hiding this comment.
Just wondering if there could be meanwhile some other previously finished archives for those idSites that need to be invalidated?
There was a problem hiding this comment.
There could be, but because of the way the function parameters are (idSites + list of dates + period type), it's a bit harder to control exactly what to invalidate. We'd have to loop over idSites & dates and check each individually, and invalidate each archive individually instead of with one query (which is what we do now I think).
There was a problem hiding this comment.
@diosmosis it is very important we respect these configured values. We basically need to check if the last archive was done more than the configured time ago even if the archive is invalid (unless the archive is invalid and it is a new day I think then we don't respect these values but not sure? @mattab )
and keep the locks but don't do anything different in ArchiveInvalidator?
I'm not quite fully understand this part but be good in general to maybe still invalidate an archive in ArchiveInvalidator? Not sure of consequences of not using Locks?
There was a problem hiding this comment.
Not sure of consequences of not using Locks?
It's just an easy way to check if an archive is on-going no matter what machine/process it's on. It's not really necessary, but it might be useful in the future.
There was a problem hiding this comment.
It's just an easy way to check if an archive is on-going no matter what machine/process
@diosmosis it would be big value if it would help with this issue: #8444 -> maybe it would be fixed?
unless the archive is invalid and it is a new day I think then we don't respect these values but not sure? @mattab
correct, these INI settings are only used when the date range includes Today.
There was a problem hiding this comment.
just wanting to make sure we're not going to work on #8444 as part of this issue :)
| $this->defaultTtl = $defaultTtl; | ||
| } | ||
|
|
||
| public function reexpireLock() |
There was a problem hiding this comment.
should it be maybe reExpireLock? Not too important though...
There was a problem hiding this comment.
Yeah, it looks weird to me too. But so did reExpireLock and I couldn't choose :)
| /** @var ArchivingStatus $archivingStatus */ | ||
| $archivingStatus = StaticContainer::get(ArchivingStatus::class); | ||
| $archivingLock = $archivingStatus->getCurrentArchivingLock(); | ||
| return new ArchivingDbAdapter(Db::getReader(), $archivingLock, $this->logger); |
There was a problem hiding this comment.
@diosmosis is there a chance you forgot to commit this file?
There was a problem hiding this comment.
a chance? no... I definitely forgot to commit it :) added now
|
I'll add this to demo soon |
|
@tsteur added back old functions and added a test for the Loader method that uses them |
|
@diosmosis maybe we can run this code on demo for a while? |
|
@tsteur it should be running on demo2 |
|
@diosmosis do you know of any issue on the demo? Maybe we could merge and release a new beta? |
|
The metrics for the last two week seem accurate, I'm not aware of any issues (though I don't get emails if demo2 has an issue). |
|
There was no error from demo2 in the last few days. @tsteur @diosmosis can you merge this and let me know, i'll release the next beta? |
…in progress (matomo-org#15272) * Use a lock when archiving and do not invalidate when archiving is in progress. * Add and fix tests + modify workflow. * forgot to add file and remove TODO * Remove use of argument. * Add back min archive time processed code and start on tests for it. * Finish new LoaderTest. * Fix new tests.
…in progress (matomo-org#15272) * Use a lock when archiving and do not invalidate when archiving is in progress. * Add and fix tests + modify workflow. * forgot to add file and remove TODO * Remove use of argument. * Add back min archive time processed code and start on tests for it. * Finish new LoaderTest. * Fix new tests.
When archiving for a site begins, we create a Lock and only release when archiving finishes or fails.
The lock's expire time is updated on each query (the TTL can be configured via DI).
There is also a change to log each archiving query (previously this was just in LogAggregator, but now it will affect all archivers).
I think we should deploy this to demo and see if it works after a day or two (after getting tests to pass of course).
Note: with this implementation it's possible for archiving to start while an invalidation is occurring, which would cause issues. I'm not sure how big of a risk it is since the invalidation queries are fairly simple. There could be a few of them though.
Fixes #15170