[
https://issues.apache.org/jira/browse/SOLR-17601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-17601:
--------------------------------
Description:
*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?
was:
CloudSolrClient & Solr (HttpSolrCall, specifically) work together so that
CloudSolrClient knows the collection's client-side cached state is out-of-date.
But the state version is appended to the payload of the response from Solr,
which CloudSolrClient removes (awkward). Furthermore if HttpSolrCall realizes
it needs to proxy the request to another node, it can't (using this strategy)
so it fails the request with HTTP 510 which CloudSolrClient understands. If
that request was retry-able, the client won't know but requests like indexing
are not and so the client sees the error.
I propose using an HTTP response header to have the state version, and to
always supply it from SolrCloud instead of only when a request parameter is
passed.
> 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]
