On Jun 27, 2006, at 5:47 AM, Fabrice Robini wrote:
What is your advice for webApplication ?
It all depends :)
- IndexSearcher pool ?
No point in that. A single IndexSearcher for searches is all that is
ever needed. Having a warming IndexSearcher, as Solr implements,
makes sense in some cases.
- New IndexSearcher for each query ?
Never!
- Something else ?
Again, it all depends on your Lucene usage. If the index is static
only a single IndexSearcher is needed. If you you need to manage
updates you have to decide how quickly those updates are visible
(everyone will always say "immediately" to that question, but
pragmatically there are lots of things to consider in this regard).
Sorry there isn't a single best answer. But I am quite happy with
Solr's mechanism, but I'm using a Ruby on Rails front-end so a web
service makes sense in my current project.
Erik
Thanks a lot,
Fab
-----Original Message-----
From: Erik Hatcher [mailto:[EMAIL PROTECTED]
Sent: mardi 27 juin 2006 11:41
To: java-user@lucene.apache.org
Subject: Re: IndexSearcher in Servlet
On Jun 27, 2006, at 5:11 AM, heritrix.lucene wrote:
Hi,
I also had the same confusion. But today when i did the testing i
found that
it will merge your results. Therefore i believe that indexSearcher
is not
thread safe. I tried this on 10,000 requests per second.
You must have something else wrong in your system if you're seeing
results merged (or please provide us a test case that demonstrates
this).
A static IndexSearcher works just fine, though is not really the
right design for a web application as you'd want to put it into
application scope instead. Statics can be trouble in web
applications that end up getting distributed.
Erik
With Regards
On 6/27/06, Ramana Jelda <[EMAIL PROTECTED]> wrote:
Hi,
You are wrong.
In ur case (If I ignore any updates to index) , One IndexSearcher
object
is
enough.
IndexSearcher is thread safe.
Jelda
-----Original Message-----
From: heritrix.lucene [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 27, 2006 10:58 AM
To: java-user@lucene.apache.org
Subject: Re: IndexSearcher in Servlet
Hi,
The same question i asked yesterday. :-) And now i know the
answer :0
Creating a new searcher for each query will make your
application very very slow....... (leave this idea) U can not
have a static indexsearcher object. It will merge all results
and the user will get the result of their query alongwith the
others :-)
The method that i am adopting is, i'll create a pool of
static searchers.
and on every request the servlet will request a free searcher
object from the pool. When he is done with that pool. it'll
return back the searcher object to that pool. This way i'll
reuse my searcher objects.
On 6/27/06, Fabrice Robini <[EMAIL PROTECTED]> wrote:
Hello,
I have a question about the IndexSearcher().
I have a Servlet that has a searchDocument(String theQuery)
method.
These method instantiate a new IndexSearcher at each query:
searchDocument(String theQuery)
{
Searcher searcher = new IndexSearcher(indexPath);
.
}
Is it a good way ? Or Is it better to use a static
searcher, and use
the same for each query (and for each user).
Is it thread safe ? Will results not be mixed to users ? (if
user A
searchs car and user B searchs boats, is it sure that user
A will get
car and B will get boats, even if the IndexSearcher is
static and is
the same ?)
Thanks a lot,
Fab
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date:
26/06/2006
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date:
26/06/2006
--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date:
26/06/2006
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
