Solr
  1. Solr
  2. SOLR-4577

The collections API should return responses (sucess or failure) for each node it attempts to work with.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.2.1, 4.3, 6.0
    • Component/s: SolrCloud
    • Labels:
      None

      Description

      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.

        Issue Links

          Activity

          Hide
          Shawn Heisey added a comment -

          I like this idea. The few times I've used the collections API to create new collections, I know it worked, but the barebones response didn't say so. This may be implicit here, but I think the response needs to include a top-level success or failure as well as per node/core.

          Show
          Shawn Heisey added a comment - I like this idea. The few times I've used the collections API to create new collections, I know it worked, but the barebones response didn't say so. This may be implicit here, but I think the response needs to include a top-level success or failure as well as per node/core.
          Hide
          Mark Miller added a comment -

          Thanks for the feedback Shawn. SOLR-4576 will solve the top level case - an error there will cause an exception.

          Here is what I currently have for a response format:

            {responseHeader={status=0,QTime=3063},
            failure={127.0.0.1:49301_vipe%2Fx=org.apache.solr.common.SolrException:Error CREATEing SolrCore 'halfcollection_shard1_replica1': Core with name 'halfcollection_shard1_replica1' already exists.},
            success={127.0.0.1:41247_vipe%2Fx={responseHeader={status=0,QTime=3029},core=halfcollection_shard2_replica1,saved=/tmp/org.apache.solr.cloud.CollectionsAPIDistributedZkTest-jetty1-1363283260454/solr.xml}}}
          
          Show
          Mark Miller added a comment - Thanks for the feedback Shawn. SOLR-4576 will solve the top level case - an error there will cause an exception. Here is what I currently have for a response format: {responseHeader={status=0,QTime=3063}, failure={127.0.0.1:49301_vipe%2Fx=org.apache.solr.common.SolrException:Error CREATEing SolrCore 'halfcollection_shard1_replica1': Core with name 'halfcollection_shard1_replica1' already exists.}, success={127.0.0.1:41247_vipe%2Fx={responseHeader={status=0,QTime=3029},core=halfcollection_shard2_replica1,saved=/tmp/org.apache.solr.cloud.CollectionsAPIDistributedZkTest-jetty1-1363283260454/solr.xml}}}
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1456683

          SOLR-4574: The Collections API will silently return success on an unknown ACTION parameter.
          SOLR-4576: Collections API validation errors should cause an exception on clients and otherwise act as validation errors with the Core Admin API.
          SOLR-4577: The collections API should return responses (success or failure) for each node it attempts to work with.

          Show
          Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1456683 SOLR-4574 : The Collections API will silently return success on an unknown ACTION parameter. SOLR-4576 : Collections API validation errors should cause an exception on clients and otherwise act as validation errors with the Core Admin API. SOLR-4577 : The collections API should return responses (success or failure) for each node it attempts to work with.
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1456710

          SOLR-4574: The Collections API will silently return success on an unknown ACTION parameter.
          SOLR-4576: Collections API validation errors should cause an exception on clients and otherwise act as validation errors with the Core Admin API.
          SOLR-4577: The collections API should return responses (success or failure) for each node it attempts to work with.

          Show
          Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1456710 SOLR-4574 : The Collections API will silently return success on an unknown ACTION parameter. SOLR-4576 : Collections API validation errors should cause an exception on clients and otherwise act as validation errors with the Core Admin API. SOLR-4577 : The collections API should return responses (success or failure) for each node it attempts to work with.
          Hide
          Per Steffensen added a comment -

          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

          Show
          Per Steffensen added a comment - 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
          Hide
          Mark Miller added a comment -

          I'd love to see a holistic improvement to how errors are handled and returned by Solr. It certainly deserves it's own issue. Until then, it makes sense to have this work like the rest of Solr does.

          Show
          Mark Miller added a comment - I'd love to see a holistic improvement to how errors are handled and returned by Solr. It certainly deserves it's own issue. Until then, it makes sense to have this work like the rest of Solr does.
          Hide
          Per Steffensen added a comment -

          I provided my attempt at a holistic solution in SOLR-3178, with a separate issue SOLR-3382 on the part of response-includes-response-for-each-subrequest. Unfortunately it is merged in with all the other improvements in SOLR-3178. I would like to try to dig out the parts related to exception-propagation and inclusion of sub-request results/exceptions. If you want?

          Show
          Per Steffensen added a comment - I provided my attempt at a holistic solution in SOLR-3178 , with a separate issue SOLR-3382 on the part of response-includes-response-for-each-subrequest. Unfortunately it is merged in with all the other improvements in SOLR-3178 . I would like to try to dig out the parts related to exception-propagation and inclusion of sub-request results/exceptions. If you want?
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1458104

          SOLR-4574: Move CHANGES entry.
          SOLR-4576: Move CHANGES entry.
          SOLR-4577: Move CHANGES entry.

          Show
          Commit Tag Bot added a comment - [branch_4x commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1458104 SOLR-4574 : Move CHANGES entry. SOLR-4576 : Move CHANGES entry. SOLR-4577 : Move CHANGES entry.
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] Mark Robert Miller
          http://svn.apache.org/viewvc?view=revision&revision=1458105

          SOLR-4574: Move CHANGES entry.
          SOLR-4576: Move CHANGES entry.
          SOLR-4577: Move CHANGES entry.

          Show
          Commit Tag Bot added a comment - [trunk commit] Mark Robert Miller http://svn.apache.org/viewvc?view=revision&revision=1458105 SOLR-4574 : Move CHANGES entry. SOLR-4576 : Move CHANGES entry. SOLR-4577 : Move CHANGES entry.
          Hide
          Mark Miller added a comment -

          I would like to try to dig out the parts related to exception-propagation and inclusion of sub-request results/exceptions. If you want?

          I would be interested in this.

          Show
          Mark Miller added a comment - I would like to try to dig out the parts related to exception-propagation and inclusion of sub-request results/exceptions. If you want? I would be interested in this.
          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.

            People

            • Assignee:
              Mark Miller
              Reporter:
              Mark Miller
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development