On Thu, Oct 13, 2016 at 5:04 AM, Mikhail Khludnev wrote:
> Hello,
> Why not "To:local.one -(To:[* TO local.one} To:{local.one TO *)" ?
That would not match example 2:
> 2. To:other.one, third.one,
This alone would match 1 and 2, but not 3:
To:[* TO local.one} OR To:{local.one TO *)
Except
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 fou
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?
You have far far too many CompressingStoredFieldsReader instances in your JVM.
Mike McCandless
Hello,
Why not "To:local.one -(To:[* TO local.one} To:{local.one TO *)" ?
On Wed, Oct 12, 2016 at 7:59 PM, Valentin Popov
wrote:
> Hi all,
>
> I broke my mind to figure out one search problem. I have a field «To» that
> store domains. Like example To:local.one, other.one, third.one. I have a
> s
Hi all,
I broke my mind to figure out one search problem. I have a field «To» that
store domains. Like example To:local.one, other.one, third.one. I have a set of
a domain’s that are local, in this example it is «local.one», and set of non
local domains are infinitive. I need to search all doc
We do not create readers on our own, that part is done/managed by searcher
manager. Not sure if they are garbage collected.
What do you mean by indices ?
No, we are not using NoMergePolicy. Default merge policy is used.
Thanks
Rahul
From: Adrien Grand
Sent:
After readers are released, are they also free to be garbage collected or
is something holding references to them?
How many indices do you have? Are you using something like the
NoMergePolicy?
Le mer. 12 oct. 2016 à 16:35, Rahul Chandwani a
écrit :
> Hi Adrien,
>
> Every acquire() call is follow
Hi Adrien,
Every acquire() call is followed by release() call.
From: Adrien Grand
Sent: Wednesday, October 12, 2016 7:55:58 PM
To: Rahul Chandwani; java-user@lucene.apache.org
Subject: Re: Default LRUQueryCache causing OOO exception
Hi Rahul,
The most likely ca
Hi Rahul,
The most likely cause to your problem is that your are leaking IndexReader
instances. You say you are using SearcherManager, could you check that
there is a call to release matching every call to acquire?
Le mer. 12 oct. 2016 à 15:02, Rahul Chandwani a
écrit :
> Hi Adrien,
>
> Total n
Hi Adrien,
Total number of instances of CompressingStoredFieldsReader = 76,808 occupying
760 MB heap.
Total number of instances of SegmentCoreReaders = 38,099 occupying 368 MB heap.
Thanks
-Original Message-
From: Adrien Grand [mailto:jpou...@gmail.com]
Sent: Wednesday, October 12, 20
Hi Rahul,
High memory from both these classes is unexpected. I am wondering that
maybe your application does not close index readers when it doesn't need
them anymore? Another possibility would be that you are dealing with lots
of IndexReader instances in the same JVM. Are you able to count how ma
Hello,
We are using lucene 5.5.2 for search .
We are getting out of memory exception as default LRUQueryCache is occupying
more much more than default 32 MB memory.
Searcher Manager is used here to get an instance of index searcher to perform
search. Default lru query cache and default query
12 matches
Mail list logo
