Another option would be to only re-open your searcher when actually needed, that is after the index has changed. This only does you some good when you have some hope that there are sizable gaps in your modifications....
Another possibility is to relax the "immediately" constraint. Would a maximum of 10 minutes really be unacceptable? That would allow you to open up a new Reader every 10 minutes, warm it up in the background and then switch. This works if you can say something to your product manager like "give me a 10 minute delay and people will get significantly faster results". If that's unacceptable, you can *still* open up a new reader in the background and warm it up before using it. "immediately" then becomes 5-10 seconds or so. Best Erick On 5/24/07, Simon Wistow <[EMAIL PROTECTED]> wrote:
I've built a Lucene system that gets rapidly updated - documents are supposed to be searchable immeidately after they've been indexed. As such I have a Writer that puts new index, update and delete tasks into a queue and then has a thread which consumes them and applies them to the index using one instance of an IndexModifier. So far so good. However every new Search opens up a new IndexSearcher in order to make sure that it gets new documents. The docs indicate is a big performance penalty. Are there any tips or tricks I can use to mitigate this? thanks, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
