Hi,

I ran into an issue where certain combinations of queries and sort orders cause 
an Exception in the Highlighter component that in turn causes a 500 Server 
Error.
I tracked down the cause to a problem in the tokenizer chain I use, but I do 
not have a quick solution yet.

The point I want to raise here is that the "global" 500 error for the whole of 
the response seems way too restrictive.
In addition the response body still contains the correct values for the query 
and facets itself but getting to it is awkward (I use SolrNet: I have to catch 
the WebException, get the response from there and hope the main parts of it are 
intact...), but at least it keeps the bulk of the application running.

My suggestion would be that exceptions thrown in components only affect the 
corresponding part of the response, but do not cause a 500 Server Error.
At the end of the response the "<lst name="error">" element could be made 
repetitive (with a component="..." attribute?)

This way end users of the application might notice parts are not functioning 
properly in some circumstances, but the main application would still be usable.
The thrown exception should still be logged of course to enable the cause to be 
found (and a monitoring service to notify the admins and/or developers)

I made an exception for the query component since probably most components rely 
on it functioning correctly.

Luc Vanlerberghe

Reply via email to