[
https://issues.apache.org/jira/browse/SOLR-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-4487:
---------------------------
Assignee: Hoss Man
Summary: SolrException usage in solrj client code can't handle all
possible http error codes returned by servers -- example "413 Request Entity
Too Large" (was: Add "413 Request Entity Too Large" to SolrException.ErrorCode)
Once upon a time (before SolrJ even existed), SolrException's constructor took
in an arbitrary numeric code, and it was being used inconsistently, so the
ErrorCode enum was defined to help ensure that when errors were thrown by solr,
they were thrown using a consistent, finite subset, of http status codes that
could be propagate to the end user.
But once solrj was added, and we started using SolrException in clients to wrap
any and all errors returned by Solr via HTTP, i think it's a mistake to
continue limiting SolrException to this enumeration.
Solr as a server should still have a finite, limited list of error codes that
it throws, but if the SolrException is going to be used in the client, then it
needs to be able to handle all of the possible status codes that might be
returned by any arbitrary http server (or proxy) that the client is talking to.
The really ironic thing is that SolrException still tracks & exposes the status
code as an arbitrary int (via the code() method) -- it's only the constructor
that limits you to the ErrorCode enum.
So i propose we re-add a constructor to SolrException that accepts an arbitrary
int error code, and start using that in client code like HttpSolrServer where
we are building up an exception from an arbitrary http server response.
The addition is trivial, but we should obviously add some javadocs explaining
when/why to use each constructor...
{noformat}
public SolrException(int code, String msg, Throwable th) {
super(msg, th);
this.code = code;
}
{noformat}
...any objections?
alternative suggestion: add a package protected (or private?) subclass of
SolrException to org.apache.solr.client.impl (or maybe even directly in
HttpSolrServer) and put this constructor there.
i actually think i kind of like this alternative idea better, because i would
help mitigate the risk of people using the int constructor with bogus error
code values in other solr code.
> SolrException usage in solrj client code can't handle all possible http error
> codes returned by servers -- example "413 Request Entity Too Large"
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4487
> URL: https://issues.apache.org/jira/browse/SOLR-4487
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
> Affects Versions: 4.0
> Reporter: Alexander Dietrich
> Assignee: Hoss Man
>
> Solr responds to excessively large queries with a 413 status code, but
> HttpSolrServer.request() loses this information when it tries to look up the
> code in SolrException.ErrorCode, resulting in a status code 0 in the thrown
> exception.
> Being able to see this status code would be helpful.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
