Just want to bring some visibility to an interesting issue: https://issues.apache.org/jira/browse/SOLR-17601
*Background & problem:* CloudSolrClient & Solr (HttpSolrCall, > specifically) work together so that CloudSolrClient knows its collection's > client-side cached state is out-of-date. HttpSolrCall appends the state > version to the payload of the response, assuming a NamedList, which > CloudSolrClient removes on receipt. This is awkward. If HttpSolrCall > realizes it needs to proxy the request to another node (likely due to an > out-of-date state in the client for talking to the "wrong" node), it can't > (using this strategy) so it fails the request with HTTP 510 which > CloudSolrClient understands. Awkward again. If that request was > retry-able, the user of SolrJ won't know but requests like indexing (HTTP > POST) are not and so the user sees the error. > > *Proposal:* I propose using an HTTP response header to return the state > version. *Always* return it from SolrCloud; can be done for proxied > requests too, letting CloudSolrClient know when to expire its cache entry. > > The *stateVer* parameter and potentially failing with HTTP 510 may be > obsolete? > ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley
