Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
3.5
Description
Today when an error occurs on server side during the handling of a request, the handling of the request will stop at the point when the error occured, and only a error-message (reason part of HTTP status line) and error-code (HTTP response code) is pushed back to the sender of the request.
This can be improved in several ways
- Reacting as a client on errors, solely based on a textual message and a HTTP response code is hard. The error ought have some kind of type telling the client which kind of error happened.
- When handling multi-document updates the error might happen during the handling of one of the documents - potentially not the first document and potentially not the last document.
- The client ought to get information about which documents where successfully updated (the ones comming before the document creating the error).
- If the error updating a document is not due to a general problem, it could very well be that some of the documents not yet handled at the time of the error (the documents comming after the document creating the error), could be successfully updated - so why not try that.
- If continuing the updating of documents, even after one document-update resulted in an error (as suggested above), the updating of some of those documents might also result in an error. This leads to another improvement, namely being able to send information about more than one error back to the client.
Attachments
Issue Links
- incorporates
-
SOLR-445 Update Handlers abort with bad documents
- Closed
- is related to
-
SOLR-3018 enhance solr to support per-document results in batch mode
- Open
-
SOLR-3383 Async responses in SolrJ
- Open
- relates to
-
SOLR-3384 Custom SolrServer chains - mixing SolrServer-subclass properties as you like to
- Open