Re: IndexSearcher and IndexWriter.rollback

Q1. Are you using a SearcherManager or a direct IndexSearcher? If you are using a SearcherManager, you could just call `maybeRefresh()` and then re-acquire a new `IndexSearcher`. The method docs

Re: IndexSearcher creation policy question

Your best bet is to use a searcher manager to manage the searcher instance, and only refresh the manager if writes are committed. This way the same searcher instances can be shared by multiple threads. For the paging, if you want to have a guaranteed consistent view, you have to keep around the se

RE: IndexSearcher using Collector

Hi, The search function does block. IndexSearcher.search(Query, Collector) returns when all collecting is done. You can do the after-collect work after it returns. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Messag

Re: IndexSearcher with two Indexes

On Fri, Jan 27, 2012 at 4:53 PM, Hany Azzam wrote: > Hi Robert, > > Thanks for the reply. I am trying to do something different. If I use a > mutireader then the searching/scoring will take place over the two indexes at > the same time. However, in my case the subcomponents of the retrieval mode

Re: IndexSearcher with two Indexes

Hi Robert, Thanks for the reply. I am trying to do something different. If I use a mutireader then the searching/scoring will take place over the two indexes at the same time. However, in my case the subcomponents of the retrieval model are calculated over separate evidence spaces. For example,

Re: IndexSearcher with two Indexes

On Fri, Jan 27, 2012 at 3:21 PM, Hany Azzam wrote: > Hi, > > I have two indexes. One that contains all the documents in the collection and > the other contains only the relevant documents. I am using Lucene 4.0 and the > new SimilariyBase class to build my retrieval models (similarity functions)

Re: IndexSearcher with two Indexes

Hi, I have two indexes. One that contains all the documents in the collection and the other contains only the relevant documents. I am using Lucene 4.0 and the new SimilariyBase class to build my retrieval models (similarity functions). One of the retrieval models requires statistics to be comp

Re: IndexSearcher Single Instance Bottleneck?

No, Lucene itself shouldn't be doing this, the recommendation is for multiple threads to share a single searcher. I'd first look upstream, are your requests being processed serially? I.e. is there a single thread that's handling requests? Best Erick On Thu, Mar 10, 2011 at 4:25 PM, RobM wrote: >

Re: IndexSearcher - open file handles by deleted files

Just closing IndexSearcher should be enough. Are you really sure you're closing all IndexSearchers you've opened? Hmm the code looks somewhat dangerous. Why sleep for 10 seconds before closing? Is this to ensure any in-flight queries finish? It's better to explicitly track this (eg w/ IndexRea

Re: IndexSearcher

Thanks! 2009/3/9 Andrzej Bialecki > liat oren wrote: > >> Yes, I changed it to TOKENIZED and its working now, Thanks! >> >> About Luke, what do you mean by saying that the analyzer is in the >> classpath? >> It exists in a package in my computer - it also has its filter and other >> classes. How

Re: IndexSearcher

liat oren wrote: Yes, I changed it to TOKENIZED and its working now, Thanks! About Luke, what do you mean by saying that the analyzer is in the classpath? It exists in a package in my computer - it also has its filter and other classes. How can it be used in Luke? You need to add this jar to t

Re: IndexSearcher

Yes, I changed it to TOKENIZED and its working now, Thanks! About Luke, what do you mean by saying that the analyzer is in the classpath? It exists in a package in my computer - it also has its filter and other classes. How can it be used in Luke? 2009/3/8 Andrzej Bialecki > liat oren wrote: >

Re: IndexSearcher

liat oren wrote: Ok, thanks. I will have to edit the code of Luke in order to add another analyzer, right? No - if your analyzer is already on the classpath, then it's enough to type in the fully qualified class name in the drop down box (it's editable). -- Best regards, Andrzej Bialecki

Re: IndexSearcher

