+1. I think as an improvement, a helpful message on how to track the status of the async request should be returned as part of the response of async collection api calls.
Even 1s poll for these commands is okay in real world. On Thu, 29 Jun, 2023, 8:05 pm David Smiley, <david.w.smi...@gmail.com> wrote: > Some (most?) cluster admin commands can be executed in an async mode: > > https://solr.apache.org/guide/solr/latest/configuration-guide/collections-api.html#asynchronous-calls > > What I find really strange and unnecessary is that some of the commands > *internally* operate differently based on whether the command was invoked > this way or not. This adds complexity to understanding / maintenance and > to testing. Instead, I think commands should do sub-steps in whatever way > that makes sense for what the command is doing. I propose that BackupCmd > send requests to each shard asynchronously because it's potentially a heavy > operation. Likewise, some intermediate steps of a shard split could be > time consuming and should always be executed in an async way (e.g. the > actual index splitting step) but not cheap steps. All this is transparent > to the client, by the way. > > The only downside I can think of is that an async issued request will take > a bit longer. But given these are used for heavy commands (that are likely > already being invoked this way) -- I think that's fair. > CollectionAdminRequest.RequestStatus.waitFor polls every 1 second. > SOLR-16313 proposes configurability of this. I would prefer that the > server-side implementation have an option to have it wait up to a > configurable seconds via a ZK watch so that commonly an async command > wouldn't noticeably take any longer. Nonetheless this is just an > improvement proposal; it's not a "blocker" to my proposal above, IMO. > > ~ David >
