[
https://issues.apache.org/jira/browse/SOLR-18344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated SOLR-18344:
----------------------------------
Labels: pull-request-available (was: )
> Backup status is not reported on /replication?command=details until the
> backup completes
> ----------------------------------------------------------------------------------------
>
> Key: SOLR-18344
> URL: https://issues.apache.org/jira/browse/SOLR-18344
> Project: Solr
> Issue Type: Bug
> Components: Backup/Restore
> Affects Versions: 10.0, main(11.0), 9.10.1
> Reporter: Idan Tepper
> Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The "backup" key in the /replication?command=details response is only
> populated once a backup has finished. While one is running there is no
> indication that it is running, and the key still holds the *previous*
> backup's payload -- including "status": "success".
> Anything that issues /replication?command=backup and then polls
> command=details therefore reads the stale "success" of an earlier backup as
> the result of the one it just started, and concludes the new backup is
> already done. With no prior backup the key is simply absent, so a poller
> cannot distinguish "running" from "never started".
> SnapShooter.createSnapAsync already accepts a Consumer<NamedList<?>> that
> ReplicationHandler wires to its volatile snapShootDetails field, which
> getReplicationDetails publishes under the "backup" key. That consumer is only
> invoked once, at the very end of the snapshot.
> Proposal: keep the consumer and emit through it while the snapshot
> progresses, adding two in-progress statuses ahead of the existing terminal
> ones:
> * "waiting for commit" -- published synchronously, before the worker thread
> starts, so a stale "success" can no longer be mistaken for the new backup's
> result. Carries no file counts, as the index commit (and with it the file
> list) is not resolved yet.
> * "running" -- published after each file is copied, with "fileCount" and
> "finishedFileCount" so callers can show progress.
> The existing "success" and exception payloads are unchanged. The change is
> additive to the
> response and needs no change to ReplicationHandler.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
