As stated many times, it is SIGNIFICANT if using RAMdirectories to hold
entire indexes. If not, then it is not such a big deal.
Rather than using FixedThreadLocal, a more involved solution using a runtime
property to determine which thread local impl to use is possible. In lieu of
that, RAMDirecto
I think more detail is in needed.
-Original Message-
From: Krishnan, Ananda [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 11, 2006 10:46 PM
To: java-dev@lucene.apache.org
Cc: [EMAIL PROTECTED]
Subject: RE: Lucene Index comparison..
Hi
i will explain about my problem a bit more in detail
Krishnan, Ananda wrote:
> i will explain about my problem a bit more in detail. Every night at
> a particular time indexing will be happen. I have to find out any
> new urls or any files have been added in the new index so that i
> have to send an alert to the customer.
> I know about sending ale
On Tue, 2006-05-09 at 13:21 -0400, Yonik Seeley wrote:
> > Did anybody know what needs to be synchronized and what
> > does not need to
> > be synchronized?
>
> Needs to be considered on a case-by-case basis IMO.
>
> > Should I summarize the uses and post it here for
> > discussion?
> Sure!
He
[ http://issues.apache.org/jira/browse/LUCENE-564?page=all ]
Otis Gospodnetic resolved LUCENE-564:
-
Resolution: Fixed
Applied, thanks.
> Class DisjunctionSumScorer does not need to be public.
> --
hmm. So what you're saying is that there is a "memory leak", but very
very noticeable with large RAMDirectories (like what we have)...
With a 5M directories, it seems to be leaking atleast 5M per hour,
depending on queries.. even on our 1500M VM they run our of memory over
24 hours.
So I gu
With a copy to java-dev, I suppose none you mind...
On Friday 12 May 2006 19:40, Yonik Seeley wrote:
> On 5/12/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
> > Yonik Seeley wrote:
> > > So the first step is to decide if we should migrate to this, and if
> > > so, where it belongs.
> > > - lucene.ut
With a copy to java-dev, I suppose none you mind...
On Friday 12 May 2006 19:40, Yonik Seeley wrote:
> On 5/12/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
> > Yonik Seeley wrote:
> > > So the first step is to decide if we should migrate to this, and if
> > > so, where it belongs.
> > > - lucene.ut
There is no "memory leak" per se - just the propensity to use more memory
than would seem to be needed (based on index size).
Using the FixedThreadLocal along with the modified TermInfosReader (that
uses it), the memory problem is resolved. If you are not seeing that, then
you have some other memo
I finally got around to making the NioFSDirectory with caching 1.9
compliant. I also produced a performance test case.
Below is the results on my machine:
read random = 586391
read same = 68578
nio read random = 72766
nio max mem = 203292672
nio memory = 102453248
nio hits = 14974713
nio misses =
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man updated LUCENE-557:
Attachment: LUCENE-557-BooleanQuery-explain-fix.patch
Some fixes to BooleanQuery to make BooleanWeight.explain work correctly in more
cases: specifically when minNrSho
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man updated LUCENE-557:
Attachment: LUCENE-557-FilteredQuery-explain-fix.patch
Patch of FilteredQuery that returns a correct Explanation in negative cases
where the document does not pass the
Is there also a nextSetBit(bitNr) somewhere on http://www.hackersdelight.org ?
This method is essential for filtering a query search.
They have some algorithms for ntz (number of trailing zeros) for a
single int value. That's the harder part. Using ntz to implement
nextSetBit in an int or arra
Oh, and the performance for nextSetBit() was 46% faster (at least on
my box at home, which I developed on, and hence this stuff is tuned
for).
-Yonik
On 5/12/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> Is there also a nextSetBit(bitNr) somewhere on http://www.hackersdelight.org ?
> This metho
Code is here for those interested:
http://issues.apache.org/jira/browse/SOLR-15
-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional comman
This produces a "term out of order" exception:
doc.add(new Field("", "", Field.Store.YES, Field.Index.UN_TOKENIZED));
As the exception is quite confusing we should probably catch it earlier,
providing a better message. But would it be okay to disallow all empty
field names? If not, I'd at leas
I'm curious: does the exception only occur if both the field and the value
are empty? ... are the Field.Store and Field.Index options you listed
neccessary for this condition as well?
Is it clear why this situation causes the exception?
(I don't have any obejction to rejecting blank field names
On Freitag 12 Mai 2006 23:41, Chris Hostetter wrote:
> I'm curious: does the exception only occur if both the field and the
> value are empty?
Yes, and the field needs to be untokenized. Store doesn't matter.
> Is it clear why this situation causes the exception?
I haven't thought about that...
ntz8 or ntz8a could possibly be faster than what I have now for low
density bit sets:
http://www.hackersdelight.org/HDcode/ntz.cc
I don't know how to expand those to 64 bit, but they could always be
used on the two 32 bit chunks I guess. Anyway, for higher density bit
sets, my current implementa
On Fri, 2006-05-12 at 16:01 +0200, karl wettin wrote:
> > Needs to be considered on a case-by-case basis IMO.
> >
> > > Should I summarize the uses and post it here for
> > > discussion?
In lack of other the view from someone that actually knows for sure,
here are my comments.
> StandardTokeniz
NearSpans
-
Key: LUCENE-569
URL: http://issues.apache.org/jira/browse/LUCENE-569
Project: Lucene - Java
Type: Bug
Components: Search
Reporter: Hoss Man
NearSpans appears to have a bug in skipTo that causes it to skip over some
matching documents c
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
Hoss Man updated LUCENE-569:
Attachment: TestNearSpans.java
test case using NearSpans directly that demonstrates bug.
> NearSpans
> -
>
> Key: LUCENE-569
> URL: http://i
[ http://issues.apache.org/jira/browse/LUCENE-569?page=all ]
Hoss Man updated LUCENE-569:
Summary: NearSpans skipTo bug (was: NearSpans)
fixed title
> NearSpans skipTo bug
>
>
> Key: LUCENE-569
> URL: http://issues.ap
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man updated LUCENE-557:
Attachment: LUCENE-557-SpanScorer-explain-HACK-fix.patch
HACK work arround for making SpanScorer.explain work in spite of NearSpan bug.
Fixes all existing known SpanQ
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man reassigned LUCENE-557:
---
Assign To: Hoss Man
Status Update:
The patches so far fix all of the known issues that don't involve a Scorer
"matching" a document with a score of 0.0 ... the
25 matches
Mail list logo
