Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Wed, 10 Apr 2013 08:34:16 +0000 (UTC)
From: "Per Steffensen (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: <JIRA.12551741.1334909723892.141411.1365582856448@arcas>
In-Reply-To: <JIRA.12551741.1334909723892@arcas>
References: <JIRA.12551741.1334909723892@arcas>
Subject: [jira] [Comment Edited] (SOLR-3382) Finegrained error propagation
 (focus on multi-document updates)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627601#comment-13627601 ] 

Per Steffensen edited comment on SOLR-3382 at 4/10/13 8:34 AM:
---------------------------------------------------------------

We use this Apache issue/ticket to keep track of what we did on our own internal version of Solr, and what would be provided in a patch for this issue if the Apache community was interested. Therefore this additional comment, for now just a "note to self":

The solution for "error propagation" now not only supports sending error-code, error-msg and error-type (corresponding to package+classname in java) so that exceptions can be reconstructed and thrown on client-side (automatic in SolrJ). Now it also supports additional properties (name/value pairs) on an exception and have those propagated over the line to the client where it can be (will be in SolrJ) attached as properties on the reconstructed exception. Explicit properties on exception are nice, because only alternative is to "encode" it in the error-msg, and then you have to parse the error-msg on the receiving side and that is part of what we want to avoid (it is too hacky and error prone).
Properties also supported on "nested" exceptions about parts of the request-handling that failed - e.g. in a 5-doc update-request, where 3 updates succeed and 2 fail, 2 "nested/part"-exceptions will be returned to the client. Both of those "nested/part"-exceptions can independently contain their own set of properties.

As a proof-of-concept and to show that the implementation works and to have the feature "protected" by tests, the VersionConflict exception introduced in the solution for SOLR-3178 has been enhanced to carry a property "currentVersion" containing the current version of the document on server-side. So now, if the client want to know about the actual current version on server-side, it does not have to parse the error-msg to get hold of it - just read the provided property. All existing tests using VersionConflict has been updated to test that the returned currentVersion is correct. There are test that have VersionConflict as the top-level exception (version-conflict in a single-doc update-request) and other tests that have several VersionConflicts as "nested/part"-exceptions so both aspects are tested. 

The ability of VersionConflict to carry current-version might not be very usefull. But it shows that the feature implementation works and it makes it easy to protect the feature by tests. Internally we will be using the feature for somthing far more usefull.
                
      was (Author: steff1193):
    We use this Apache issue/ticket to keep track of what we did on our own internal version of Solr, and what would be provided in a patch for this issue if the Apache community was interested. Therefore this additional comment, for now just a "note to self":

The solution for "error propagation" now not only supports sending error-code, error-msg and error-type (corresponding to package+classname in java) so that exceptions can be reconstructed and thrown on client-side (automatic in SolrJ). Now it also supports additional properties (name/value pairs) on an exception and have those propagated over the line to the client where it can be (will be in SolrJ) attached as properties on the reconstructed exception. Explicit properties on exception are nice, because only alternative is to "encode" it in the error-msg, and then you have to parse the error-msg on the receiving side and that is part of what we want to avoid (it is too hacky and error prone).
Properties also supported on "nested" exceptions about parts of the request-handling that failed - e.g. in a 5-doc update-request, where 3 updates succeed and 2 fail, 2 "nested/part"-exceptions will be returned to the client. Both of those "nested/part"-exceptions can independently contain their own set of properties.

As a proof-of-concept and to show that the implementation works and to have the feature "protected" by tests, the VersionConflict exception introduced in the solution for SOLR-3178 has been enhanced to carry a property "currentVersion" containing the current version of the document on server-side. So now, if the client want to know about the actual current version on server-side, it does not have to parse the error-msg to get hold of it - just read the provided property. All existing tests using VersionConflict has been updated to test that the returned currentVersion is correct. There are test that have VersionConflict as the top-level exception (version-conflict in a single-doc update-request) and other tests that have several VersionConflicts as "nested/part"-exceptions so both aspects are tested. 
                  
> Finegrained error propagation (focus on multi-document updates)
> ---------------------------------------------------------------
>
>                 Key: SOLR-3382
>                 URL: https://issues.apache.org/jira/browse/SOLR-3382
>             Project: Solr
>          Issue Type: New Feature
>          Components: clients - java, Response Writers, update
>    Affects Versions: 3.5
>            Reporter: Per Steffensen
>            Assignee: Per Steffensen
>              Labels: client, documents, error, multiple, propagation, update
>             Fix For: 4.3
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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