You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Jon Poulton <Jo...@vyre.com> on 2009/12/09 18:47:11 UTC
Concurrent access to EmbeddedSolrServer
Hi there,
I'm about to start implementing some code which will access a Solr instance via a ThreadPool concurrently. I've been looking at the solrj API docs ( particularly http://lucene.apache.org/solr/api/index.html?org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.html ) and I just want to make sure what I have in mind makes sense. The Javadoc is a bit sparse, so I thought I'd ask a couple of questions here.
1) I'm assuming that EmbeddedSolrServer can be accessed concurrently by several threads at once for add, delete and query operations (on the SolrServer parent interface). Is that right? I don't have to enforce single-threaded access?
2) What happens if multiple threads simultaneously call commit?
3) What happens if multiple threads simultaneously call optimize?
4) Both commit and optimise have optional parameters called "waitFlush" and "waitSearcher". These are undocumented in the Javadoc. What do they signify?
Thanks in advance for any help.
Cheers
Jon
Re: Concurrent access to EmbeddedSolrServer
Posted by Reuben A Christie <ch...@knewco.com>.
we learned it hard way, Wish I had read this before
http://wiki.apache.org/solr/EmbeddedSolr
it is not threadsafe. start seeing concurrent modification exception as
soon as within 100 Samples, when you load it with more than 1 Concurrent
Users ( I have tested it using jmeter)
best,
Reuben
On 12/9/2009 12:47 PM, Jon Poulton wrote:
> Hi there,
> I'm about to start implementing some code which will access a Solr instance via a ThreadPool concurrently. I've been looking at the solrj API docs ( particularly http://lucene.apache.org/solr/api/index.html?org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.html ) and I just want to make sure what I have in mind makes sense. The Javadoc is a bit sparse, so I thought I'd ask a couple of questions here.
>
>
> 1) I'm assuming that EmbeddedSolrServer can be accessed concurrently by several threads at once for add, delete and query operations (on the SolrServer parent interface). Is that right? I don't have to enforce single-threaded access?
>
> 2) What happens if multiple threads simultaneously call commit?
>
> 3) What happens if multiple threads simultaneously call optimize?
>
> 4) Both commit and optimise have optional parameters called "waitFlush" and "waitSearcher". These are undocumented in the Javadoc. What do they signify?
>
> Thanks in advance for any help.
>
> Cheers
>
> Jon
>
--
Re: Concurrent access to EmbeddedSolrServer
Posted by Shalin Shekhar Mangar <sh...@gmail.com>.
On Wed, Dec 9, 2009 at 11:17 PM, Jon Poulton <Jo...@vyre.com> wrote:
> Hi there,
> I'm about to start implementing some code which will access a Solr instance
> via a ThreadPool concurrently. I've been looking at the solrj API docs (
> particularly
> http://lucene.apache.org/solr/api/index.html?org/apache/solr/client/solrj/embedded/EmbeddedSolrServer.html) and I just want to make sure what I have in mind makes sense. The Javadoc
> is a bit sparse, so I thought I'd ask a couple of questions here.
>
>
> 1) I'm assuming that EmbeddedSolrServer can be accessed concurrently
> by several threads at once for add, delete and query operations (on the
> SolrServer parent interface). Is that right? I don't have to enforce
> single-threaded access?
>
>
Yes. It is thread-safe.
> 2) What happens if multiple threads simultaneously call commit?
>
> 3) What happens if multiple threads simultaneously call optimize?
>
>
For both #2 and #3 - The requests will be queued. As a best practice,
consider committing only when necessary (preferably, once at the end).
> 4) Both commit and optimise have optional parameters called
> "waitFlush" and "waitSearcher". These are undocumented in the Javadoc. What
> do they signify?
>
>
See
http://wiki.apache.org/solr/UpdateXmlMessages#Optional_attributes_for_.22commit.22_and_.22optimize.22
--
Regards,
Shalin Shekhar Mangar.