After using latest Solr tip I now get errors in Lucene during post-optimize
callbacks that scan the index.
java.lang.IndexOutOfBoundsException: Index: 24, Size: 0
at java.util.ArrayList.RangeCheck(ArrayList.java:547)
at java.util.ArrayList.get(ArrayList.java:322)
at
This is with an optimized index. If I copy it back into the index dir, Solr
opens it up fine and searches it. But the code opening and scanning via
Lucene fails on the same data.
jayson.minard wrote:
After using latest Solr tip I now get errors in Lucene during
post-optimize callbacks
Code used is this:
Directory directory = new FSDirectory(new File(luceneIndexDir), null);
reader = IndexReader.open(directory, true); // open directory read-only
...
reader.document(curDoc++, FIELD_SELECTOR);
...
and it bombs on the document() call.
jayson.minard wrote
Since Yonik answered over on the Lucene side, continuing this there:
http://www.nabble.com/Getting-errors-reading-lucene-indexes-using-recent-lucene-from-Solr-td23545868.html#a23546172
jayson.minard wrote:
Code used is this:
Directory directory = new FSDirectory(new File(luceneIndexDir
How risky was this change? I need to take a build out to test with some of
my patches that are near the tip and I am looking for a reasonable last
point and most of the builds this month have been ok for me and then this
popped into the commit list.
Any thoughts? Where does Lucene 2.9 put the
,
right? This could be a problem for index replication. (Incidentally,
I'm rather unfamiliar with the new java-based replication design.
Anyone care to comment on the implications?)
cheers,
-MIke
On 10-May-09, at 10:54 AM, jayson.minard wrote:
Mike,
I revamped
Does every thread really need to notify the update handler of the commit
interval/threshold being reached, or really just the first thread that
notices should send the signal, or better yet a background commit watching
thread so that no foreground thread has to pay attention at all. That is
We are using Solr from SVN Rev 745179
And now see this problem:
https://issues.apache.org/jira/browse/SOLR-1030
Which was broken after Jan 9, 2009 which was our last snapshot.
I'm still digging into it to see if it is obvious.
--j
--
View this message in context:
See the SOLR-1030 issue for further comments. Seems to be broken prior to
r733656 as well as we found an old bug in our database that appears to be
the same problem.
jayson.minard wrote:
We are using Solr from SVN Rev 745179
And now see this problem:
https://issues.apache.org/jira
Hello.
We currently are intersecting a precalculated OpenBitSet (that does not
affect score) with search by adding it to the filters in the ResponseBuilder
via a wrapped in a ConstantScoreQuery and Filter. We do this just before
QueryComponent does its job.
The code appears like:
But does solr-core have a dependency to solr-common still? Try clearing your
local repository and rebuilding. I get an error...
Path to dependency:
1) com.name.removed:jar:0.0.5-SNAPSHOT
2) org.apache.solr:solr-core:jar:1.4-SNAPSHOT
3)
Solr 1.4-SNAPSHOT seems to now be requiring:
3) org.apache.commons:commons-io:jar:1.4
which doesn't appear to exist on public repositories.
commons-io:commons-io:1.4 does exist.
If you clear your repository and build using it, the build fails.
Before entering a bug, is anyone else
12 matches
Mail list logo
