That's exactly what we're doing (setting the value in each config). The main
problem with that is we have multiple people working on each of these solr
projects, in different environments. Their data.dir path is always the same
(relative) value which works fine under Jetty. But running under tomcat, the
data dir is relative to tomcat's home. So an absolute hard-coded path is the
only solution. My hope was that we'd be able to override it using the same
method as setting the "solr/home" value in the tomcat context file.

The thought of running multiple tomcats is interesting. Do you have any
issues with memory or cpu performance?

Thanks,
Matt

On Tue, Mar 3, 2009 at 11:45 AM, Matthew Runo <mr...@zappos.com> wrote:

> Perhaps you could hard code it in the solrconfig.xml file for each solr
> instance? Other than that, what we did was run multiple instances of Tomcat.
> That way if something goes bad in one, it doesn't affect the others.
>
> Thanks for your time!
>
> Matthew Runo
> Software Engineer, Zappos.com
> mr...@zappos.com - 702-943-7833
>
> On Mar 3, 2009, at 8:39 AM, Matt Mitchell wrote:
>
>  Hi Matthew,
>>
>> The problem is that we have multiple instances of solr running under one
>> tomcat. So setting -Dsolr.data.dir=foo would set the home for every solr.
>> I
>> guess multi-core might solve my problem, but that'd change our app
>> architecture too much, maybe some other day.
>>
>> I *kind* of have a solution for the permissions thing though:
>>
>> - The project user is part of the tomcat group.
>> - The tomcat user is part of the project user group.
>> - We're making a call to "umask 002" in the tomcat catalina.sh file (means
>> all files created will have group write)
>>
>> So when solr (tomcat) creates the index, they're group writable now and I
>> can remove etc.!
>>
>> So, I still need to figure out the data.dir problem. Hmm.
>>
>> Thanks for your help,
>> Matt
>>
>> On Tue, Mar 3, 2009 at 11:31 AM, Matthew Runo <mr...@zappos.com> wrote:
>>
>>  It looks like if you set a -Dsolr.data.dir=foo then you could specify
>>> where
>>> the index would be stored, yes?  Are you properly setting your solr.home?
>>> I've never had to set the data directory specifically, Solr has always
>>> put
>>> it under my home.
>>>
>>> From solrconfig.xml:
>>> <dataDir>${solr.data.dir:./solr/data}</dataDir>
>>>
>>> Since Solr is running under tomcat, I'd assume that the index will always
>>> appear to be owned by tomcat as well. I don't think there is any way to
>>> have
>>> a different user for the written files - but someone else might want to
>>> chime in before you believe me 100% on this one.
>>>
>>> Thanks for your time!
>>>
>>> Matthew Runo
>>> Software Engineer, Zappos.com
>>> mr...@zappos.com - 702-943-7833
>>>
>>>
>>> On Mar 2, 2009, at 5:46 PM, Matt Mitchell wrote:
>>>
>>> Hi. I'm sorry if this is the second time this message comes through!
>>>
>>>>
>>>> A few questions here...
>>>>
>>>> #1
>>>> Does anyone know how to set the user/group and/or permissions on the
>>>> index
>>>> that solr creates? It's always the tomcat user. Is it possible to change
>>>> this in my context file? Help!
>>>>
>>>> #2
>>>> I'm deploying Solr via Tomcat and really thought I had this stuff down.
>>>> But
>>>> it seems that with some recent system upgrades, my scheme is failing to
>>>> set
>>>> the data dir correctly.
>>>>
>>>> I'm deploying solr to tomcat, using a context file as described here:
>>>>
>>>>
>>>> http://wiki.apache.org/solr/SolrTomcat#head-024d7e11209030f1dbcac9974e55106abae837ac
>>>>
>>>> But when I deploy, Tomcat says that it can't find a ./data/index
>>>> directory
>>>> -- relative to the tomcat home directory. How can I set the data dir
>>>> relative to the solr home value I'm specifying in the tomcat context
>>>> file?
>>>> Note: a hard-coded absolute path works, but I want to configure at
>>>> deployment time.
>>>>
>>>> In the past, I tried setting the data dir in the same way the solr home
>>>> is
>>>> set in the context file without luck. Does this now work in the latest
>>>> solr
>>>> nightly?
>>>>
>>>> Thanks,
>>>>
>>>>
>>>
>>>
>

Reply via email to