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 FSDirect
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:
>
> This is w
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
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 org.ap
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 r
ing post-commit callback hooks,
> 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:
:36 AM, jayson.minard wrote:
>
>>
>> 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
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
ass
With autocommit, I am seeing threads pile up behind the CommitTracker
scheduleCommitWithin method while commit and background merging is underway
(blocked by CommitTracker.run). Is this intended? Or should the commit be
scheduled and the threads move along working on the next "transaction" ? I
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.
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:
http://www.nabble.com/Facet-
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:
List
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) org.apache.solr:solr-common:jar:1.
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 seein
14 matches
Mail list logo