What Shashi said. On Sun, Mar 8, 2009 at 10:22 AM, Shashi Kant wrote: > Liat, i think what Erick suggested was to use the TOKENIZED setting instead > of UN_TOKENIZED. For example your code should read something like: > > Document doc = new Document(); > doc.add(new Field(WordIndex.FIELD_WORL

Re: IndexSearcher

Liat, i think what Erick suggested was to use the TOKENIZED setting instead of UN_TOKENIZED. For example your code should read something like: Document doc = new Document(); doc.add(new Field(WordIndex.FIELD_WORLDS, "111 222 333", Field.Store.YES, * Field.Index.TOKENIZED*)); Unless I am missing s

Re: IndexSearcher

In Luke, you can select from among most of the analyzers provided by Lucene, there's a drop-down on the search tab. And I'm sure you can add your own custom ones, but I confess I've never tried. Best Erick On Sun, Mar 8, 2009 at 4:14 AM, liat oren wrote: > Ok, thanks. > > I will have to edit th

Re: IndexSearcher

Ok, thanks. I will have to edit the code of Luke in order to add another analyzer, right? If I need to query a long text - for example to search for articles that are textually close in their content, I need to parse to the query the text of the article. Then I get the error that it is too long.

Re: IndexSearcher

I think your root problem is that you're indexing UN_TOKENIZED, which means that the tokens you're adding to your index are NOT run through the analyzer. So your terms are exactly "111", "222 333" and "111 222 333", none of which match "222". I expect you wanted your tokens to be "111", "222", and

Re: IndexSearcher - architecture - shortest possible latency between update of index (via IndexWriter/IndexReader) and querying the same using IndexSearcher

Thanks Erick for the clarifications regarding the same. Assuming we have a RAMDirectory based inverted index (along with a FSDirectory for a secondary storage index) - what would be the limitation on the RAMDirectory capacity in terms of the size of the index. (other than the main memory i.e.

Re: IndexSearcher - architecture - shortest possible latency between update of index (via IndexWriter/IndexReader) and querying the same using IndexSearcher

This topic has been discussed *very* extensively, so I'd recommend you search the mail archive (see http://wiki.apache.org/lucene-java/MailingListArchives ) since there are more good ideas there than I can remember. But the short answer is that you must open a new searcher for modifications to be s

Re: IndexSearcher and multi-threaded performance

It's more than possible, it's probable. Cache thrashing would definitely be my first guess; with so many copies of the exact same data you're not only missing out on significant gains with the L2 cache, you're also taking a major hit with every cache miss (which probably happens every context swit

Re: IndexSearcher and multi-threaded performance

Also, by OS is the one reason we can think of now, but that doesn't mean there aren't other reasons. EG, who knows -- maybe for small indexes NIO doesn't help but for large ones it does (just an example) and so you'd want non-static choice. Mike Yonik Seeley wrote: On Wed, Nov 12, 20

Re: IndexSearcher and multi-threaded performance

Good! In fact now we see similar slowness with nio-thread vs nio-shared as we see for RAM-thread vs RAM-shared. Ie, for both RAM and NIO you get better performance sharing a single reader than reader-per-thread. This is odd -- I would have expected that with infinite RAM reader-per- thr

Re: IndexSearcher and multi-threaded performance

On Wed, Nov 12, 2008 at 5:00 PM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > since the choice of FSDirectory varient is largly going to be based on OS, > I can't think of any reason why a static setter method wouldn't be good > enough in this particular case. https://issues.apache.org/jira/browse

Re: IndexSearcher and multi-threaded performance

: >From the user perspective: a public constructor would be the most : obvious, and would be consistent with RAMDirectory. A lot of the cases where system properties are currently used can't really be solved this way because the client isn't the one constructing the object. SegmentReader's IMP

Re: IndexSearcher and multi-threaded performance

>From the user perspective: a public constructor would be the most obvious, and would be consistent with RAMDirectory. Dmitri On Wed, Nov 12, 2008 at 4:50 AM, Michael McCandless <[EMAIL PROTECTED]> wrote: > > I think we really should open up a non-static way to choose a different > FSDirectory im

Re: IndexSearcher and multi-threaded performance

Nice! At 8 threads nio-shared catches up with ram-shared. Here's the complete table: fs-thread nio-thread ram-thread fs-shared nio-shared ram-shared 1 71877 70461 54739 73986 72155 61595 2 34949 34945 26735 43719 33019 28935 3

Re: IndexSearcher and multi-threaded performance

I'm thinking about it, so if someone else doesn't get something together before I have some free time... Its just not clear to me at the moment how best to do it. Michael McCandless wrote: Any takers for pulling a patch together...? Mike Mark Miller wrote: +1 - Mark On Nov 12, 2008, at

Re: IndexSearcher and multi-threaded performance

Any takers for pulling a patch together...? Mike Mark Miller wrote: +1 - Mark On Nov 12, 2008, at 4:50 AM, Michael McCandless <[EMAIL PROTECTED] > wrote: I think we really should open up a non-static way to choose a different FSDirectory impl? EG maybe add optional Class to FSDir

Re: IndexSearcher and multi-threaded performance

+1 - Mark On Nov 12, 2008, at 4:50 AM, Michael McCandless <[EMAIL PROTECTED] > wrote: I think we really should open up a non-static way to choose a different FSDirectory impl? EG maybe add optional Class to FSDirectory.getDirectory? Or maybe give NIOFSDirectory a public ctor? Or s

Re: IndexSearcher and multi-threaded performance

I think we really should open up a non-static way to choose a different FSDirectory impl? EG maybe add optional Class to FSDirectory.getDirectory? Or maybe give NIOFSDirectory a public ctor? Or something? Mike Mark Miller wrote: Mark Miller wrote: Thats a good point, and points out

Re: IndexSearcher and multi-threaded performance

Mark Miller wrote: Thats a good point, and points out a bug in solr trunk for me. Frankly I don't see how its done. There is no code I can see/find to use it rather than FSDirectory. Still assuming there must be a way, but I don't see it... Ah - brain freeze. What else is new :) You have to s

Re: IndexSearcher and multi-threaded performance

Dmitri Bichko wrote: 32 cores, actually :) Glossed over that - even better! Killer machine to be able to test this on. I reran the test with readonly turned on (I changed how the time is measured a little, it should be more consistent): fs-thread ram-thread fs-shared

Re: IndexSearcher and multi-threaded performance

32 cores, actually :) I reran the test with readonly turned on (I changed how the time is measured a little, it should be more consistent): fs-thread ram-thread fs-shared ram-shared 1 71877 54739 73986 61595 2 34949 26735 43719 28935 3 25581

Re: IndexSearcher and multi-threaded performance

I re-ran the no-readonly ram tests: thread shared 1 64043 53610 2 26999 25260 3 27173 17265 4 22205 13222 5 20795 11098 6 17593 9852 7 17163 8987 8 17275 9052 9 19392 10266 10 27809 10397 11 25987 10724

Re: IndexSearcher and multi-threaded performance

Nice results, thanks! The poor disk-based scaling may be fixed by NIOFSDirectory, if you are on Unix. If you are on Windows it won't help (and will likely be worse than FSDirectory), because of an apparently bug in Sun's JVM on Windows whereby NIO positional file reads seem to share a loc

Re: IndexSearcher and multi-threaded performance

And if you you are on unix and could try trunk and use the new NIOFSDirectory implementation...that would be awesome. Woah...that made 2.4 too. A 2.4 release will allow both optimizations. Many thanks! - To unsubscribe, e-m

Re: IndexSearcher and multi-threaded performance

Nice! An 8 core machine with a test ready to go! How about trying the read only mode that was added to 2.4 on your IndexReader? And if you you are on unix and could try trunk and use the new NIOFSDirectory implementation...that would be awesome. Those two additions are our current hope for

Re: IndexSearcher update

Yes you may do that as well... no updates are noted by the searcher until it (the searcher) is updated :) -- Anshum Gupta Naukri Labs! http://ai-cafe.blogspot.com The facts expressed here belong to everybody, the opinions to me. The distinction is yours to draw On Thu, Oct 16, 2008

