[jira] Resolved: (LUCENE-388) [PATCH] IndexWriter.maybeMergeSegments() takes lots of CPU resources

[ http://issues.apache.org/jira/browse/LUCENE-388?page=all ] Yonik Seeley resolved LUCENE-388. - Fix Version/s: 2.0.1 Resolution: Fixed I've committed Doron's version after review and further testing with my testInvariants() (also committed, but c

Re: [jira] Commented: (LUCENE-648) Allow changing of ZIP compression level for compressed fields

I agree. I would vote for deprecating the compression stuff. I am still interested in the flexible indexing part mentioned later in Nicolas' response, but that is a separate thread. On Aug 16, 2006, at 8:33 PM, Robert Engels wrote: I just think the compressed field type should be removed

Re: [jira] Commented: (LUCENE-648) Allow changing of ZIP compression level for compressed fields

I just think the compressed field type should be removed from lucene all together. Only the binary field type should remain, and the application can externally compress/uncompress fields using a fascade/containment hierarchy using Document. That is class MyDocument { Document doc; Stri

Re: flushRamSegments() is "over merging"?

On 8/16/06, Doron Cohen <[EMAIL PROTECTED]> wrote: Under-merging would hurt search, unless optimize is called explicitly, but the index should "behave" without requiring the user to call optimize. 388 deals with this. Depends on what you mean by "behave" :-) More segments than expected can caus

[jira] Commented: (LUCENE-388) [PATCH] IndexWriter.maybeMergeSegments() takes lots of CPU resources

[ http://issues.apache.org/jira/browse/LUCENE-388?page=comments#action_12428527 ] Yonik Seeley commented on LUCENE-388: - I was literally a minute away from committing my version when Doron sumbitted his ;-) Actually, I think I like Doron's

[jira] Updated: (LUCENE-388) [PATCH] IndexWriter.maybeMergeSegments() takes lots of CPU resources

[ http://issues.apache.org/jira/browse/LUCENE-388?page=all ] Doron Cohen updated LUCENE-388: --- Attachment: doron_IndexWriter.patch It seems that the excessive cpu usage is mainly for (re)scanning those single-doc segments at the top of the "stack". The f

[jira] Commented: (LUCENE-645) Highligter fails to include non-token at end of string to be highlighted

[ http://issues.apache.org/jira/browse/LUCENE-645?page=comments#action_12428521 ] Mark Harwood commented on LUCENE-645: - [Just got back from holiday and picking up some old messages] I've committed what I beleive to be a fix for this along w

[jira] Closed: (LUCENE-653) GData-server storage fix activation depth

[ http://issues.apache.org/jira/browse/LUCENE-653?page=all ] Yonik Seeley closed LUCENE-653. --- Resolution: Fixed committed. > GData-server storage fix activation depth > - > > Key: LUCENE-653 >

[jira] Closed: (LUCENE-642) GData Server IndexComponent

[ http://issues.apache.org/jira/browse/LUCENE-642?page=all ] Yonik Seeley closed LUCENE-642. --- Resolution: Fixed It works now! committed. > GData Server IndexComponent > --- > > Key: LUCENE-642 > URL

[jira] Commented: (LUCENE-528) Optimization for IndexWriter.addIndexes()

[ http://issues.apache.org/jira/browse/LUCENE-528?page=comments#action_12428478 ] Ning Li commented on LUCENE-528: In an email thread titled "LUCENE-528 and 565", I described a weakness of the proposed solution: "I'm totally for a version of ad

[jira] Closed: (LUCENE-649) Fixed Spelling mailinglist.xml

[ http://issues.apache.org/jira/browse/LUCENE-649?page=all ] Daniel Naber closed LUCENE-649. --- Resolution: Fixed Thanks, committed. > Fixed Spelling mailinglist.xml > -- > > Key: LUCENE-649 > URL:

[jira] Closed: (LUCENE-656) FieldsInfo uses deprecated API

[ http://issues.apache.org/jira/browse/LUCENE-656?page=all ] Daniel Naber closed LUCENE-656. --- Resolution: Fixed Thanks, patch is committed. > FieldsInfo uses deprecated API > -- > > Key: LUCENE-656 >

Re: GData-Server svn repository

Fixed thank you! regards simon On 8/16/06, Marcos César de Oliveira <[EMAIL PROTECTED]> wrote: The svn url in the wiki is wrong. The correct url is: http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/gdata-server/.

[jira] Updated: (LUCENE-653) GData-server storage fix activation depth

[ http://issues.apache.org/jira/browse/LUCENE-653?page=all ] Simon Willnauer updated LUCENE-653: --- Attachment: bugfix.diff Some Changes to fix still open bugs and features: Feature: EntryEventListener -> Added method for listener EntryEventMediator -> A

GData-Server svn repository

The svn url in the wiki is wrong. The correct url is: http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/gdata-server/.

Re: [jira] Commented: (LUCENE-648) Allow changing of ZIP compression level for compressed fields

On Aug 16, 2006, at 8:32 AM, Nicolas Lalevée wrote: Hi, In the issue, you wrote that "This way the indexing level just stores opaque binary fields, and then Document handles compress/uncompressing as needed." I have looked into the Lucene code, and it seems to me that it is Field that

Re: [jira] Commented: (LUCENE-648) Allow changing of ZIP compression level for compressed fields

Le Lundi 14 Août 2006 20:44, Michael McCandless a écrit : > >> If you make the compression external this is already done. In order > >> to do what the poster requires, you still need to read and update > >> fields without reading the entire document. You just do this at a > >> binary field level, a

Re: flushRamSegments() is "over merging"?

Thanks Yonik, you're right, I got confused with the merge factor. My (corrected) interpretation of merge-factor is - rank of an imaginary merge tree - controlling how many segments are merged to create a larger segment. This way it balances io for merging during indexing, vs. io during search. Yo