stack trace response

[Koji Sekiguchi <ko...@r.email.ne.jp>]

Hello,

We have a front application server that uses Solr to search our contents.

If the front application calls Solr with /select but missing q parameter,
Solr returns a stack trace with its response body, while we expect
XML response with an error message (& the stack trace in the XML).
Is it a feature?

If so, is the front server responsible about checking required params
before requesting to Solr, correct?

I've found a similar issue in JIRA:

an empty query string in the admin interface throws an exception
http://issues.apache.org/jira/browse/SOLR-48

but the solution was that the front checked q parameter before sending.

We are hoping Solr returns a readable response produced by Response Writer
even if the front server sends wrong request to Solr,
but if it is a feature, we will validate params at the front.
We'd like to just confirm that.

Thank you,

Koji

Re: stack trace response

[Ryan McKinley <ry...@gmail.com>]

I agree, the display is a bit weird.  But, if you check the response
headers it the response code is 400 "Bad Request"

In firefox or IE, you would need to inspect the headers to see what is going on.

The issue is that /select uses a servlet that writes out a stack trace
for every error it hits directly.  Is uses:

  try{response.setStatus(rc);} catch (Exception e) {}
  PrintWriter writer = response.getWriter();
  writer.write(msg);

Down the line, when we have
http://issues.apache.org/jira/browse/SOLR-141, this will be the best
option.

I'm lobbying to let the SolrDispatchFilter handle /select.  The
SolrDispatchFilter passes the error code and message on to the servlet
container so it is formatted in the most standard way.  It also only
includes a stack trace for 500 errors, not 400,403,etc.  It uses:

  res.sendError( code, ex.getMessage() );


ryan

Re: stack trace response

[Chris Hostetter <ho...@fucit.org>]

: If the front application calls Solr with /select but missing q parameter,
: Solr returns a stack trace with its response body, while we expect
: XML response with an error message (& the stack trace in the XML).
: Is it a feature?
:
: If so, is the front server responsible about checking required params
: before requesting to Solr, correct?

generally speaking, clients should allways try to ensure that they only
send welformed requests -- the built in RequestHandlers can't function
without a "q" param, so i would say yes they should check that they have a
value for that param before sending the request to Solr.  if you want
their to be a default value for the "q" param, you can configure it in the
solrconfig.xml.

at a broader level, you are correct - the error reporting is not very
clean.  we are hoping to eventually fix that so the error reporting is
more consistent...

   http://issues.apache.org/jira/browse/SOLR-141

...in the mean time, i believe query errors are reported using the HTTP
status code (if not 200, then an error) and update errors are reported in
the XML response body.




-Hoss