I agree. We chose embedded to minimize the maintenance cost of http solr
servers.
One more concern. Even if I have only one node doing indexing, other nodes
need to reopen index reader periodically to catch up with new changes,
right? Is there a solr request that does this?
Thanks,
Bing
--
Vie
Yeah, that is not really supported. One write lock and one IndexWriter per
index.
If you use embedded you want to share your CoreContainer, else don't use
embedded.
On Aug 6, 2012, at 1:56 PM, Bing Hua wrote:
> Hi,
>
> I'm trying to use two embedded solr servers pointing to a same solrhome /
Makes sense. Thank you.
--
View this message in context:
http://lucene.472066.n3.nabble.com/Multiple-Embedded-Servers-Pointing-to-single-solrhome-index-tp3999451p4000180.html
Sent from the Solr - User mailing list archive at Nabble.com.
No, you can only have one program controlling an index. This will not
work! You should use a primary/failover technique where one program
does all of the indexing, and then another program is the fallback for
the first indexer.
On Tue, Aug 7, 2012 at 7:31 AM, Bing Hua wrote:
> Thanks Lance. The u
Thanks Lance. The use case is to have a cluster of nodes which runs the same
application with EmbeddedSolrServer on each of them, and they all point to
the same index on NFS. Every application is designed equal, meaning that
everyone may index and/or search.
In such way, after every commit the wr
Where is the common index? On NFS?
If it is on a native hard disk (on the same computer) Solr uses the
file locking mechanism supplied by the operating system (Linux or
Windows). This may not be working right. See this for more info on
file locking:
http://wiki.apache.org/lucene-java/AvailableLock
