[jira] [Created] (SOLR-6550) Provide simple mechanism for passing additional metadata / context about a server-side SolrException back to the client-side

["Timothy Potter (JIRA)" <ji...@apache.org>]

Timothy Potter created SOLR-6550:
------------------------------------

             Summary: 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


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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org