lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2813) TrieTokenizerFactory should catch NumberFormatException, return 400 (not 500)
Date Wed, 16 Nov 2011 02:52:52 GMT

    [ 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


Mime
View raw message