flink-issues 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] (FLINK-3166) The first program in ObjectReuseITCase has the wrong expected result, and it succeeds
Date Sat, 26 Dec 2015 18:03:49 GMT

    [ https://issues.apache.org/jira/browse/FLINK-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15071932#comment-15071932

ASF GitHub Bot commented on FLINK-3166:

Github user StephanEwen commented on the pull request:

    Merging this...

> The first program in ObjectReuseITCase has the wrong expected result, and it succeeds
> -------------------------------------------------------------------------------------
>                 Key: FLINK-3166
>                 URL: https://issues.apache.org/jira/browse/FLINK-3166
>             Project: Flink
>          Issue Type: Bug
>          Components: Distributed Runtime, Documentation, Tests
>            Reporter: Gabor Gevay
>            Assignee: Greg Hogan
>            Priority: Critical
> The first program in ObjectReuseITCase has the following input:
> a,1
> a,2
> a,3
> a,4
> a,50
> There is a groupBy on field 0, and then a reduce, so the result should be 1+2+3+4+50
= 60. But the hardcoded expected result is 100, and running the Flink program also produces
> The problem is caused my mismatched assumptions between ReduceCombineDriver.sortAndCombine
and the ReduceFunction in the test about object reuse rules of ReduceFunctions:
> ReduceCombineDriver.sortAndCombine has the following comment:
> "The user function is expected to return the first input as the result."
> While the ReduceFunction in the test is modifying and returning the second input. (And
the second program in the test also has the same problem.)
> I can't find the assumption that is stated in the comment in any documentation. For example,
the javadoc of ReduceFunction should make the user aware of this. Or, alternatively, the code
of the driver should be modified to not make this assumption. I'm not sure which solution
is better.

This message was sent by Atlassian JIRA

View raw message