You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Per Steffensen (Created) (JIRA)" <ji...@apache.org> on 2012/04/20 10:16:41 UTC
[jira] [Created] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
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
Fix For: 4.0
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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Per Steffensen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267475#comment-13267475 ]
Per Steffensen commented on SOLR-3382:
--------------------------------------
New patch available as part of SOLR-3173_3178_3382_3428_plus.patch on SOLR-3178
> 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.0
>
>
> 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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Per Steffensen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13260742#comment-13260742 ]
Per Steffensen commented on SOLR-3382:
--------------------------------------
See patch attached to SOLR-3178
> 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.0
>
>
> 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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Per Steffensen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258086#comment-13258086 ]
Per Steffensen commented on SOLR-3382:
--------------------------------------
In our contribution the "finegrained error propagation" is solely used for reporting "unique key constraint"- and "versioning"-errors, but the design is very generic, so in the future it can also be used for other situations where you want to report "partial errors" back to the client - e.g. in a replication setup, information about a update succeeding on leader but not on one or more of the replica.
> 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.0
>
>
> 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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Per Steffensen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258174#comment-13258174 ]
Per Steffensen commented on SOLR-3382:
--------------------------------------
Stefan: Done! Changed my code and Wiki page. Please review and comment if you are not satisfied.
> 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.0
>
>
> 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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Per Steffensen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258080#comment-13258080 ]
Per Steffensen commented on SOLR-3382:
--------------------------------------
We have created a solution to this while adding the update-features of "fail if intent is to insert new document and document already exists", "fail if intent is to update existing document and document does not exist or has been changed since loaded" etc. as described in SOLR-3173, SOLR-3178 and on http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics. Details about the solution to this SOLR-3382 is also to be found on http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics. Reason for solving this SOLR-3382 at the same time as SOLR-3173 and SOLR-3178 is that "unique key constraint"- and "versioning"-errors are not worth much if they cannot get properly propagated to the client.
We hope to contribe this solutions within a few weeks, but please feel free to comment, help shape etc., and we will make changes according to the wishes of the community.
> 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.0
>
>
> 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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Per Steffensen (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258134#comment-13258134 ]
Per Steffensen commented on SOLR-3382:
--------------------------------------
Stefan Metheis, the string-operations are already there for you if you are using SolrJ, but I guess you are not, since you (as I understand it) are dealing with Solr admin console (probably calling services like update/query directly from the browser using some kind of Ajax, instead of doing that on server, which would be natural if the admin console where e.g. JSP-based). But never mind, your idea about encoding error-type (namespace and name) in response headers instead of in the reason-phrase is better. I will make the necessary changes in our code, so that it will be part of the contribution, and change the Wiki page. Thanks a lot!
> 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.0
>
>
> 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: 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
[jira] [Commented] (SOLR-3382) Finegrained error propagation (focus
on multi-document updates)
Posted by "Stefan Matheis (steffkes) (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SOLR-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13258092#comment-13258092 ]
Stefan Matheis (steffkes) commented on SOLR-3382:
-------------------------------------------------
Per, just one quick thought, regarding http://wiki.apache.org/solr/Per%20Steffensen/Update%20semantics#Status_line :
Can we stick with default reason-phrases and put ours in {{X-Error-*}} -Headers? Otherwise we have to put String-Operations in Place, if we want to output these informations in some type of frontend
> 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.0
>
>
> 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: 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