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
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 <luc...@mikemccandless.com>
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?
On Wed, Oct 12, 2016 at 10:56 PM, Trejkaz <trej...@trypticon.org> wrote:
> On Thu, Oct 13, 2016 at 6:32 AM, Michael McCandless
> <luc...@mikemccandless.com> 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
> 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!)
> To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-user-h...@lucene.apache.org
___ Watch an eGain Customer Service
Transformation<https://www.youtube.com/watch?v=dEwdFfWoyuE> Success Story