lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Chandwani <>
Subject Re: Default LRUQueryCache causing OOO exception
Date Fri, 14 Oct 2016 06:41:42 GMT
Thanks Adrien, Micheal, Trejkaz.

You guys were right.

I was concentrating my energy at wrong place.

We have two types of indexes:

1. File based directory: which we use for text search. Here we make use of searcher manager.

2. In memory directory: which we use for auto complete/auto suggestion. Here no searcher manager
is used, we open new reader/searcher for every request. Same were not closed after use.

Issue is resolved now.



From: Michael McCandless <>
Sent: Thursday, October 13, 2016 2:38:46 PM
To: Lucene Users
Cc: Rahul Chandwani
Subject: Re: Default LRUQueryCache causing OOO exception

These sounds like good ideas Trejkaz ... maybe open an issue and make
a starting patch so we can iterate?

I agree a try-w-resources solution, and/or a lambda solution, could be better.

Did you already share how you got it working for multiple indices?

Mike McCandless

On Wed, Oct 12, 2016 at 10:56 PM, Trejkaz <> wrote:
> On Thu, Oct 13, 2016 at 6:32 AM, Michael McCandless
> <> wrote:
>> You must be calling SearcherManager.maybeRefresh periodically, which
>> does open new NRT readers.
>> Can you please triple check that you do in fact always release() after
>> an acquire(), in a finally clause?
> For what it's worth, I found this API particularly hard to use.
> 1. I would prefer a withReader(Callback) kind of method to separate
> methods to acquire and release. It makes it impossible to forget to
> call the release method and now that lambdas are in the language, it
> looks a hell of a lot tidier than try-finally.
> 2. If there has to be some kind of cleanup I'm supposed to perform on
> an object, I prefer that to be done in close() so that I can use
> try-with-resources like with any other object that I'm expected to
> close.
>   2b. The API design is doubly bad, because the object it returns
> *does* have a close() method, but "no, you're not allowed to call
> that, you have to use this other method over here which almost every
> developer on the team will get wrong every single time".
> 3. I wish there had been a version which could keep track of the same
> stuff for multiple indexes, since getting that to work reliably has
> been nearly impossible. (I think we're there right now, but I have no
> way to prove it!)
> TX
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
___ Watch an eGain Customer Service Transformation<>
Success Story

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message