The only hesitation I have is SOLR-342, where the o.p. is still seeing
the original issue:
https://issues.apache.org/jira/browse/SOLR-342
I'm hoping he responds today to my last 2 comments, and then we can
iterate from there. But I'm not sure how long that will take to reach
closure.
Mike
I'm chasing down a bug in my application where multiple threads were readingand
caching the same filter (same very common term, big index) and causedan Out of
Memory exception when I would expect there to be plenty ofmemory to spare.
There's a number of layers to this app to investigate (I was us
Even though you only have two threads... how many different
IndexReader instances do you have?
Also, if they are opened/closed/released, and you are running at 100
% cpu, you may be running into a finalization problem - the instances/
references cannot be GC'd due to finalization, thus the O
I think this code has been discussed before, but I can't find
the occasion on which that happened.
Actually, this code may do some things like creating two different
caches, and as you said calling filter.bits(reader) in parallel.
Creating different caches does not hurt because in the end
one onl
>>Even though you only have two threads... how many different IndexReader
>>instances do you have?
One reader - kept open throughout.
>>I think the only way to make the current version
>>work correctly is to make whole method synchronized on this
>>object, i.e. declare it as public synchronized
In his example though, he states there are only two threads, and that
even with two being created, he should have plenty of memory to spare
(if I am reading it correctly).
On Feb 18, 2008, at 9:23 AM, Paul Elschot wrote:
I think this code has been discussed before, but I can't find
the occa
Op Monday 18 February 2008 17:08:50 schreef mark harwood:
> >>Even though you only have two threads... how many different IndexReader
> >>instances do you have?
>
> One reader - kept open throughout.
>
> >>I think the only way to make the current version
> >>work correctly is to make whole meth
>>But I'm afraid more detailed information will be needed before this OOM can
>>be solved.
I can't see a likely explanation for my particular issue in
CachingWrapperFilter but, as a separate issue, it looks to have this potential
inefficiency (parallel loading/ attempted caching of the same dat
Token reuse is not ideal for avoiding array copies
--
Key: LUCENE-1181
URL: https://issues.apache.org/jira/browse/LUCENE-1181
Project: Lucene - Java
Issue Type: Improvement
Components
[
https://issues.apache.org/jira/browse/LUCENE-1003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Lihachev updated LUCENE-1003:
Attachment: TestRussianAnalyzer.java.patch
Patch that adds new test to the TestRussianAna
10 matches
Mail list logo
