Thank you for bringing closure! Mike McCandless
http://blog.mikemccandless.com On Fri, Oct 14, 2016 at 2:41 AM, Rahul Chandwani <rchandw...@egain.com> wrote: > 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 --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
