I noticed that async admin requests to Solr must have a unique asyncId or else a request is rejected. Makes sense -- maybe the request is in progress. But what if it isn't -- what if the previous request for the same ID either succeeded or failed? Shouldn't we clear the previous asyncId status and let the new request go through?
I'm imagining leveraging this uniqueness constraint in order to be an additional protection measure against requests that should be done atomically, like a shard split. Yes there are already locks but this additional measure will allow a fail-fast -- no enqueue of a doomed message to the Overseer that will ultimately never succeed any way. Thus the sender of a shard split can use an async ID like "SPLIT-collectionName-shardName". Maybe there are other parts of SolrCloud that could leverage this constraint to its advantage likewise. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
