lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Default LRUQueryCache causing OOO exception
Date Fri, 14 Oct 2016 10:04:05 GMT
Thank you for bringing closure!

Mike McCandless

http://blog.mikemccandless.com


On Fri, Oct 14, 2016 at 2:41 AM, Rahul Chandwani <rchandwani@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 <lucene@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 <trejkaz@trypticon.org> wrote:
>> On Thu, Oct 13, 2016 at 6:32 AM, Michael McCandless
>> <lucene@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>
> ___ Watch an eGain Customer Service Transformation<https://www.youtube.com/watch?v=dEwdFfWoyuE>
Success Story

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message