In many search engines, that would be a guaranteed crash. A postings list is read into memory, then replaced on disk, so now the engine has an inconsistent index.
Even if it works, don't be surprised if it breaks in a later release. The snapshot system exists precisely to do this in a safe manner. If you want a reliable search engine, I'd use the collection distribution scripts to do same machine distribution. I'm always amazed that people even think this might work. Do people try this with RDMBs, too? wunder On 10/1/08 11:47 AM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > You should be able to run like that. Most likely nobody can answer your last > question with certainty because it's likely very few people, if any, are > running Solr in this type of a setup. > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > ----- Original Message ---- >> From: Jagadish Rath <[EMAIL PROTECTED]> >> To: solr-user@lucene.apache.org >> Sent: Wednesday, October 1, 2008 11:49:27 AM >> Subject: Re: Anyproblem in running two solr instances on the same machine >> using the same directory ? >> >> Ok. Can we run two solr instances(using the same data directory) one for >> commits and the other for queries on the same machine ? Are there any known >> issues for this ? >> >> On Fri, Sep 26, 2008 at 11:48 AM, Jagadish Rath wrote: >> >>> Hi >>> >>> I am running two solr instances on the same machine using the same data >>> directory. one on port 8982 and the other on 8984. >>> >>> - 1st one *only accepts commits* (indexer) -- *port 8982* >>> >>> -- It has all tha cache size as 0, to get rid of warmup of >>> searchers >>> >>> - 2nd one* accepts all the queries*.(searcher) -- *port 8984* >>> >>> -- It has non-zero cache size as it needs to handle queries >>> >>> - I have a cron *which does a dummy commit to the 2nd instance (on port >>> 8984)* to update its searcher every 1 minute. >>> >>> --- *curl http://localhost:8984/solr/update -s -H >>> 'Content-type:text/xml; charset=utf-8' -d ""* >>> >>> I am trying to use this as a *solution to the maxWarmingSearcher limit >>> exceeded Error* that occurs as a result of a large no. of commits. I am >>> trying to use this solution as an alternate to the conventional master/slave >>> solution. >>> >>> I have following questions >>> >>> - *Is there any known issue with this solution or any issues that can >>> be foreseen for this solution?* >>> >>> * -- does it result in a corrupted index ? >>> * >>> >>> - *What are the other solutions to the problem of "maxWarmingSearchers >>> limit exceeded error " ?** * >>> >>> A would really appreciate a quick response. >>> >>> Thanks >>> Jagadish Rath >>> >
