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
