I hacked up the test a bit so it would compile against 9.0 and confirmed
the problem existed there as well.
So going back a little farther with some manual bisection (to account for
the transition from ant to gradle) lead me to the following...
# first bad commit: [2719cf6630eb2bd7cb37d0e8462
With some trial and error I realized two things...
1) the order of the terms in the BooleanQuery seems to matter
- but in terms of their "natural order", not the order in the doc
(which is why i was so confused trying to reproduce it)
2) the problem happens when using termVectors but
I've got a user getting java.lang.IndexOutOfBoundsException from the
UnifiedHighlighter in Solr 9.1.0 w/Lucene 9.3.0
(And FWIW, this same data, w/same configs, in 8.11.1, purportedtly didn't
have this problem)
I don't really understand the highlighter code very well, but AFAICT:
- Defaul
On Monday 30 November 2009 18:51:34 Nick Burch wrote:
> On Mon, Nov 30, 2009 at 12:22 PM, Stefan Trcek
wrote:
> > I'd do, but was not successful to get the svn repo some months ago.
> > I have to claim the sys admin for any svn repo to open a door
> > through the firewall. Gave up due to
> >
> >
OK I committed this, plus further removes of "expert" from TopDocs, to
trunk (future 3.1), 2.9 and 3.0 branches.
Thanks!
Mike
On Tue, Dec 1, 2009 at 5:31 AM, Stefan Trcek wrote:
> On Tuesday 01 December 2009 11:07:41 Michael McCandless wrote:
>> OK -- none of IndexSearcher's search methods need
Super, thanks. I'll commit your patch, fixing javadocs for
TopDocs/TopFieldDocs.
Mike
On Tue, Dec 1, 2009 at 5:31 AM, Stefan Trcek wrote:
> On Tuesday 01 December 2009 11:07:41 Michael McCandless wrote:
>> OK -- none of IndexSearcher's search methods needed tweaking? Just
>> TopDocs/TopFieldDo
On Tuesday 01 December 2009 11:07:41 Michael McCandless wrote:
> OK -- none of IndexSearcher's search methods needed tweaking? Just
> TopDocs/TopFieldDocs?
Yes, you can use these methods in Searcher, they are sufficient:
TopDocs Searcher.search(Query query, Filter filter, int n)
TopFieldDocs Sea
OK -- none of IndexSearcher's search methods needed tweaking? Just
TopDocs/TopFieldDocs?
Mike
On Tue, Dec 1, 2009 at 4:52 AM, Stefan Trcek wrote:
> On Monday 30 November 2009 18:42:50 Michael McCandless wrote:
>> I was able to apply that git patch just fine -- so I think it'll
>> work?
>
> Good
On Monday 30 November 2009 18:42:50 Michael McCandless wrote:
> I was able to apply that git patch just fine -- so I think it'll
> work?
Good to hear it works that simple.
This patch completes the task.
It is a "two file" patch, so if this will work too, I'm confident.
Stefan
> On Mon, Nov 30, 2
On Mon, Nov 30, 2009 at 12:22 PM, Stefan Trcek wrote:
I'd do, but was not successful to get the svn repo some months ago. I
have to claim the sys admin for any svn repo to open a door through the
firewall. Gave up due to
$ nmap -p3690 svn.apache.org
PORT STATE SERVICE
3690/tcp fi
I was able to apply that git patch just fine -- so I think it'll work?
Thanks!
Mike
On Mon, Nov 30, 2009 at 12:22 PM, Stefan Trcek wrote:
> On Monday 30 November 2009 14:24:20 Michael McCandless wrote:
>> I agree, it's silly we label things like TopDocs/TopFieldDocs as
>> expert -- they are no
On Monday 30 November 2009 14:24:20 Michael McCandless wrote:
> I agree, it's silly we label things like TopDocs/TopFieldDocs as
> expert -- they are no longer for "low level" APIs (or, perhaps since
> we've removed the "high level" API (= Hits), what remains should no
> longer be considered low le
I agree, it's silly we label things like TopDocs/TopFieldDocs as
expert -- they are no longer for "low level" APIs (or, perhaps since
we've removed the "high level" API (= Hits), what remains should no
longer be considered low level).
Do you wanna cough up a patch to correct these?
Mike
On Mon,
On Friday 27 November 2009 14:49:07 Michael McCandless wrote:
> So the "don't care" equivalent here is to use IndexSearcher's normal
> search APIs (ie, we don't use Version to switch this on or off).
Hmm - Searcher/IndexSearchers search methods are "Low
level", "Expert", "Expert + low level" or r
On Friday 27 November 2009 14:49:07 Michael McCandless wrote:
>
> So the "don't care" equivalent here is to use IndexSearcher's normal
> search APIs (ie, we don't use Version to switch this on or off).
Thanks for the hint. For an unknown reason I once fell into
the "search(query, filter, collecto
On Fri, Nov 27, 2009 at 8:13 AM, Stefan Trcek wrote:
> On Friday 27 November 2009 12:07:07 Michael McCandless wrote:
>> Re: What does "out of order" mean?
>>
>> It refers to the order in which the docIDs are delivered to your
>> Collector.
>>
>> &
On Friday 27 November 2009 12:07:07 Michael McCandless wrote:
> Re: What does "out of order" mean?
>
> It refers to the order in which the docIDs are delivered to your
> Collector.
>
> "Normally" they are always delivered in increasing order.
>
> However
Ds to your collector out of order. In this case, docs are
processed in batches (chunks of 1024 docIDs at once), and within a
batch you may receive docIDs out of order.
Many collectors don't mind getting docIDs out of order, and so it's
important to return "true" from your acceptDocsO
Hi,
The documentation of org.apache.lucene.search.Collector uses the obscure
term "out of order". What does "order" mean? The natural order of
document IDs, a scoring order, or some other order?
--
Cheers,
Alex
> (i'm all thumbs when it comes to index internals and the file formats, but
> > i'm just tossig it out there as an idea)
> >
> >
> >
> > -Hoss
> >
> >
> > -
> >
, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/out-of-order-tf4276385.html#a12187972
Sent from the Lucene - Java Users mailing list archive at Nabble.com.
-
: After you close that IndexWriter, can you list the files in your
: directory (that's a RAMDirectory right?)? Something like this:
The OP said this was a fairly small RAMDirectory index right? would it be
worth while to just write the whole thing to disk and post it onlin so
people could see ev
> > Closing/
> > opening writers at different times? Any changes to the default parameters
> > (mergeFactor, maxBufferedDocs, etc.)?
> >
> > Mike
> >
> > "testn" <[EMAIL PROTECTED]> wrote:
> >>
> >> Here you go
> &
etc.)?
>
> Mike
>
> "testn" <[EMAIL PROTECTED]> wrote:
>>
>> Here you go
>>
>> -> Error during the indexing : docs out of order (0 <= 0 )
>> org.apache.lucene.index.CorruptIndexException: docs out of order (0 <=
this RAMDirectory? Closing/
opening writers at different times? Any changes to the default parameters
(mergeFactor, maxBufferedDocs, etc.)?
Mike
"testn" <[EMAIL PROTECTED]> wrote:
>
> Here you go
>
> -> Error during the index
Here you go
-> Error during the indexing : docs out of order (0 <= 0 )
org.apache.lucene.index.CorruptIndexException: docs out of order (0 <= 0 )
at
org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:368)
t happens, I will try to capture
> the stacktrace.
>
>
>
> Michael McCandless-2 wrote:
> >
> >
> > "testn" <[EMAIL PROTECTED]> wrote:
> >>
> >> Using Lucene 2.2.0, I still sporadically got doc out of order error. I
> >
in theory lead to
> this too.
>
> Are you able to easily reproduce it? Can you post the full exception?
>
> Mike
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail:
"testn" <[EMAIL PROTECTED]> wrote:
>
> Using Lucene 2.2.0, I still sporadically got doc out of order error. I
> indexed all of my stuff in one thread. Do you have any idea why it
> happens?
Hm, that is not good. I thought we had finally fixed this with
LUCENE-14
Using Lucene 2.2.0, I still sporadically got doc out of order error. I
indexed all of my stuff in one thread. Do you have any idea why it happens?
Thanks!
--
View this message in context:
http://www.nabble.com/out-of-order-tf4276385.html#a12172277
Sent from the Lucene - Java Users mailing list
Hi all,
I would like to draw your attention to an open and rather devious
long-standing index corruption issue that we've only now finally
gotten to the bottom of:
https://issues.apache.org/jira/browse/LUCENE-140
If you hit this, you will typically see a "docs ou
We get this when trying to optimize index:
Exception in thread "main" java.io.IOException: term out of order
at org.apache.lucene.index.TermInfosWriter.add(TermInfosWriter.java:95)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerger.ja
You could implement your own HitCollector interface and remove lower
scoring duplicates as you come across them by using a Map or something
to keep track as you go.
Ken Kinder wrote:
I've poked around on google and the archives quite a bite, but I can't
find exactly what I need. Say I have a q
I've poked around on google and the archives quite a bite, but I can't
find exactly what I need. Say I have a query that would normally
return a set of documents:
1 002 (text...)
2 001 (text...)
3 001 (text...)
4 002 (text...)
5 004 (text...)
I'd like that modified to be:
1 002 (text...)
2 001
I ve just get a "docs out of order".
I have a database that is indexed everytime an update occurs. The
index was ok for the last 3 weeks, and now, after the system throwed
an exception because of a write lock that was not released (and I
deleted it) I am recebing this:
Can anyone
out this in the faq or the archives that I
looked at.
java.io.IOException: term out of order
at org.apache.lucene.index.TermInfosWriter.add(TermInfosWriter.java:93)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerger.java:
can't get the error to occur. For me this is occuring via
IndexWriter.close(), however:
java.lang.IllegalStateException: docs out of order
at
org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:353)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerge
Writers, either.
java.lang.IllegalStateException: docs out of order
at
org.apache.lucene.index.SegmentMerger.appendPostings(SegmentMerger.java:
353)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfo(SegmentMerger.java:
316)
at
org.apache.lucene.index.SegmentMerger.mergeTermInfos(SegmentMerger.
aders is closed, we
assign
a new MultiReader to the variable holding it.
So, the problem is that randomly, but oftenly, when we are doing a close
on the
IndexWriter (after adding a document), we get an "docs out of order"
exception.
Problem seems to be with some SegmentMergeInfos in
39 matches
Mail list logo
