1> Well, it loads the local conf directory up to zookeeper so new nodes can
fetch the configuration and store it locally.
2> No, you have to upload the configuration to ZK and (I think) restart the
other servers. It's easy enough to test, just make your changes to the
config, upload it, and look at the resulting configs to insure that the
changes have been fetched.
3> No. You can run these shards in the same JVM as far as I know. This is
sometimes called "microsharding" or "oversharding" and is a pretty common
approach. Search the list I think theres been some discussion recently on
this very topic.
4> Mostly the container you use is determined by which one you're
comfortable with. Solr runs on Jetty, Tomcat, JBOSS and a host of others.
It's just simplest to start OOB with Jetty.

Best,
Erick


On Sat, Nov 17, 2012 at 2:13 AM, Cool Techi <cooltec...@outlook.com> wrote:

> Hi,
>
> I have just started working with Solr cloud and have a few questions
> related to the same,
>
> 1) In the start script we provide the the following, what's the purpose of
> providing this.
> -Dbootstrap_confdir=./solr/collection1/conf Since we don't yet have a
> config in zookeeper, this parameter causes the local configuration
> directory ./solr/conf to be uploaded as the "myconf" config.  The name
> "myconf" is taken from the "collection.configName" param below.
> -Dcollection.configName=myconf sets the config to use for the new
> collection. Omitting this param will cause the config name to default to
> "configuration1"
> 2) When we make any changes into the config/schema do we need to copy it
> to all the shards running in the cloud manually?3) If we want to start with
> 10 shards on 2 machines, anticipating the future growth, do all these
> shards needs to run on separate jetty instances4) Is there any advantage of
> running solr on jetty then Tomcat?
> Thanks,Ayush
>
>

Reply via email to