Re: IndexSearcher update

thanks for your reply. and how about merge? if i searcher on index1, and in other thread, i try to merge index2 into index1 and i do not update searcher, can i continue searching on index1? thanks Mahdi On Thu, Oct 16, 2008 at 2:19 PM, Anshum <[EMAIL PROTECTED]> wrote: > Yes you can! :) > Very no

Re: IndexSearcher update

Yes you can! :) Very normally. -- Anshum Gupta Naukri Labs! http://ai-cafe.blogspot.com The facts expressed here belong to everybody, the opinions to me. The distinction is yours to draw On Thu, Oct 16, 2008 at 3:43 PM, mahdi yari <[EMAIL PROTECTED]> wrote: > hi dears > > i have a

Re: IndexSearcher thread safety

As Michael said, you can share it, and you should share it, this will improve performance and reuse the internal cache associated to the IndexSearcher (term cache, filters cache, etc). On Tue, Mar 11, 2008 at 7:31 AM, J B <[EMAIL PROTECTED]> wrote: > Hi, > > Are instances of IndexSearcher thread

Re: IndexSearcher thread safety

They are thread safe. You should share a single instance across multiple threads. Mike J B wrote: Hi, Are instances of IndexSearcher thread safe? In other words, should each thread have it's own instance of IndexSearcher, or could I share a single one between many threads, to avoid

