[
https://issues.apache.org/jira/browse/SOLR-6550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163700#comment-14163700
]
ASF subversion and git services commented on SOLR-6550:
-------------------------------------------------------
Commit 1630164 from [~thelabdude] in branch 'dev/branches/lucene_solr_4_10'
[ https://svn.apache.org/r1630164 ]
SOLR-6550: backport to 4_10 branch so we can backport SOLR-6511
> Provide simple mechanism for passing additional metadata / context about a
> server-side SolrException back to the client-side
> ----------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-6550
> URL: https://issues.apache.org/jira/browse/SOLR-6550
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Reporter: Timothy Potter
> Assignee: Timothy Potter
> Fix For: 5.0
>
> Attachments: SOLR-6550.patch
>
>
> While trying to resolve SOLR-6511, it became apparent that I didn't have a
> good way to convey more information about a particular error occurring on the
> server-side using SolrException. The specific situation I encountered is a
> replica took over as leader, but the previous leader wasn't aware of that yet
> (due to a Zk session expiration). So when the previous leader (the one that
> experienced the Zk session expiration) sent an update request with
> FROMLEADER, the new leader rejected the request with a SolrException.
> Ideally, we want the new leader to be able to say "you're not the leader
> anymore" and for the previous leader to fail the request in a specific way;
> see SOLR-6511 for more background on this scenario.
> My first inclination was to just extend SolrException and throw a
> LeaderChangedException and have the client behave accordingly but then I
> discovered that CUSS just takes the status code and error message and
> reconstructs a new SolrException (on the client side). HttpSolrServer does
> the same thing when creating a RemoteSolrException. So the fact that the
> server-side throw a LeaderChangeException is basically lost in translation.
> I'm open to other suggestions but here's my approach so far:
> Add a {{NamedList<String> metadata}} field to the SolrException class.
> If a server-side component wants to add additional context / metadata, then
> it will call: {{solrExc.setMetadata("name", "value);}}
> When the response is being marshaled into the wire format, ResponseUtils will
> include the metadata if available. On the client side, when the response is
> processed, the metadata gets included into the new SolrException (in CUSS) or
> RemoteSolrException (HttpSolrServer). It's up to the client to dig into the
> metadata to take additional steps as I'll be doing in
> DistributedUpdateProcessor.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
