[ 
https://issues.apache.org/jira/browse/SOLR-4450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13583057#comment-13583057
 ] 

Jan Høydahl commented on SOLR-4450:
-----------------------------------

I'm not a big fan of having to start a lot of runtime services before you can 
begin configuring your environment. The issue is that some people will start 
scripting 1) start ZK 2) start a solr node 3) call collections api 4) stop solr 
5) stop ZK just to get a pre-configured setup to store in their git/svn. I 
think we should promote using ZK as THE config service for Solr so you get 1) 
Start an empty ZK 2) upload your cluster config including all collections, 
numshards etc to ZK and 3) start an empty Solr pointing to ZK, and it will do 
what it should. Such dynamic config should not be scattered around in solr.xml 
on all nodes.

zkCli is a good start. But if we focus on polishing and documenting the ZK 
"schema" then we can arrive at the original goal of changing a config in ZK, 
and the Solr cluster will sniff this and do whatever necessary to comply. If 
the ZK "schema" is well documented (and versioned) then 3rd party (graphical) 
tools and plugins to other admin tools, other ZK mgmt tools etc will follow.
                
> Developer Curb Appeal: Need consistent command line arguments for all nodes
> ---------------------------------------------------------------------------
>
>                 Key: SOLR-4450
>                 URL: https://issues.apache.org/jira/browse/SOLR-4450
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 4.1
>            Reporter: Mark Bennett
>             Fix For: 4.2
>
>
> Suppose you want to create a small 4 node cluster (2x2, two shards, each 
> replicated), each on it's own machine.
> It'd be nice to use the same script in /etc/init.d to start them all, but 
> it's hard to come up with a set of arguments that works for both the first 
> and subsequent nodes.
> When MANUALLY starting them, the arguments for the first node are different 
> than for subsequent nodes:
> Node A like this:
>     -DzkRun -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf 
> -Dcollection.configName=MyConfig -jar start.jar
> Vs. the other 3 nodes, B, C, D:
>       -DzkHost=nodeA:9983 -jar start.jar
> But if you combine them, you either still have to rely on Node A being up 
> first, and have all nodes reference it:
>     -DzkRun -DzkHost=nodeA:9983 -DnumShards=2 
> -Dbootstrap_confdir=./solr/collection1/conf -Dcollection.configName=MyConfig
> OR you can try to specify the address of all 4 machines, in all 4 startup 
> scripts, which seems logical but doesn't work:
>     -DzkRun -DzkHost=nodeA:9983,nodeB:9983,nodeC:9983,nodeD:9983 
> -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf 
> -Dcollection.configName=MyConfig
> This gives an error:
> org.apache.solr.common.SolrException log
> SEVERE: null:java.lang.IllegalArgumentException: port out of range:-1
> This thread suggests a possible change in syntax, but doesn't seem to work 
> (at least with the embedded ZooKeeper)
> Thread:
> http://lucene.472066.n3.nabble.com/solr4-0-problem-zkHost-with-multiple-hosts-throws-out-of-range-exception-td4014440.html
> Syntax:
>     -DzkRun -DzkHost=nodeA:9983,nodeB:9983,nodeC:9983,nodeD:9983/solrroot 
> -DnumShards=2 -Dbootstrap_confdir=./solr/collection1/conf 
> -Dcollection.configName=MyConfig
> Error:
> SEVERE: Could not start Solr. Check solr/home property and the logs
> Feb 12, 2013 1:36:49 PM org.apache.solr.common.SolrException log
> SEVERE: null:java.lang.NumberFormatException: For input string: 
> "9983/solrroot"
>         at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> So:
> * There needs to be some syntax that all nodes can run, even if it requires 
> listing addresses  (or multicast!)
> * And then clear documentation about suggesting external ZooKeeper to be used 
> for production (list being maintained in SOLR-4444)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

Reply via email to