Solr
  1. Solr
  2. SOLR-7151

SolrClient.query() methods should throw IOException

    Details

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

      Description

      All the methods on SolrClient are declared as throwing SolrServerException (thrown if there's an error somewhere on the server), and IOException (thrown if there's a communication error), except for the QueryRequest methods. These swallow up IOException and repackage them in a SolrServerException.

      I think these are useful distinctions to make (you might want to retry on an IOException, but not on a SolrServerException), and we should make the query methods fall in line with the others.

      I'm not sure if this should go into 5.x as well as trunk, as it's a backwards-breaking change. I'm leaning towards yes, as it's a sufficiently useful API change that it's worth the break, but I'm not going to insist on it.

      1. SOLR-7151.patch
        32 kB
        Alan Woodward

        Activity

        Hide
        Alan Woodward added a comment -

        Patch, building on top of the patch on SOLR-7145.

        Show
        Alan Woodward added a comment - Patch, building on top of the patch on SOLR-7145 .
        Hide
        Shawn Heisey added a comment - - edited

        I'm not sure if this should go into 5.x as well as trunk, as it's a backwards-breaking change. I'm leaning towards yes, as it's a sufficiently useful API change that it's worth the break, but I'm not going to insist on it.

        +1 to 5x. I have no idea whether I'm in the minority here. I fully expect that anytime I update a library (like SolrJ) that my program uses, I may need to fix my code, and at the very least I will need to recompile my programs. If the change is documented in whatever the package has for a CHANGES file, that's even better.

        So far I've been extraordinarily lucky in that I've only needed to make changes to take advantage of new features, the code has always compiled successfully on SolrJ updates. It's a bonus that I did not expect; I'm OK with minor changes in the API. Large scale refactorings in a minor version update might bother me, but only if they do not come with a major advancement in the library's usability or capability.

        To put it another way: If CHANGES.txt informs me that I may not be able to do a drop-in jar replacement with that minor update, that's enough notice for me ... although I would have assumed that anyway.

        Show
        Shawn Heisey added a comment - - edited I'm not sure if this should go into 5.x as well as trunk, as it's a backwards-breaking change. I'm leaning towards yes, as it's a sufficiently useful API change that it's worth the break, but I'm not going to insist on it. +1 to 5x. I have no idea whether I'm in the minority here. I fully expect that anytime I update a library (like SolrJ) that my program uses, I may need to fix my code, and at the very least I will need to recompile my programs. If the change is documented in whatever the package has for a CHANGES file, that's even better. So far I've been extraordinarily lucky in that I've only needed to make changes to take advantage of new features, the code has always compiled successfully on SolrJ updates. It's a bonus that I did not expect; I'm OK with minor changes in the API. Large scale refactorings in a minor version update might bother me, but only if they do not come with a major advancement in the library's usability or capability. To put it another way: If CHANGES.txt informs me that I may not be able to do a drop-in jar replacement with that minor update, that's enough notice for me ... although I would have assumed that anyway.
        Hide
        Mark Miller added a comment -

        I think the tradeoffs have to be weighed pretty carefully. We want to get to the point that you can do rolling upgrades and such, and back compat breaks, while sometimes necessary, especially in the early days of APIs, need to become more and more rare for point releases I think.

        I'd like to start a new trend of annotating what API's can be counted on and what not before long. We are great about http, but anything java is a mine field. And soon we would like to support rolling upgrades to some degree.

        In this case, I'm not sure the win is worth the break myself. But it also of the type we have let slide before.

        Show
        Mark Miller added a comment - I think the tradeoffs have to be weighed pretty carefully. We want to get to the point that you can do rolling upgrades and such, and back compat breaks, while sometimes necessary, especially in the early days of APIs, need to become more and more rare for point releases I think. I'd like to start a new trend of annotating what API's can be counted on and what not before long. We are great about http, but anything java is a mine field. And soon we would like to support rolling upgrades to some degree. In this case, I'm not sure the win is worth the break myself. But it also of the type we have let slide before.
        Hide
        Alan Woodward added a comment -

        We are great about http, but anything java is a mine field. And soon we would like to support rolling upgrades to some degree.

        Agreed! I don't think this will effect rolling upgrades, though? This just changes how the client handles exceptions - you can still talk to a 5.1 server using a 4.10 client, and vice versa.

        Show
        Alan Woodward added a comment - We are great about http, but anything java is a mine field. And soon we would like to support rolling upgrades to some degree. Agreed! I don't think this will effect rolling upgrades, though? This just changes how the client handles exceptions - you can still talk to a 5.1 server using a 4.10 client, and vice versa.
        Hide
        Alan Woodward added a comment -

        Mark Miller do you have any objections to me committing this to 5.x?

        Show
        Alan Woodward added a comment - Mark Miller do you have any objections to me committing this to 5.x?
        Hide
        ASF subversion and git services added a comment -

        Commit 1662670 from Alan Woodward in branch 'dev/trunk'
        [ https://svn.apache.org/r1662670 ]

        SOLR-7151: SolrClient query methods throw IOException

        Show
        ASF subversion and git services added a comment - Commit 1662670 from Alan Woodward in branch 'dev/trunk' [ https://svn.apache.org/r1662670 ] SOLR-7151 : SolrClient query methods throw IOException
        Hide
        ASF subversion and git services added a comment -

        Commit 1662671 from Alan Woodward in branch 'dev/trunk'
        [ https://svn.apache.org/r1662671 ]

        SOLR-7151: CHANGES.txt attribution

        Show
        ASF subversion and git services added a comment - Commit 1662671 from Alan Woodward in branch 'dev/trunk' [ https://svn.apache.org/r1662671 ] SOLR-7151 : CHANGES.txt attribution
        Hide
        ASF subversion and git services added a comment -

        Commit 1662672 from Alan Woodward in branch 'dev/branches/branch_5x'
        [ https://svn.apache.org/r1662672 ]

        SOLR-7151: CHANGES.txt attribution

        Show
        ASF subversion and git services added a comment - Commit 1662672 from Alan Woodward in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1662672 ] SOLR-7151 : CHANGES.txt attribution
        Hide
        Timothy Potter added a comment -

        Bulk close after 5.1 release

        Show
        Timothy Potter added a comment - Bulk close after 5.1 release

          People

          • Assignee:
            Alan Woodward
            Reporter:
            Alan Woodward
          • Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development