Harmonize retrieve/recall reporting interface for success.
We now have two scenarios for retrieve reporting (repack and user transfer).
The reporting happens in queued report jobs RecallReportPacker::ReportSuccessful::execute()
, itself executed by RecallReportPacker::WorkerThread::run()
Things are now finalized in 2 separate ways:
- For user transfers, the request is asynchronously deleted (by
RecallReportPacker::ReportSuccessful::execute()
and a chain of direct wrappers). Then when the deletion result is waited for incta::RetrieveMount::waitAndFinishSettingJobsBatchRetrieved()
indirectly through theSchedulerDatabase::RetrieveJob
interface, and finally deleted from ownership inSchedulerDatabase::finishSettingJobsBatchSuccessful()
, - For repack jobs, nothing is actually done at
RecallReportPacker::ReportSuccessful::execute()
time, and then all is done inOStoreDB::RetrieveMount::batchSucceedRetrieveForRepack()
. We first update the status (OStoreDB::RetrieveJob::asyncReportSucceedForRepack()
), thenwait()
for the result, and finally queue the requests in the proper queue for reporting (currently vid of the mount, to be changed to the repack request named queue).
The logic is currently scattered at many level, but the lower level could take up all the value added, and we should move all the user/repack switching to the SchedulerDatabase
level. The higher levels just need to report the success (to trigger the async update or delete of the request, which will ensure no unnecessary retry), and then a single flush()
call should be done on the SchedulerDatabase::RetrieveMount
to wait()
for both deletions and updates, queue jobs where necessary (repack) and them remove jobs from ownership.
This will update the requests earlier for repack and simplify the code in general.