Description
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.
Attachments
Attachments
Issue Links
- is duplicated by
-
SOLR-5938 ConcurrentUpdateSolrServer don't parser the response while response status code isn't 200
-
- Closed
-