lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENENET-282) Handle potential overflow in LogByteSizeMergePolicy.SetMaxMergeMB
Date Sun, 25 Jan 2015 01:57:35 GMT

    [ https://issues.apache.org/jira/browse/LUCENENET-282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14290943#comment-14290943
] 

ASF GitHub Bot commented on LUCENENET-282:
------------------------------------------

GitHub user laimis opened a pull request:

    https://github.com/apache/lucenenet/pull/58

    Fix overflow resulting in negative values

    Noticed while debugging failing Lucene42/45 codec tests that sometimes when a test ran
ForceMerge(1) on an index writer, the merge of segments did not occur and the directory contained
whatever the number of segments existed before the merge. The tests then proceeded to fail
as they expected only one segment to be in the index.
    
    The issue is LogByteSizeMergePolicy. It does not occur all the time in the tests as its
selection is random (https://github.com/apache/lucenenet/blob/master/src/Lucene.Net.TestFramework/Util/LuceneTestCase.cs#L977).
LogByteSizeMergePolicy policy in constructor sets the max size of the segment for forced merges.
The value always ends up being too large for the long type and gets overflown, ie set to a
negative value. This then caused LogMergePolicy to inappropriately mark small segments as
too large at this logic branch:
    
    https://github.com/apache/lucenenet/blob/master/src/Lucene.Net.Core/Index/LogMergePolicy.cs#L433
    
    I double checked that Java does indeed behave by not setting the value to a negative number
and instead setting it to long.MaxValue. Looks like the previous port developers dealt with
this before as well :) https://issues.apache.org/jira/browse/LUCENENET-282 
    
    Note that this does not fix all of the tests that use ForceMerges, most of them continue
to fail due to another bug, but the fix for that is coming up in a separate PR.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/laimis/lucenenet LogByteSizeMergePolicy_fixes

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/lucenenet/pull/58.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #58
    
----
commit 593231b3b39cb81dfcd29ea81cf98dc1ba9a026a
Author: Laimonas Simutis <laimis@gmail.com>
Date:   2015-01-25T01:22:04Z

    fix overflow resulting in negative values

----


> Handle potential overflow in LogByteSizeMergePolicy.SetMaxMergeMB
> -----------------------------------------------------------------
>
>                 Key: LUCENENET-282
>                 URL: https://issues.apache.org/jira/browse/LUCENENET-282
>             Project: Lucene.Net
>          Issue Type: Bug
>            Reporter: Michael Garski
>         Attachments: LUCENENET-282.patch
>
>
> Java gracefully overflows to long.maxValue, .NET to Int64.MinValue.  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message