[
https://issues.apache.org/jira/browse/SOLR-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17909300#comment-17909300
]
Jason Gerlowski commented on SOLR-17601:
----------------------------------------
Sounds like a much better approach, +1
> HttpSolrCall: INVALID_STATE: use an HTTP response header instead
> ----------------------------------------------------------------
>
> Key: SOLR-17601
> URL: https://issues.apache.org/jira/browse/SOLR-17601
> Project: Solr
> Issue Type: Improvement
> Components: SolrCloud, SolrJ
> Reporter: David Smiley
> Priority: Major
>
> *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?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
