[ 
https://issues.apache.org/jira/browse/SOLR-11629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Varun Thacker updated SOLR-11629:
---------------------------------
    Attachment: SOLR-11629.patch

Thanks Jason for the patch! I think we're very close. I've noted some of the 
minor changes I made on top of your patch. I want to address one doubt 
mentioned below before committing it

- For example changed {{final List<String> hosts = new ArrayList<String>();}} 
to use automatic type inference 
- Spaces between the for and the curly bracket : {{for(int i=0}} . Been 
following Mike's advise
- In {{testZkConnectionStringConstructorWithValidChroot}} got rid of the 
unecessary clientChroot variable
- Some reordering of import ordering intellij on the clean unused shortcut
- Minor changes to the CloudSolrClient jdocs
- Changed the wording of the deprecation warning for 
CloudSolrClient::withClusterStateProvider 


In solrUrls approach should we add only one url only? Maybe we should be adding 
all solr urls ? 
{code}
+    public CloudSolrClientBuilder(MiniSolrCloudCluster cluster) {
+      if (random().nextBoolean()) {
+        this.zkHosts.add(cluster.getZkServer().getZkAddress());
+      } else {
+        
this.solrUrls.add(cluster.getRandomJetty(random()).getBaseUrl().toString());
+      }
{code}

On a side note we should randomize b/w the zkhost || solrUrls for all tests. 
The solrUrls approach has very less test coverage

> CloudSolrClient.Builder should accept a zk host
> -----------------------------------------------
>
>                 Key: SOLR-11629
>                 URL: https://issues.apache.org/jira/browse/SOLR-11629
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Varun Thacker
>            Assignee: Varun Thacker
>         Attachments: SOLR-11629.patch, SOLR-11629.patch, SOLR-11629.patch
>
>
> Today we need to create an empty builder and then wither pass zkHost or 
> withSolrUrl
> {code}
> SolrClient solrClient = new 
> CloudSolrClient.Builder().withZkHost("localhost:9983").build();
> solrClient.request(updateRequest, "gettingstarted");
> {code}
> What if we have two constructors , one that accepts a zkHost and one that 
> accepts a SolrUrl .
> The advantages that I can think of are:
> - It will be obvious to users that we support two mechanisms of creating a 
> CloudSolrClient . The SolrUrl option is cool and applications don't need to 
> know about ZooKeeper and new users will learn about this . Maybe our 
> example's on the ref guide should use this? 
> - Today people can set both zkHost and solrUrl  but CloudSolrClient can only 
> utilize one of them
> HttpClient's Builder accepts the host 
> {code}
> HttpSolrClient client = new 
> HttpSolrClient.Builder("http://localhost:8983/solr";).build();
> client.request(updateRequest, "techproducts");
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to