On Nov 21, 2006, at 2:01 AM, Michael Busch (JIRA) wrote:
Furthermore people could take a look in the code coverage reports
to figure out where work needs to be done, i. e. where additional
testcases are neccessary. It would be nice if we could add a page
to the Lucene website showing
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12451955 ]
Grant Ingersoll commented on LUCENE-707:
Any last comments on the new site? I am going to commit these changes within
the week (per the 4 items laid out
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Karl Wettin updated LUCENE-550:
---
Summary: InstantiatedIndex - faster but memory consuming index
(was: InstanciatedIndex - faster but memory consuming index)
Affects Version/s:
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12451963 ]
Yonik Seeley commented on LUCENE-707:
-
New site update instructions will be the same as:
http://wiki.apache.org/solr/Website_Update_HOWTO
We might want a
[ http://issues.apache.org/jira/browse/LUCENE-720?page=all ]
Michael McCandless resolved LUCENE-720.
---
Fix Version/s: 2.1
Resolution: Fixed
OK I was able to reproduce the failure using IBMs JDK 5.0 on Linux. I changed
the tests to load the
[
http://issues.apache.org/jira/browse/LUCENE-720?page=comments#action_12452001 ]
Michael Busch commented on LUCENE-720:
--
The tests now pass on my machine too. Good job, Mike! Thanks.
Unit tests TestBackwardsCompatibility and
Grant Ingersoll wrote:
I would be more than happy to put 'em in once I get my zones account and
we decide on which tool to use.
You now have a zones account.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452006 ]
Doug Cutting commented on LUCENE-707:
-
The recently clarified Apache release policy at
http://www.apache.org/dev/release.html states that we should not link
I was away so I'm catching up.
If this (occasional large documents consume too much memory) happens
to a few applications, should it be solved in IndexWriter?
A possible design could be:
First, in addDocument(), compute the byte size of a ram segment after
the ram segment is created. In the
[
http://issues.apache.org/jira/browse/LUCENE-720?page=comments#action_12452010 ]
Michael McCandless commented on LUCENE-720:
---
Thank you for tracking this down! I did not realize field number assinment was
volatile across JREs.
Chris Hostetter wrote:
To throw another twist onto things, it would appear that the ASF has a
License for Clover 1.3.2 donated by Cenqua that Committers have access to
(see committers/donated-licenses/clover in SVN) ... it's not clear to me
if that License would allow for auto generated reports
Ning Li wrote:
I was away so I'm catching up.
If this (occasional large documents consume too much memory) happens
to a few applications, should it be solved in IndexWriter?
A possible design could be:
First, in addDocument(), compute the byte size of a ram segment after
the ram segment is
I agree with Michael, if there is a clover licence we should use it.
One major advantage of clover is the ide support for eclipse and
netbeans. Emma has no Eclipse support yet and a old not maintained
netbeans plugin.
There is a ASF donated clover license under:
Michael Busch wrote on 11/22/2006 08:47 AM:
Ning Li wrote:
A possible design could be:
First, in addDocument(), compute the byte size of a ram segment after
the ram segment is created. In the synchronized block, when the newly
created segment is added to ramSegmentInfos, also add its byte
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12452039 ]
Ning Li commented on LUCENE-565:
With the recent commits to IndexWriter, this patch no longer applies cleanly.
The 5 votes for this issue encourages
me to submit
There is a flaw in this approach as you exceed the threshold before
flushing. With very large documents, that can cause an OOM.
This is a good point.
I agree that it would be better to do this in IndexWriter, but more
machinery would be needed. Lucene would need to estimate the size of
the
Hi,
I'm working on a unit test for:
http://issues.apache.org/jira/browse/LUCENE-702
which is the disk full during addIndexes() can corrupt index issue.
I think the simplest way to do this is to subclass RAMDirectory to
create a MockDiskFullRAMDirectory class (and a corresponding
Michael McCandless wrote:
But to do this I'd need to make RAMDirectory non-final. Any
objections to this?
I can think of no reason it must be final.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands,
[ http://issues.apache.org/jira/browse/LUCENE-722?page=all ]
Daniel Naber resolved LUCENE-722.
-
Resolution: Fixed
Okay, unless there's a third version of that file it's fixed now :-)
DEFAULT spelled DEFALT in MoreLikeThis.java
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452157 ]
Otis Gospodnetic commented on LUCENE-707:
-
Grant, you should remove links to lucene4C (dead), and add links to Lucene.NET
in the Incubator.
I see 2 Lucene
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452158 ]
Otis Gospodnetic commented on LUCENE-707:
-
Oh, and don't we want tabs for individual sub-projects at the top, like on
lucene.apache.org today?
Lucene
21 matches
Mail list logo
