[
https://issues.apache.org/jira/browse/SOLR-4577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604369#comment-13604369
]
Per Steffensen commented on SOLR-4577:
--------------------------------------
Of course, I would have preferred if you had used the solutions to "Typed
exception propagation" and "Finegrained error propagation" (SOLR-3382) to be
found in the patch for SOLR-3178. Then there would be support for propagating
typed exceptions across the wire and for such an exception to contain a list of
success/exception per sub-operation (Core API operations in this case).
Then the response could be an actual typed exception with typed sub-exceptions
for sub-operations that went wrong - e.g.
CollectionCreateException
- shard1_replica1: CoreAlreadyExistsException
- shard1_replica2: "success"
- shard2_replica1: NoSpaceLeftOnDeviceException
- shard2_replica2: NoRouteToNodeException
Instead of exceptions always being SolrException and everything else is to be
found out by inspecting text or parsed JSON/XML containing text-stuff only. No
actual typed exceptions propagated and thrown at client-side.
In SOLR-3178 this those features returning typed exception with typed
sub-exceptions (one for each sub-operation carried out unsuccessfully) is used
around optimistic locking errors on multidocument update requests (where the
update of some documents can go well, while update of other documents fail e.g.
due to version problems), but the exception propagation and sub-exception
system was intentionally designed general purpose, because it is obvious that
there will be a lot of cases, in a distributed system like this, where an
operation will result i several sub-operations, where each of those can
fail/succeed independently, and where you would like to be able to provide the
original client with a finegrained "result/report" back - an object/exception
hierarchy to inspect and not a bunch of text to parse.
Of course, at serialized/transport level, the solution does not do anything
SolrJ/Java-specific, because the client might not be SolrJ/Java, but if it is,
exceptions with sub-exception are automatically created and thrown.
Just a FRIENDLY note/reminder that this category of "issues" already have a
generic and powerful solution waiting to be used - in the great :-) SOLR-3178
patch
> The collections API should return responses (sucess or failure) for each node
> it attempts to work with.
> -------------------------------------------------------------------------------------------------------
>
> Key: SOLR-4577
> URL: https://issues.apache.org/jira/browse/SOLR-4577
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Priority: Minor
> Fix For: 4.3, 5.0
>
>
> This is when the command itself is successful on the node, but then we need a
> report of the sub command result on each node.
> There is some code that sort of attempts to do this that came in with the
> collection api response contribution, but it's not really working currently.
--
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: [email protected]
For additional commands, e-mail: [email protected]
