[
https://issues.apache.org/jira/browse/FLINK-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15062259#comment-15062259
]
ASF GitHub Bot commented on FLINK-3166:
---------------------------------------
Github user greghogan commented on the pull request:
https://github.com/apache/flink/pull/1464#issuecomment-165499126
I haven't found a prohibition on returning the second input to a
user-defined reduce function. I think fixing this in code is preferable to
documenting the problem or throwing an error, especially since the problem only
exists with object reuse enabled.
Object reuse is configured in JavaProgramTestBase but must be set in the
ExecutionEnvironmentFactory by TestEnvironment. I don't see that any of the
many tests subclassing JavaProgramTestBase were testing with object reuse
enabled.
It is rather difficult to test for object reuse. ObjectReuseITCase simply
captured a few isolated instances of strange behavior (with the original tests
3 and 4 being perfect copies). I would look to duplicate the first two tests in
the appropriate JavaProgramTestBase subclass and delete ObjectReuseITCase.
> 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 this.
> 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
(v6.3.4#6332)
