Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-8146

Allowing SolrJ CloudSolrClient to have preferred replica for query/read

    Details

    • Type: New Feature
    • Status: Reopened
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 5.3
    • Fix Version/s: None
    • Component/s: clients - java
    • Labels:
      None

      Description

      Backgrouds

      Currently, the CloudSolrClient randomly picks a replica to query.
      This is done by shuffling the list of live URLs to query then, picking the first item from the list.

      This ticket is to allow more flexibility and control to some extend which URLs will be picked up for queries.

      Note that this is for queries only and would not affect update/delete/admin operations.

      Implementation

      The current patch uses regex pattern and moves to the top of the list of URLs only those matching the given regex specified by the system property

      solr.preferredQueryNodePattern

      Initially, I thought it may be good to have Solr nodes tagged with a string pattern (snitch?) and use that pattern for matching the URLs.

      Any comment, recommendation or feedback would be appreciated.

      Use Cases

      There are many cases where the ability to choose the node where queries go can be very handy:

      Special node for manual user queries and analytics

      One may have a SolrCLoud cluster where every node host the same set of collections with:

      • multiple large SolrCLoud nodes (L) used for production apps and
      • have 1 small node (S) in the same cluster with less ram/cpu used only for manual user queries, data export and other production issue investigation.

      This ticket would allow to configure the applications using SolrJ to query only the (L) nodes

      This use case is similar to the one described in SOLR-5501 raised by Manuel Lenormand

      Minimizing network traffic

      For simplicity, let's say that we have a SolrSloud cluster deployed on 2 (or N) separate racks: rack1 and rack2.

      On each rack, we have a set of SolrCloud VMs as well as a couple of client VMs querying solr using SolrJ.

      All solr nodes are identical and have the same number of collections.

      What we would like to achieve is:

      • clients on rack1 will by preference query only SolrCloud nodes on rack1, and
      • clients on rack2 will by preference query only SolrCloud nodes on rack2.
      • Cross-rack read will happen if and only if one of the racks has no available Solr node to serve a request.

      In other words, we want read operations to be local to a rack whenever possible.

      Note that write/update/delete/admin operations should not be affected.

      Note that in our use case, we have a cross DC deployment. So, replace rack1/rack2 by DC1/DC2

      Any comment would be very appreciated.

      Thanks.

      1. SOLR-8146.patch
        7 kB
        Noble Paul
      2. SOLR-8146.patch
        17 kB
        Arcadius Ahouansou
      3. SOLR-8146.patch
        7 kB
        Arcadius Ahouansou
      4. SOLR-8146.patch
        7 kB
        Arcadius Ahouansou

        Issue Links

          Activity

          Hide
          arcadius Arcadius Ahouansou added a comment -

          Using LinkedList instead

          Show
          arcadius Arcadius Ahouansou added a comment - Using LinkedList instead
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Updated with more tests.
          Any comment or feedback would be most appreciated

          Show
          arcadius Arcadius Ahouansou added a comment - Updated with more tests. Any comment or feedback would be most appreciated
          Hide
          elyograg Shawn Heisey added a comment -

          Rack awareness is covered by SOLR-6205.

          Show
          elyograg Shawn Heisey added a comment - Rack awareness is covered by SOLR-6205 .
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Hello Shawn Heisey
          Thank you very much for having a look at this issue.

          This issue and SOLR-6205 (that I have raised a while back) are different things.
          SOLR-6205 about the solrCloud server availability/redundancy across 2 DCs while this one is solely about SolrJ preferences.

          For instance let's say

          • a SolrJ client is deployed in DC1 and
          • we have replica of a given shard in both DC1 and DC2.
          • This patch allows to configure SolrJ to by preference query the replica in DC1 first, minimizing unnecessary trip to the other DC2 to get data that is available in its own DC1.

          Thanks.

          Show
          arcadius Arcadius Ahouansou added a comment - Hello Shawn Heisey Thank you very much for having a look at this issue. This issue and SOLR-6205 (that I have raised a while back) are different things. SOLR-6205 about the solrCloud server availability/redundancy across 2 DCs while this one is solely about SolrJ preferences. For instance let's say a SolrJ client is deployed in DC1 and we have replica of a given shard in both DC1 and DC2. This patch allows to configure SolrJ to by preference query the replica in DC1 first, minimizing unnecessary trip to the other DC2 to get data that is available in its own DC1. Thanks.
          Hide
          arcadius Arcadius Ahouansou added a comment -

          they are not the same issue

          Show
          arcadius Arcadius Ahouansou added a comment - they are not the same issue
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Hello Shawn Heisey
          I thought the initial issue description may have been misleading and unclear.
          So, I have re-edited it.

          Please let me know in case there is any question.

          Thanks.

          Show
          arcadius Arcadius Ahouansou added a comment - Hello Shawn Heisey I thought the initial issue description may have been misleading and unclear. So, I have re-edited it. Please let me know in case there is any question. Thanks.
          Hide
          noble.paul Noble Paul added a comment -

          I see that a regex is used for expressing the affinity.

          I would rather have something like the replica placement rule and piggy back on same syntax

          examples

          preferredNodes=host:<hostName>
          

          you can implement new snitches such as DCAwareSnitch or RackAwareSnitch and add to the patch and use rules like

          preferredNodes=dc:DC2
          prefrredNodes=rack:RACK3
          
          Show
          noble.paul Noble Paul added a comment - I see that a regex is used for expressing the affinity. I would rather have something like the replica placement rule and piggy back on same syntax examples preferredNodes=host:<hostName> you can implement new snitches such as DCAwareSnitch or RackAwareSnitch and add to the patch and use rules like preferredNodes=dc:DC2 prefrredNodes=rack:RACK3
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Thank you very much Noble Paul.
          I will have a look into snitch

          Show
          arcadius Arcadius Ahouansou added a comment - Thank you very much Noble Paul . I will have a look into snitch
          Hide
          noble.paul Noble Paul added a comment -

          Actually you can write a snitch which uses a regex predicate as in

          preferredNodes=hostPattern:<theregex>
          

          As the Snitch does not need any extra params , just add it to the list of well known snitches

          Show
          noble.paul Noble Paul added a comment - Actually you can write a snitch which uses a regex predicate as in preferredNodes=hostPattern:<theregex> As the Snitch does not need any extra params , just add it to the list of well known snitches
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Hello Noble Paul
          Thank you very much for your suggestions.

          Regarding: preferredNodes=hostPattern:<theregex>,

          If I understand well ( and correct me if I am wrong), in order to use the preferredNodes snitch, one will have to add that snitch to the collection. Is this correct?

          The way the current implementation works is that there is not change at all on the SolrCloud server or collection.

          All the configuration is on the client SolrJ: This is on purpose because it's the client SolrJ that needs to choose its preferred servers.
          Ideally, with the use of snitch, we would like to let the client make this choice without having to add anything to the server or collection.

          How can this be achieved? Any hint will be appreciated.

          Thank you very my Noble Paul

          Show
          arcadius Arcadius Ahouansou added a comment - Hello Noble Paul Thank you very much for your suggestions. Regarding: preferredNodes=hostPattern:<theregex> , If I understand well ( and correct me if I am wrong), in order to use the preferredNodes snitch, one will have to add that snitch to the collection. Is this correct? The way the current implementation works is that there is not change at all on the SolrCloud server or collection. All the configuration is on the client SolrJ: This is on purpose because it's the client SolrJ that needs to choose its preferred servers. Ideally, with the use of snitch, we would like to let the client make this choice without having to add anything to the server or collection. How can this be achieved? Any hint will be appreciated. Thank you very my Noble Paul
          Hide
          noble.paul Noble Paul added a comment -

          in order to use the preferredNodes snitch, one will have to add that snitch to the collection. Is this correct?

          well, no. The implicit snitches are available to all collections. A snitch just has to say that I can provide values for a particular tag .

          Using regex is not really possible in the current design . It is only possible to provide discrete values. or ranges.

          Lets assume an ip address 192.93.255.255 . It is possible for a Snitch to provide values such as
          ip_1 = 192
          ip_2 = 93
          ip_3 = 255
          ip_4 = 255

          In this case you can provide a rule which says preferredNodes=ip_1:192,ip_2:93
          This means it will choose only nodes 192.93.*.*
          This can be a part of the ImplicitSnitch itself. The implicitSnitch can provide values for tags ip_1, ip_2. ip_3, ip_4 and for ip v6 it can provide values for ip_5 and ip_6 as well

          Show
          noble.paul Noble Paul added a comment - in order to use the preferredNodes snitch, one will have to add that snitch to the collection. Is this correct? well, no. The implicit snitches are available to all collections. A snitch just has to say that I can provide values for a particular tag . Using regex is not really possible in the current design . It is only possible to provide discrete values. or ranges. Lets assume an ip address 192.93.255.255 . It is possible for a Snitch to provide values such as ip_1 = 192 ip_2 = 93 ip_3 = 255 ip_4 = 255 In this case you can provide a rule which says preferredNodes=ip_1:192,ip_2:93 This means it will choose only nodes 192.93.*.* This can be a part of the ImplicitSnitch itself. The implicitSnitch can provide values for tags ip_1 , ip_2 . ip_3 , ip_4 and for ip v6 it can provide values for ip_5 and ip_6 as well
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Thank you very much Noble Paul for the clarification.

          Looking at SOLR-6289, maybe there is an overlap between ip_2 vs dc and ip_3 vs rack?

          Show
          arcadius Arcadius Ahouansou added a comment - Thank you very much Noble Paul for the clarification. Looking at SOLR-6289 , maybe there is an overlap between ip_2 vs dc and ip_3 vs rack ?
          Hide
          noble.paul Noble Paul added a comment -

          It's OK , the tag names should make sense , that is all using DC or rack does not necessarily make sense in all cases

          Show
          noble.paul Noble Paul added a comment - It's OK , the tag names should make sense , that is all using DC or rack does not necessarily make sense in all cases
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Hello Noble Paul
          I have been working on the support for IP tags such as ip_1, ip_2, ip_3 and ip_4 in ImplicitSnitch.

          Support for IPv6 is not yet implemented but I do have some failing tests for that

          Is it OK for me to create a different ticket/card for support for the IP tags?

          Thanks.

          Show
          arcadius Arcadius Ahouansou added a comment - Hello Noble Paul I have been working on the support for IP tags such as ip_1 , ip_2 , ip_3 and ip_4 in ImplicitSnitch . Support for IPv6 is not yet implemented but I do have some failing tests for that Is it OK for me to create a different ticket/card for support for the IP tags? Thanks.
          Hide
          noble.paul Noble Paul added a comment -

          Yeah, open a ticket for enhancing the snitch

          Show
          noble.paul Noble Paul added a comment - Yeah, open a ticket for enhancing the snitch
          Hide
          arcadius Arcadius Ahouansou added a comment -

          The new ticket is SOLR-8522

          Show
          arcadius Arcadius Ahouansou added a comment - The new ticket is SOLR-8522
          Hide
          susheel2777@gmail.com Susheel Kumar added a comment -

          Hello Noble, Arcadius,

          Can you please describe how exactly ImplicitSnitch can be used for preferredNodes and if there is anything to be done on SolrJ client to use preferredNodes for querying replicas?

          I have created a JIRA https://issues.apache.org/jira/browse/SOLR-9283 to document the exact steps/details for anyone to refer.

          Thanks,
          Susheel

          Show
          susheel2777@gmail.com Susheel Kumar added a comment - Hello Noble, Arcadius, Can you please describe how exactly ImplicitSnitch can be used for preferredNodes and if there is anything to be done on SolrJ client to use preferredNodes for querying replicas? I have created a JIRA https://issues.apache.org/jira/browse/SOLR-9283 to document the exact steps/details for anyone to refer. Thanks, Susheel
          Hide
          arcadius Arcadius Ahouansou added a comment -

          Hello Susheel.

          This ticket is not fully implemented yet.

          The attached patch is the very first version which does work, but relies on passing regex as start up param to the SolrJClient in the format

          -Dsolr.preferredQueryNodePattern=SOME_REGEX_MATCHING_A_SET_OF_SOLR_NODES
          
          

          This approached worked well for us but:

          • It does not look very elegant and
          • it does not integrate well into the current code base.

          so, a better way to do this is to use the snitch.

          Unfortunately, due to changes in priority, I was not able to come back to finish this work.

          Show
          arcadius Arcadius Ahouansou added a comment - Hello Susheel. This ticket is not fully implemented yet. The attached patch is the very first version which does work, but relies on passing regex as start up param to the SolrJClient in the format -Dsolr.preferredQueryNodePattern=SOME_REGEX_MATCHING_A_SET_OF_SOLR_NODES This approached worked well for us but: It does not look very elegant and it does not integrate well into the current code base. so, a better way to do this is to use the snitch. Unfortunately, due to changes in priority, I was not able to come back to finish this work.
          Hide
          susheel2777@gmail.com Susheel Kumar added a comment - - edited

          Thanks, Noble and Arcadius for clarifying the status of SOLR-8146.

          Hello Noble, I can start working on the patch. Have a question to clarify

          1. For multi-data center scenario, the preferredNodes rule may specify different values / ranges depending on, from which data center solrj client is querying? So do you see preferredNodes rule being used during query operation like

          http://localhost:8983/solr/collection1/select?rule=preferredNodes=ip_1:192,ip_2:93

          The current Snitches design/implementation is only being used in Admin Collections API (https://cwiki.apache.org/confluence/display/solr/Collections+API) for replica placement so this will be another usage of Snitches and extending to query operations.

          Thanks,
          Susheel

          Show
          susheel2777@gmail.com Susheel Kumar added a comment - - edited Thanks, Noble and Arcadius for clarifying the status of SOLR-8146 . Hello Noble, I can start working on the patch. Have a question to clarify 1. For multi-data center scenario, the preferredNodes rule may specify different values / ranges depending on, from which data center solrj client is querying? So do you see preferredNodes rule being used during query operation like http://localhost:8983/solr/collection1/select?rule=preferredNodes=ip_1:192,ip_2:93 The current Snitches design/implementation is only being used in Admin Collections API ( https://cwiki.apache.org/confluence/display/solr/Collections+API ) for replica placement so this will be another usage of Snitches and extending to query operations. Thanks, Susheel
          Hide
          noble.paul Noble Paul added a comment -

          It should be also honored by SolrJ . SolrJ should look for the parameters and identify the nodes right there itself. If the request indeed reaches a node, The first server to receive this request should route the request to the right nodes
          The params could be as follows

          routingRule=ip_1:192&routingRule=ip_2:93
          
          Show
          noble.paul Noble Paul added a comment - It should be also honored by SolrJ . SolrJ should look for the parameters and identify the nodes right there itself. If the request indeed reaches a node, The first server to receive this request should route the request to the right nodes The params could be as follows routingRule=ip_1:192&routingRule=ip_2:93
          Hide
          susheel2777@gmail.com Susheel Kumar added a comment - - edited

          Thanks, Paul. I like the routingRule terminology than preferredNodes. The current rules like cores, freeDisk, host etc doesn't include "rule" in their names, so wanted to double check if "routingRule" name is okay and there is similar parameter name _route_ for routing keys https://cwiki.apache.org/confluence/display/solr/Advanced+Distributed+Request+Options. Hope these names all fit together to avoid any ambiguity.

          Show
          susheel2777@gmail.com Susheel Kumar added a comment - - edited Thanks, Paul. I like the routingRule terminology than preferredNodes. The current rules like cores, freeDisk, host etc doesn't include "rule" in their names, so wanted to double check if "routingRule" name is okay and there is similar parameter name _ route _ for routing keys https://cwiki.apache.org/confluence/display/solr/Advanced+Distributed+Request+Options . Hope these names all fit together to avoid any ambiguity.
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user susheelks opened a pull request:

          https://github.com/apache/lucene-solr/pull/66

          SOLR-8146: Allowing SolrJ CloudSolrClient to have preferred replica for query/read

          This pull request is to get feedback on the approach of implementing routingRule.

          The unit test is not ready yet as facing challenges on how to mock/ inject dependency to simulate a cluster with different IP addresses machines and only matching one gets added to urlList which ultimately gets passed to LBHttpSolrClient.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/susheelks/lucene-solr SOLR-8146

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/lucene-solr/pull/66.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #66


          commit e761d7c2e1ecf6ce37eb43bc764897fbed8cdc4e
          Author: Kumar, Susheel (CORP) <susheel.kumar@adp.com>
          Date: 2016-08-10T00:42:45Z

          changes for limiting query to shard matching routing rule


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user susheelks opened a pull request: https://github.com/apache/lucene-solr/pull/66 SOLR-8146 : Allowing SolrJ CloudSolrClient to have preferred replica for query/read This pull request is to get feedback on the approach of implementing routingRule. The unit test is not ready yet as facing challenges on how to mock/ inject dependency to simulate a cluster with different IP addresses machines and only matching one gets added to urlList which ultimately gets passed to LBHttpSolrClient. You can merge this pull request into a Git repository by running: $ git pull https://github.com/susheelks/lucene-solr SOLR-8146 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/66.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #66 commit e761d7c2e1ecf6ce37eb43bc764897fbed8cdc4e Author: Kumar, Susheel (CORP) <susheel.kumar@adp.com> Date: 2016-08-10T00:42:45Z changes for limiting query to shard matching routing rule
          Hide
          susheel2777@gmail.com Susheel Kumar added a comment -

          Hello Noble,

          Can you please review the pull request and provide feedback on the approach of implementing routingRule and accordingly i can move forward with it.

          Thanks,
          Susheel

          Show
          susheel2777@gmail.com Susheel Kumar added a comment - Hello Noble, Can you please review the pull request and provide feedback on the approach of implementing routingRule and accordingly i can move forward with it. Thanks, Susheel
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 3ab22f6e3a21e748220946aed7bac9bce3c9b332 in lucene-solr's branch refs/heads/branch_6x from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3ab22f6 ]

          SOLR-8146: refactored the replica rules classes so that they can be accessed from SolrJ

          Show
          jira-bot ASF subversion and git services added a comment - Commit 3ab22f6e3a21e748220946aed7bac9bce3c9b332 in lucene-solr's branch refs/heads/branch_6x from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=3ab22f6 ] SOLR-8146 : refactored the replica rules classes so that they can be accessed from SolrJ
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 063d624cdcf73e0eeb3c11487a76d4c3de7f40dc in lucene-solr's branch refs/heads/master from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=063d624 ]

          SOLR-8146: refactored the replica rules classes so that they can be accessed from SolrJ

          Show
          jira-bot ASF subversion and git services added a comment - Commit 063d624cdcf73e0eeb3c11487a76d4c3de7f40dc in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=063d624 ] SOLR-8146 : refactored the replica rules classes so that they can be accessed from SolrJ
          Hide
          noble.paul Noble Paul added a comment -

          The patch after the recent refactoring. Without that you cannot access it from SolrJ

          • class ClientSnitchContext is not implemented yet.
          • we will need to cache the tag (with a timeout) values (only the ones that need server input ) at SolrJ
          Show
          noble.paul Noble Paul added a comment - The patch after the recent refactoring. Without that you cannot access it from SolrJ class ClientSnitchContext is not implemented yet. we will need to cache the tag (with a timeout) values (only the ones that need server input ) at SolrJ
          Hide
          noble.paul Noble Paul added a comment -

          Susheel Kumar you can take up my patch and continue with that

          Show
          noble.paul Noble Paul added a comment - Susheel Kumar you can take up my patch and continue with that
          Hide
          susheel2777@gmail.com Susheel Kumar added a comment -

          Thank you, Noble. I am going thru the changes and will get back to you.

          Show
          susheel2777@gmail.com Susheel Kumar added a comment - Thank you, Noble. I am going thru the changes and will get back to you.
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user susheelks commented on the issue:

          https://github.com/apache/lucene-solr/pull/66

          Merged routingRule changes after latest refactored code

          Show
          githubbot ASF GitHub Bot added a comment - Github user susheelks commented on the issue: https://github.com/apache/lucene-solr/pull/66 Merged routingRule changes after latest refactored code
          Hide
          shalinmangar Shalin Shekhar Mangar added a comment -

          What is the status of this issue? Seems like some code has been committed but there is no mention in CHANGES.txt. Also now we have two Snitch classes on master (I did not check the other branches) one in org.apache.solr.cloud.rule.Snitch (which seems to be unused) and another in org.apache.solr.common.cloud.rule.Snitch. Can we please clean this up?

          Show
          shalinmangar Shalin Shekhar Mangar added a comment - What is the status of this issue? Seems like some code has been committed but there is no mention in CHANGES.txt. Also now we have two Snitch classes on master (I did not check the other branches) one in org.apache.solr.cloud.rule.Snitch (which seems to be unused) and another in org.apache.solr.common.cloud.rule.Snitch. Can we please clean this up?
          Hide
          noble.paul Noble Paul added a comment -

          What is done is just a refactoring so that this can be used in solrj. So, no need to mention it in changes.txt. yeah there is an unused snitch class that needs to go

          Show
          noble.paul Noble Paul added a comment - What is done is just a refactoring so that this can be used in solrj. So, no need to mention it in changes.txt. yeah there is an unused snitch class that needs to go
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit e6ce903a76b2fd6bb28dc76805add6b37a7814eb in lucene-solr's branch refs/heads/master from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6ce903 ]

          SOLR-8146: removing the unused class

          Show
          jira-bot ASF subversion and git services added a comment - Commit e6ce903a76b2fd6bb28dc76805add6b37a7814eb in lucene-solr's branch refs/heads/master from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=e6ce903 ] SOLR-8146 : removing the unused class
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 591984cd0325c387e3b4976e5236eb7c7cd1e93e in lucene-solr's branch refs/heads/branch_6x from Noble Paul
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=591984c ]

          SOLR-8146: removing the unused class

          Show
          jira-bot ASF subversion and git services added a comment - Commit 591984cd0325c387e3b4976e5236eb7c7cd1e93e in lucene-solr's branch refs/heads/branch_6x from Noble Paul [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=591984c ] SOLR-8146 : removing the unused class
          Hide
          githubbot ASF GitHub Bot added a comment -

          Github user susheelks closed the pull request at:

          https://github.com/apache/lucene-solr/pull/66

          Show
          githubbot ASF GitHub Bot added a comment - Github user susheelks closed the pull request at: https://github.com/apache/lucene-solr/pull/66
          Hide
          githubbot ASF GitHub Bot added a comment -

          GitHub user susheelks opened a pull request:

          https://github.com/apache/lucene-solr/pull/147

          SOLR-8146 decouple building url list from CloudSolrClient to separate class for…

          I am suggesting to decouple building the url list from CloudSolrClient.sendRequest(..) to a separate class. The advantage will be the ability to easily write unit test for building the url list part and as we implement more routingRules for querying like query only the same rack replica's / OR query replica's where mem/cpu/disk utilisation is below a threshold can be easily unit tested etc.

          I can add more tests if approach looks good. Please review.

          You can merge this pull request into a Git repository by running:

          $ git pull https://github.com/susheelks/lucene-solr SOLR-8146

          Alternatively you can review and apply these changes as the patch at:

          https://github.com/apache/lucene-solr/pull/147.patch

          To close this pull request, make a commit to your master/trunk branch
          with (at least) the following in the commit message:

          This closes #147


          commit 852aa685cc626a4a03c649895ae5ccbfb0008887
          Author: Susheel Kumar <susheel2777@gmail.com>
          Date: 2017-01-28T13:33:53Z

          decouple building url list from CloudSolrClient to separate class for better testability


          Show
          githubbot ASF GitHub Bot added a comment - GitHub user susheelks opened a pull request: https://github.com/apache/lucene-solr/pull/147 SOLR-8146 decouple building url list from CloudSolrClient to separate class for… I am suggesting to decouple building the url list from CloudSolrClient.sendRequest(..) to a separate class. The advantage will be the ability to easily write unit test for building the url list part and as we implement more routingRules for querying like query only the same rack replica's / OR query replica's where mem/cpu/disk utilisation is below a threshold can be easily unit tested etc. I can add more tests if approach looks good. Please review. You can merge this pull request into a Git repository by running: $ git pull https://github.com/susheelks/lucene-solr SOLR-8146 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/147.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #147 commit 852aa685cc626a4a03c649895ae5ccbfb0008887 Author: Susheel Kumar <susheel2777@gmail.com> Date: 2017-01-28T13:33:53Z decouple building url list from CloudSolrClient to separate class for better testability

            People

            • Assignee:
              Unassigned
              Reporter:
              arcadius Arcadius Ahouansou
            • Votes:
              6 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Created:
                Updated:

                Development