You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (Commented) (JIRA)" <ji...@apache.org> on 2011/11/16 03:52:52 UTC
[jira] [Commented] (SOLR-2813) TrieTokenizerFactory should catch
NumberFormatException, return 400 (not 500)
[ https://issues.apache.org/jira/browse/SOLR-2813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13150982#comment-13150982 ]
Hoss Man commented on SOLR-2813:
--------------------------------
Ok .. backporting has lead me into some confusion.
The new tests were failing, which lead me to an investigation where i discovered that TrieTokenizerFactory isn't used as much as I thought -- some of the things I was testing for were actually dependent on SOLR-2402, so I backported that to 3x.
Once that was done, backporting this patch caused queries and updates with malformed numbers to both return 400 errors instead of 500 errors in ad-hoc testing, but it still didn't fix the failures in BasicFunctionalityTest. Digging in a little more the problem seems to be that on trunk, the TestHarness.update method uses DirectSolrConnection which propgates any errors into the test framework, while on the 3x branch it's still using XmlUpdateRequestHandler.doLegacyUpdate so the exception is hidden from the test.
I need to look at this again tomorrow when i have some more time -- the functionality of this patch is good to go on 3x, it's just the damn test case that is anoying.
(Looks like the TestHarness changes are from r1054124 as part of SOLR-1930 ... maybe just backport the test changes from that commit w/o removing the deprecated method?)
> TrieTokenizerFactory should catch NumberFormatException, return 400 (not 500)
> -----------------------------------------------------------------------------
>
> Key: SOLR-2813
> URL: https://issues.apache.org/jira/browse/SOLR-2813
> Project: Solr
> Issue Type: Bug
> Components: Schema and Analysis
> Affects Versions: 3.4, 4.0
> Environment: 4.0 trunk, snapshot taken 09/08/2011.
> Reporter: Jeff Crump
> Assignee: Hoss Man
> Priority: Minor
> Fix For: 3.5, 4.0
>
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> TrieTokenizerFactory is allowing bad user input to result in a 500 error rather than a 400. For a long-valued field, for example, this code in TrieTokenizerFactory.reset() will throw a NumberFormatException:
> > case LONG:
> > ts.setLongValue(Long.parseLong(v));
> > break;
> The NFE gets all the way out to RequestHandlerBase.handleRequest():
> > catch (Exception e) {
> > SolrException.log(SolrCore.log,e);
> > if (e instanceof ParseException) {
> > e = new SolrException(SolrException.ErrorCode.BAD_REQUEST, e);
> > }
> but is not caught here, and ends up coming out of SolrDispatchFilter.sendError as a 500.
> Simply catching NFE and turning it into a SolrException does the trick:
> ==== solr/core/src/java/org/apache/solr/analysis/TrieTokenizerFactory.java#1 - /4.0-trunk-09082011/solr/core/src/java/org/apache/solr/analysis/TrieTokenizerFactory.java ====
> 110a111,112
> > } catch (NumberFormatException e) {
> > throw new SolrException(SolrException.ErrorCode.BAD_REQUEST, "Unable to parse input", e);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org