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.