[
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.
*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:
*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?
> 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: [email protected]
For additional commands, e-mail: [email protected]
