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. Thanks Rahul ________________________________ 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? Mike McCandless http://blog.mikemccandless.com 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 > 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: 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
