Thanks, Hoss.

For the last question, yes I understand now it's referring to whatever solr
home we have named.  However, there's still the last part of my question
that feels suspicious why the "solr" string is directly coded in the script
(unlike other cases they usually use ${solr_root} to get to specific dirs.
)   I pasted this line again below:

I saw in snappuller line 226 (solr 1.2):

${stats} rsync://${master_host}:${rsyncd_port}/solr/${name}/
${data_dir}/${name}-wip

Is the above "solr" a hard-coded solr home name? If so, it's not desirable
since we have multiple solr homes with different names.  If not, what is
this "solr"?



Thanks,
-Hui




On 9/20/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
>
>
> : 1) config different port for each solr home dir (since they run on the
> same
> : host);
>
> you mean a differnet rsync port right? ... yes the scripts as distributed
> assume that each rsync daemon will be dedicated to a single solr
> "instance" .. the idea beaing that even if you have 12 Solr intances
> running on one servlet container port, you have 12 seperate rsync ports so
> you can start/stop enable/disable them independently when doing index
> rebuilds, etc...
>
> : 2) run rsync-start script under each of the solr home's bin dir.
> : (btw, just to make clear, we should run rsync-start after rsync-enable
> that
> : I understand.)
>
> correct, rsyncd-enable just sets the flag file so that rsyncd-start will
> function ... the idea being that you can install rsyncd-start in such a
> way that it will run whenever your port is startup, or whenever you box is
> booted, but disable it from happening without removing the script from
> those places.
>
> : Can someone confirm my understanding? Does the #3 question suggests a
> : hard-coded "solr" that shouldn't be?
>
> solr/conf, solr/bin, solr/data, solr/logs ... all assume your solr home
> directory is named "solr/", but that's not a requirement.  It's a pretty
> pervasive documentation shortcut that could be changed if osmeone wanted
> to be systematic about it, but I don't think it's all that bad since
> that's a decent "common case"
>
>
>
> -Hoss
>
>


-- 
Regards,

-Hui

Reply via email to