Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable
Subject: RE: IndexSearcher in Servlet
Date: Tue, 27 Jun 2006 09:00:22 -0400
Message-ID: 
 <63434C14F9A6F74CB36B85033E4C30CA0255FAD2@hermes.corp.cyveillance.com>
Thread-Topic: IndexSearcher in Servlet
Thread-Index: AcaZ13Gg6l7dV6txStyjvDNrK22CpQACb3AgAAIOP0A=
From: "Omar Didi" <odidi@Cyveillance.com>
To: <java-user@lucene.apache.org>

you can initiliaze your IndexSearcher in a Servlet Listner, and even =
warm it up with few queries. that way when the user sends the first =
query it won't take a long time to load the index in RAM.

> -----Original Message-----
> From: Fabrice Robini [mailto:frobini@octo.com]
> Sent: Tuesday, June 27, 2006 8:01 AM
> To: java-user@lucene.apache.org
> Subject: RE: IndexSearcher in Servlet
>=20
>=20
> Erik,
>=20
> Thank you for your reply.
> I'm goingto use the static IndexSearcher in my Servlet (my=20
> index is static).
>=20
> Thanks :-)
>=20
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]=20
> Sent: mardi 27 juin 2006 12:49
> To: java-user@lucene.apache.org
> Subject: Re: IndexSearcher in Servlet
>=20
>=20
> On Jun 27, 2006, at 5:47 AM, Fabrice Robini wrote:
> > What is your advice for webApplication ?
>=20
> It all depends :)
>=20
> > - IndexSearcher pool ?
>=20
> No point in that.  A single IndexSearcher for searches is all=20
> that is =20
> ever needed.  Having a warming IndexSearcher, as Solr implements, =20
> makes sense in some cases.
>=20
> > - New IndexSearcher for each query ?
>=20
> Never!
>=20
> > - Something else ?
>=20
> Again, it all depends on your Lucene usage.  If the index is static =20
> only a single IndexSearcher is needed.  If you you need to manage =20
> updates you have to decide how quickly those updates are visible =20
> (everyone will always say "immediately" to that question, but =20
> pragmatically there are lots of things to consider in this regard).
>=20
> Sorry there isn't a single best answer.   But I am quite happy with =20
> Solr's mechanism, but I'm using a Ruby on Rails front-end so a web =20
> service makes sense in my current project.
>=20
> 	Erik
>=20
>=20
>=20
> >
> > Thanks a lot,
> >
> > Fab
> >
> > -----Original Message-----
> > From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> > 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 <ramana.jelda@ciao-group.com> 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:heritrix.lucene@gmail.com]
> >>>> 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 <frobini@octo.com> 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 =3D 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
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>>=20
> --------------------------------------------------------------------=20
> >>> -
> >>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: java-user-help@lucene.apache.org
> >>>
> >>>
> >
> >
> >=20
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
> >
> >
> > --=20
> > No virus found in this incoming message.
> > Checked by AVG Free Edition.
> > Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date: =20
> > 26/06/2006
> >
> >
> > --=20
> > No virus found in this outgoing message.
> > Checked by AVG Free Edition.
> > Version: 7.1.394 / Virus Database: 268.9.5/376 - Release Date: =20
> > 26/06/2006
> >
> >
> >
> >=20
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: java-user-help@lucene.apache.org
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>=20
>=20
> --=20
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.5/376 - Release=20
> Date: 26/06/2006
> =20
>=20
> --=20
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.394 / Virus Database: 268.9.5/376 - Release=20
> Date: 26/06/2006
> =20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
> For additional commands, e-mail: java-user-help@lucene.apache.org
>=20
>=20

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org