[
https://issues.apache.org/jira/browse/SOLR-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17910508#comment-17910508
]
David Smiley commented on SOLR-17601:
-------------------------------------
Perhaps the server should also return a fingerprint (MD5 hash) of the live
nodes in an HTTP response header, thus efficiently notifying a
CloudSolrClient's ClusterStateProvider that it's live nodes is out-of-date.
> 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.
> *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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
