Thanks for the Reply Lance. >From your post my understanding is that Solr commiters are more focussed on http solr than EmbeddedSolrServer and EmbeddedSolrServer may not be tested for all features supported by http solr. Said that, can you please tell if there is any justification/usecase for using EmbeddedSolrServer? Reason am asking is if EmbeddedSolrServer is not advised by Solr committers than why don't they deprecate it and force users to go http solr route instead of EmbeddedSolrServer. Just trying to understand if there is any valid use-case for using EmbeddedSolrServer.
We currently have EmbeddedSolrServer with multi-core setup (one core per client and size of each core/index is in the range of 20G-70G) integrated in our web application and it has been working fine for us but after reading the responses I am now wondering if we should be moving towards Http Solr and what benefit we might get if EmbeddedSolrServer is replaced with Http Solr. For replication we have been using rsync tool and it has been working fine for us. Also for our needs (below) do you suggest Http Solr or EmbeddedSolrServer. 1) Indexing Speed is more important than flexibility 2) Have huge text articles/blog files (>2 MB) that needs to be parsed from filesystem and indexed. Our index size will be in the range of 20 GB - 70 GB per core. And there is a core for each client. 3) Need to store all the data in the index because we absolutely need the highlighter feature working and reading through Solr documentation I found that Highlighter can be used only when data is stored. 4) We also need to store positions and offsets because we need to be able to use phrase queries and also need the position of the terms in search result documents. Thanks K'Rider ----- Thanks -K'Rider -- View this message in context: http://lucene.472066.n3.nabble.com/Solr-Index-Concurrency-Is-it-possible-to-have-multiple-threads-write-to-same-index-tp4002544p4003622.html Sent from the Solr - User mailing list archive at Nabble.com.
