Solr
  1. Solr
  2. SOLR-4672

requests for cores which had known startup init failures should result in 500 not 404

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.3, 5.0
    • Component/s: None
    • Labels:
      None

      Description

      SOLR-3591 added support for tracking if a core failed to init properly, and reporting this data back in STATUS request to the CoreAdminHandler so they could be displayed in the UI.

      Attempts to use those cores anyway (for queries or updates, etc...) by users/clients that may not realize the core failed to init results in 404 errors because the core doesn't exist, however it should be fairly straight forward to intead return a 500 error wrapping the cause of the init failure.

        Issue Links

          Activity

          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.
          Hide
          Hoss Man added a comment -

          Hoss Man: I vote you don't worry about it <G>...

          done and done!

          I spun off SOLR-4688 to let you worry about that (lemme know if you need help) and committed what was here...

          Committed revision 1465749.
          Committed revision 1465770.

          Show
          Hoss Man added a comment - Hoss Man: I vote you don't worry about it <G>... done and done! I spun off SOLR-4688 to let you worry about that (lemme know if you need help) and committed what was here... Committed revision 1465749. Committed revision 1465770.
          Hide
          Erick Erickson added a comment -

          Hoss Man: I vote you don't worry about it <G>...

          I've just written some tests on that very subject as part of SOLR-4663. I took a look at your tests and I think I can just add a test for the return code == 500 to the ones that I've already written verifying that the tests return the message I expect. There's some infrastructure over in TestLazyCores for creating lazy core defs that I can leverage. Take me about 5 minutes.

          Does that work for you?

          Show
          Erick Erickson added a comment - Hoss Man: I vote you don't worry about it <G>... I've just written some tests on that very subject as part of SOLR-4663 . I took a look at your tests and I think I can just add a test for the return code == 500 to the ones that I've already written verifying that the tests return the message I expect. There's some infrastructure over in TestLazyCores for creating lazy core defs that I can leverage. Take me about 5 minutes. Does that work for you?
          Hide
          Hoss Man added a comment -

          patch that adds the neccessary logic to CoreContainer to throw 500 exception from getCore(name) if the name is in the list of core's with init failures.

          I've updated CoreContainerCoreInitFailuresTest and done some manual testing with the example webapp to verify this works right.

          the one thing i'm not 100% sure of is if this is behaving the way it should when dealing with lazy loaded transient cores. From what i can tell, this should already already work because of how lazy loaded cores are created on demand, but i'm not 100% certain that i understand what's happening in all cases here. Either wya it would be good to have a test of this.

          Erick Erickson: if you could take a look and give me some guidance on how it should work, and how to write a good test for that it would be appreciated.

          Show
          Hoss Man added a comment - patch that adds the neccessary logic to CoreContainer to throw 500 exception from getCore(name) if the name is in the list of core's with init failures. I've updated CoreContainerCoreInitFailuresTest and done some manual testing with the example webapp to verify this works right. the one thing i'm not 100% sure of is if this is behaving the way it should when dealing with lazy loaded transient cores. From what i can tell, this should already already work because of how lazy loaded cores are created on demand, but i'm not 100% certain that i understand what's happening in all cases here. Either wya it would be good to have a test of this. Erick Erickson : if you could take a look and give me some guidance on how it should work, and how to write a good test for that it would be appreciated.

            People

            • Assignee:
              Hoss Man
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development