The data _is_ separated from the code. It's all relative
to solr_home which need not have any relation to where
the code is executing from.
For instance, I can start Solr like
java -Dsolr.solr.home=/Users/Erick/testdir/solr -jar start.jar
and have my war in a completely different place.
Best,
The problem we had was that we tried to run:
java -Dsolr.data.dir=/opt/solr/data -Dsolr.solr.home=/opt/solr/home -jar
start.jar
and got different behavior for how solr handles these 2 params.
we created 2 collections, which created 2 cores.
then we got 2 home dirs for the cores, as expected:
On Nov 25, 2013, at 8:12 AM, adfel70 adfe...@gmail.com wrote:
I was expecting that the path I sent would serve as the BASE path for all
cores the the node hosts
When running Solr on HDFS, there is a similar prop you can use
-Dsolr.hdfs.home. If you set that, all data dirs are created nicely
On 11/26/2013 9:19 AM, adfel70 wrote:
The problem we had was that we tried to run:
java -Dsolr.data.dir=/opt/solr/data -Dsolr.solr.home=/opt/solr/home -jar
start.jar
and got different behavior for how solr handles these 2 params.
we created 2 collections, which created 2 cores.
then we got 2
The first thing I'd do is not send an absolute path. What
happens if you just sent -Dsolr.data.dir=data? (no '/')?
We had this discussion a while ago when we were working
on auto-discovery, and it turns out that
there _are_ legitimate cases in which more than one
core/collection can point to the
Thanks for the reply, Erick.
Actually, I didnt not think this through. I just thought it would be a good
idea to separate the data from the application code.
I guess I'll leave it without setting the datadir parameter and add a
symlink.
--
View this message in context:
