On Mon, Feb 20, 2012 at 12:07 PM, Uwe Schindler wrote:
> See my response. The problem is not in Lucene; its in general a problem of
> fixed
> thread pools that execute other callables from within a callable running at
> the
> moment in the same thread pool. Callables are simply waiting for each
A long-running program of mine (which Uwe's read a model of) slowly
keeps adding merge threads. I count 22 at the moment. Each one shows
up, runs for a bit, and then goes to sleep for, seemingly ever. I
don't do anything explicit to control merging behavior.
They name themselves "Lucene Merge Thre
On Sun, Feb 19, 2012 at 8:07 PM, Uwe Schindler wrote:
> See my response. The problem is not in Lucene; its in general a problem of
> fixed thread pools that execute other callables from within a callable
> running at the moment in the same thread pool. Callables are simply waiting
> for each ot
See my response. The problem is not in Lucene; its in general a problem of
fixed thread pools that execute other callables from within a callable running
at the moment in the same thread pool. Callables are simply waiting for each
other.
Use a separate thread pool for Lucene (or whenever you ex
See https://issues.apache.org/jira/browse/LUCENE-3803 for an example
of the hang. I think this nets out to pilot error, but maybe Javadoc
could protect the next person from making the same mistake.
-
To unsubscribe, e-mail: java-u
Conveniently, all the 'wrong-result' problems disappeared when I
followed your advice about counting hits.
On Sun, Feb 19, 2012 at 10:39 AM, Robert Muir wrote:
> On Sun, Feb 19, 2012 at 9:08 AM, Benson Margulies
> wrote:
>> 3.5.0: I passed a fixed size executor service with one thread, and
>>
Hello,
I am really new to Lucene, last week through this list i was really
successfull into finding a solution to my problem.
I have a new question now, i am trying to implement a new similarity
class that uses the Jaccard coefficient, i have been reading the
javadocs and a lot of other webpage
and there was a dumb typo.
1 thread: hang
2 threads: hang
3 or more: no hang
On Feb 19, 2012, at 10:40 AM, Robert Muir wrote:
> On Sun, Feb 19, 2012 at 9:08 AM, Benson Margulies
> wrote:
>> 3.5.0: I passed a fixed size executor service with one thread, and
>> then with two threads, to the In
I should have been clearer; the hang I can make into a test case but I
wondered if is would just get closed as 'works as designed'. the
result discrepancy needs some investigation, I should not have
mentioned it yet.
On Feb 19, 2012, at 10:40 AM, Robert Muir wrote:
> On Sun, Feb 19, 2012 at 9:08
On Sun, Feb 19, 2012 at 9:08 AM, Benson Margulies wrote:
> 3.5.0: I passed a fixed size executor service with one thread, and
> then with two threads, to the IndexSearcher constructor.
>
> It hung.
>
> With three threads, it didn't work, but I got different results than
> when I don't pass in an
On Sun, Feb 19, 2012 at 10:23 AM, Benson Margulies
wrote:
> thanks, that's what I needed.
>
Thanks for bringing this up, I think its a common issue, I created
https://issues.apache.org/jira/browse/LUCENE-3799 to hopefully improve
the docs situation.
--
lucidimagination.com
thanks, that's what I needed.
On Feb 19, 2012, at 9:51 AM, Robert Muir wrote:
> On Sun, Feb 19, 2012 at 9:21 AM, Benson Margulies
> wrote:
>> If I have a lot of segments, and an executor service in my searcher,
>> the following runs out of memory instantly, building giant heaps. Is
>> there an
By passing Integer.MAX_VALUE you are requesting Lucene to allocate a priority
queue for collecting results with that size, this OOMs. With Lucene if you are
using TopDocs, the idea is to only get a limited amount of Top-Ranking
documents to display search results. The user is not interested in t
On Sun, Feb 19, 2012 at 9:21 AM, Benson Margulies wrote:
> If I have a lot of segments, and an executor service in my searcher,
> the following runs out of memory instantly, building giant heaps. Is
> there another way to express this? Should I file a JIRA that the
> parallel code should have some
If I have a lot of segments, and an executor service in my searcher,
the following runs out of memory instantly, building giant heaps. Is
there another way to express this? Should I file a JIRA that the
parallel code should have some graceful behavior?
int longestMentionFreq = searcher.search(long
3.5.0: I passed a fixed size executor service with one thread, and
then with two threads, to the IndexSearcher constructor.
It hung.
With three threads, it didn't work, but I got different results than
when I don't pass in an executor service at all.
Is this expected? Should the javadoc say som
you can delete by query like -category:category1
On Sun, Feb 19, 2012 at 9:41 PM, Li Li wrote:
> I think you could do as follows. taking splitting it to 3 indexes for
> example.
> you can copy the index 3 times.
> for copy 1
> for(int i=0;i reader1.delete(i);
> }
> for copy
> for(in
I think you could do as follows. taking splitting it to 3 indexes for
example.
you can copy the index 3 times.
for copy 1
for(int i=0;i
Sounds like a nice machine!
It's frustrating that RAMFile even has any sync'd methods... Lucene is write
once, so once a RAMFile is written we don't need any sync to read it. Maybe on
creating a RAMInputStream we could make a new ReadOnlyRAMFile, holding the same
buffers without sync.
That sa
19 matches
Mail list logo
