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

ASF GitHub Bot commented on FLINK-3166:
---------------------------------------

Github user zentol commented on the pull request:

    https://github.com/apache/flink/pull/1464#issuecomment-165516598
  
    ooohhh...that's a problem. alrighty, your solution for that looks good. 
actually, would you mind moving that into a separate PR so we can get it in 
faster? this should be fixed ASAP.


> 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)

Reply via email to