Re: IndexSearcher and Multiple Threads

: Is IndexSearcher ThreadSafe? I made a simple httpserver using grizzly as ... : java.lang.NullPointerException : at org.apache.lucene.queryParser.QueryParser.jj_scan_token( ... : This error does not happen if I do searches one at a time. IndedSearcher is thread safe, QueryPar

Re: IndexSearcher and Multiple Threads

The IndexSearcher is thread-safe. The QueryParser is *not*. From the JavaDocs for QueryParser Note that QueryParser is *not* thread-safe. So I'd guess you're using a single QueryParser across multiple threads. Just use a new one each time, they're not expensive... Best Erick On Jan 28, 200

Re: IndexSearcher and RAMDirectory

17 jan 2008 kl. 16.42 skrev Cam Bazz: Hello, Hi, I understand after writing some documents in an index with an indexwriter, the IndexSearcher object has to be reinstantiated for it to find newly instantiated objects. that is correct, given you instantiate the new IndexSearcher(directory

Re: IndexSearcher cache

: initialized... I tried to create a seacher everytime but that lead me to : the Too-Many-Files-Open exception. So no matter what I do I face a show : stopper. were you closing the old searcher before opening the new one? even if that was the cause of your problem, i still wouldn't recomend reop

Re: IndexSearcher cache

My two cents: Lucene often offers the least common denominator...for example: out of the box, Lucene best handles either a single user / single thread experience or a mostly 'read only' experience. I believe that the main reason for this is that it serves the greatest variety uses. You can, a

Re: IndexSearcher cache

I agree those are benefits when you batch process the indexes once or once in a while. The beauty of AOP is that I can intercept writes and do change the index on the spot. At that point I'd need to let the search know or drop it. If I do that that will face issues on the search side since this

Re: IndexSearcher cache

Indeed, having to re-open a searcher/reader in order for searches to reflect index modification, can sometimes not best fit with the logic of a certain application. But see the features made possible with this design: (+) searches do not feel index modifications until desired. (++) no need to sync

Re: IndexSearcher cache

That part is self understood. However as I describe the problem initially - and the use case is a very practical way of dealing with documents in real live - they change, we edit them, I don't want to run a batch re-indexing thing every night... I just wanted done on the spot. One instance Index

Re: IndexSearcher cache

<1>. Every time you close/open a reader, you pay a significant penalty to warm up caches, etc. You may have to do some tricky dancing to coordinate among the sessions to be able to close/reopen the reader to allow updates to show up though. Erick On 3/5/07, Mohammad Norouzi <[EMAIL PROTECTED]>

Re: IndexSearcher cache

Hi Erick I am completely confused about this IndexReader. in my case, I have to keep the reader opened because of pagination of the result so I have to had a reader per session. the thing that baffled me is can only one reader service all the session at the same time? I mean 1- having one reader

Re: IndexSearcher cache

There was quite a long discussion thread on this topic relatively recently, try searching the archive for concurrence, perhaps IndexReader, etc. The short take-away is that you should share a single instance of the reader, since opening one is an expensive operation, and the first searches you pe

Re: IndexSearcher cache

Daniel, Thanks for replying. THe only reason I don't close my indexSearcher is that I got the "Too Many File Open Exception" and I decided to make my searcher static in the SearchService. If I do go and close then open a new one I may expose myself to some concurent access issues while people can

Re: IndexSearcher cache

MC Moisei wrote: Hi to all members of the user group! Let me get to my problem. I use Lucene in two different parts of the application. One is the SearchService and one is an AOP interceptor that intercepts any changes in the Searcheable entities. This last part is removing the document from the

Re: IndexSearcher on multi-core CPU machine

I don't know. But I'm curious about the results. 19 feb 2007 kl. 16.33 skrev dmitri: I haven't tried using several IndexSearchers over a single IndexReader. Do you think it can help? --- dmitri karl wettin-3 wrote: What are the effects if you supply the same reader to

Re: IndexSearcher on multi-core CPU machine

I haven't tried using several IndexSearchers over a single IndexReader. Do you think it can help? --- dmitri karl wettin-3 wrote: > > > What are the effects if you supply the same reader to IndexSearcher:s? > > 19 feb 2007 kl. 16.03 skrev dmitri: > >> >> I use >>

Re: IndexSearcher on multi-core CPU machine

I don't think so as sorting in on integer fields - dmitri Paul Smith-2 wrote: > > are you using Locale-sensitive sorting at all? > > https://issues.apache.org/jira/browse/LUCENE-806 > > Just wondering if you're seeing the same problem we are having. > > cheers, > > Paul Smith > >

Re: IndexSearcher on multi-core CPU machine

What are the effects if you supply the same reader to IndexSearcher:s? 19 feb 2007 kl. 16.03 skrev dmitri: I use - searcher = new IndexSearcher(indexLocation); - So readers are created under the hood. dmitri karl wettin-3 wrote: 18 feb 2007 kl. 22.52 skrev

Re: IndexSearcher on multi-core CPU machine

I use - searcher = new IndexSearcher(indexLocation); - So readers are created under the hood. dmitri karl wettin-3 wrote: > > > 18 feb 2007 kl. 22.52 skrev dmitri: > >> With org.apache.lucene.store.MMapDirectory throughput is better but >> I still >> have to

Re: IndexSearcher on multi-core CPU machine

18 feb 2007 kl. 22.52 skrev dmitri: With org.apache.lucene.store.MMapDirectory throughput is better but I still have to create multiple IndexSearcher instances to have 100% CPU utilization. With multiple IndexSearchers search times are better under multithreaded load. concurrent 1 s

Re: IndexSearcher on multi-core CPU machine

are you using Locale-sensitive sorting at all? https://issues.apache.org/jira/browse/LUCENE-806 Just wondering if you're seeing the same problem we are having. cheers, Paul Smith On 19/02/2007, at 8:52 AM, dmitri wrote: We have search (no update) web app on 2 dual core CPU machine (2x Du

Re: IndexSearcher executed concurrently

Oh, that is great! I didn't notice this javadoc. Maybe i need to update my lucene lib. I had thought one user requests his query, other queries maybe impact on the result since using a single IndexSearcher. Forget these mails. Thanks a lot.. On 9/5/06, karl wettin <[EMAIL PROTECTED]>

Re: IndexSearcher executed concurrently

On Tue, 2006-09-05 at 17:57 +0800, jacky wrote: > 1. I wander if concurrent users can get the right results with > different queries since the class has only one IndexSearcher instance. > > 2. As we know, a new IndexSearcher can be created when user request > his query. If first method gets the r

Re: Indexsearcher - one instance in PHP via javabridge?

Wow thanks, this is such a good answer that I wasn't expecting that much :-) It looks like it could resolve all my problems at once! Thanks a lot! Mike Chris Hostetter wrote: : I'm trying to follow these instructions, but I have zero experience with : Java, JVMs, Tomcat, etc. Could somebody h

Re: Indexsearcher - one instance in PHP via javabridge?

: I'm trying to follow these instructions, but I have zero experience with : Java, JVMs, Tomcat, etc. Could somebody help me with this one? Thanks in : advance! if you want to eliminate your need to write java code (or servlets) completely take a look at Solr ... it provides a webservicesish API

RE: IndexSearcher memory leak?

ent for RAMDirectory.close(), which I expect would be valued by others. -Original Message- From: Heng Mei [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 09:28 To: java-user@lucene.apache.org Subject: Re: IndexSearcher memory leak? Thanks for the helpful tip, it makes sense now. I had previou

Re: IndexSearcher memory leak?

nal Message- From: Heng Mei [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 06:32 To: java-user@lucene.apache.org Subject: Re: IndexSearcher memory leak? import org.apache.lucene.search.Searcher; import org.apache.lucene.search.IndexSearcher; import org.apache.lucene.search.*; import org.apache.l

RE: IndexSearcher memory leak?

earcher( ramdir ); } -Original Message- From: Heng Mei [mailto:[EMAIL PROTECTED] Sent: 06 July 2006 06:32 To: java-user@lucene.apache.org Subject: Re: IndexSearcher memory leak? import org.apache.lucene.search.Searcher; import org.apache.lucene.search.IndexSearcher; import org.apach

Re: IndexSearcher memory leak?

java-source or application/x-java) try including it inline in your email. : Date: Wed, 5 Jul 2006 21:50:35 -0700 : From: Heng Mei <[EMAIL PROTECTED]> : Reply-To: java-user@lucene.apache.org : To: java-user@lucene.apache.org : Subject: Re: IndexSearcher memory leak? : : Thanks for t

Re: IndexSearcher memory leak?

5 Jul 2006 21:50:35 -0700 : From: Heng Mei <[EMAIL PROTECTED]> : Reply-To: java-user@lucene.apache.org : To: java-user@lucene.apache.org : Subject: Re: IndexSearcher memory leak? : : Thanks for the fast response -- you're right, I had a typo in the code snippet. : : I've attach

Re: IndexSearcher memory leak?

Thanks for the fast response -- you're right, I had a typo in the code snippet. I've attached the test code that reproduces the OutOfMemoryException. The code is a simple main method that repeatedly opens/searches/closes an index using RAMDirectory. Maybe there's something I'm overlooking, but i

Re: IndexSearcher memory leak?

: I get an OutOfMemoryException after a few iterations of the following loop: : LOOP: : ramdir = new RAMDirectory( "path/to/my/directory" ); : searcher = new IndexSearcher( reader ); : searcher.search(new TermQuery( new Term( "field", "keyword"))); : searcher.close(); :

Re: IndexSearcher in Servlet

You have to re-init the searcher / reader object. You can re-init the reader object that the searcher uses, without re-initing the searcher object itself, as stated earlier here On Wed, 28 Jun 2006 14:23:21 +0200, heritrix.lucene <[EMAIL PROTECTED]> wrote: o o no I mean the searching wou

Re: IndexSearcher in Servlet

o o no I mean the searching would be fast or not... But now i have tested. The result that i found reveals that there would be no difference in terms of searching speed. But there is another thing that i want to ask. What if the index is changed in between. Will the indexReader give the results w

Re: IndexSearcher in Servlet

On Jun 28, 2006, at 6:53 AM, heritrix.lucene wrote: Is there any difference in terms of speed between IndexReader and IndexSearcher?? I'm assuming you mean is there any difference in speed in how you construct an IndexSearcher no. Erik On 6/27/06, Erik Hatcher <[EMAIL PRO

Re: IndexSearcher in Servlet

As far as i know, an IndexSearcher use an IndexReader.. Hence you can do searcher.getIndexReader().. even tho you instanciated the searcher with a string path or a directory. So, i would guess that by creating a searcher with an indexreader as parameter, the constructor will be faster. But,

Re: IndexSearcher in Servlet

Is there any difference in terms of speed between IndexReader and IndexSearcher?? On 6/27/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: On Jun 27, 2006, at 10:32 AM, Fabrice Robini wrote: > That's also my case... > I create a new IndexSearcher at each query, but with a static and > instanciate

Re: IndexSearcher in Servlet

ent. --Renaud - Original Message - From: "Erik Hatcher" <[EMAIL PROTECTED]> To: Sent: Tuesday, June 27, 2006 3:49 AM Subject: Re: IndexSearcher in Servlet On Jun 27, 2006, at 5:47 AM, Fabrice Robini wrote: What is your advice for webApplication ? It all depends

Re: IndexSearcher in Servlet

uot;Erik Hatcher" <[EMAIL PROTECTED]> To: Sent: Tuesday, June 27, 2006 3:49 AM Subject: Re: IndexSearcher in Servlet 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 Index

Re: IndexSearcher in Servlet

On Jun 27, 2006, at 10:32 AM, Fabrice Robini wrote: That's also my case... I create a new IndexSearcher at each query, but with a static and instanciated Directory. New IndexSearcher(myDirectory) It seems to be OK... am I wrong ? You may be "ok" given your query patterns, but you won't benef

Re: IndexSearcher in Servlet

static searcher. Of course you still have to manage the static reader. Am I wrong in my thinking here? Thanks, Michael Crump -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 6:49 AM To: java-user@lucene.apache.org Subject: Re: IndexSear

RE: IndexSearcher in Servlet

java-user@lucene.apache.org Subject: RE: IndexSearcher in Servlet Hello, I have another question along this line. One of the points made in this thread was to never create a new IndexSearcher for each query. Is this true even in the case that an IndexSearcher is being created with a static or c

Re: IndexSearcher in Servlet

Singleton pattern is better. Than you can extend it to proxy pattern. existing IndexReader really isn't that expensive and does get around - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL

RE: IndexSearcher in Servlet

e the static reader. Am I wrong in my thinking here? Thanks, Michael Crump -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 27, 2006 6:49 AM To: java-user@lucene.apache.org Subject: Re: IndexSearcher in Servlet On Jun 27, 2006, at 5:47 AM, Fabrice Robini

RE: IndexSearcher in Servlet

Tuesday, June 27, 2006 8:01 AM > To: java-user@lucene.apache.org > Subject: RE: IndexSearcher in Servlet > > > Erik, > > Thank you for your reply. > I'm goingto use the static IndexSearcher in my Servlet (my > index is static). > > Thanks :-) > &g

RE: IndexSearcher in Servlet

Erik, Thank you for your reply. I'm goingto use the static IndexSearcher in my Servlet (my index is static). Thanks :-) -Original Message- From: Erik Hatcher [mailto:[EMAIL PROTECTED] Sent: mardi 27 juin 2006 12:49 To: java-user@lucene.apache.org Subject: Re: IndexSearcher in Se

Re: IndexSearcher in Servlet

[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. T

Re: IndexSearcher in Servlet

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:

RE: IndexSearcher in Servlet

: 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

Re: IndexSearcher in Servlet

ead 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

Re: IndexSearcher in Servlet

ou 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

RE: IndexSearcher in Servlet

e.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 ind

RE: IndexSearcher in Servlet

ROTECTED] Sent: mardi 27 juin 2006 10:58 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 no

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 que

Re: IndexSearcher and IndexWriter in conjuction

: The trick is that once segment files are written, they are never : modified (except for the "segments" file itself). New documents are : added to new segments, not existing segments. When segments are : merged, a new bigger segment is created. This way, the view of the : index for a specific

Re: IndexSearcher and IndexWriter in conjuction

On 3/13/06, Nikhil Goel <[EMAIL PROTECTED]> wrote: > Can someone please explain how does IndexSearcher and IndexWriter works in > conjuction. The trick is that once segment files are written, they are never modified (except for the "segments" file itself). New documents are added to new segments,

Re: IndexSearcher and IndexWriter in conjuction

Hi Patrick, thanks for writing back but my question is:- do we really need to write something new to achieve what I want to achieve. By going thru Lucene Tutorials, i dont think there is a need to do such a thing:- http://blog.danbartels.com/archive/2004/09/09/186.aspx Indexing and searching are

Re: IndexSearcher and IndexWriter in conjuction

Hi Nikhil We are using the index accessor contribution. For more information see: http://www.nabble.com/Fwd%3A-Contribution%3A-LuceneIndexAccessor-t17416.html#a47049 This should help you to co-ordinate the IndexSearcher and IndexWriter. Patrick On 13/03/06, Nikhil Goel <[EMAIL PROTECTED]> wrote:

  1   2   >