Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
Date: Fri, 12 Feb 2016 16:40:18 +0000 (UTC)
From: "Gabor Gevay (JIRA)" <jira@apache.org>
To: issues@flink.apache.org
Message-ID: <JIRA.12938843.1455294568000.38469.1455295218226@Atlassian.JIRA>
In-Reply-To: <JIRA.12938843.1455294568000@Atlassian.JIRA>
References: <JIRA.12938843.1455294568000@Atlassian.JIRA>
 <JIRA.12938843.1455294568218@arcas>
Subject: [jira] [Updated] (FLINK-3394) Clear up the contract of
 MutableObjectIterator.next(reuse)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/FLINK-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Gabor Gevay updated FLINK-3394:
-------------------------------
    Description: 
{{MutableObjectIterator.next(reuse)}} has the following contract (according to [~StephanEwen]'s comment \[1\]):

1. The caller may not hold onto {{reuse}} any more
2. The iterator implementor may not hold onto the returned object any more.

This should be documented in its javadoc (with "WARNING" so that people don't overlook it).

Additionally, since this was a "secret contract" up to now, all the 270 usages of {{MutableObjectIterator.next(reuse)}} should be checked for violations. A few that are suspicious at first glance, are in {{CrossDriver}}, {{UnionWithTempOperator}}, {{MutableHashTable.ProbeIterator.next}}, {{ReusingBuildFirstHashJoinIterator.callWithNextKey}}. (The violating calls in the reduce drivers are being fixed by https://github.com/apache/flink/pull/1626 )

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

  was:
{{MutableObjectIterator.next(reuse)}} has the following contract (according to [~StephanEwen]'s comment \[1\]):

1. The caller may not hold onto {{reuse}} any more
2. The iterator implementor may not hold onto the returned object any more.

This should be documented in its javadoc (with "WARNING" so that people don't overlook it).

Additionally, since this was a "secret contract" up to now, all the 270 usages of {{MutableObjectIterator.next(reuse)}} should be checked for violations. A few that are suspicious at first glance, are in {{CrossDriver}}, {{UnionWithTempOperator}}, {{MutableHashTable.ProbeIterator.next}}, {{ReusingBuildFirstHashJoinIterator.callWithNextKey}}.

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


> Clear up the contract of MutableObjectIterator.next(reuse)
> ----------------------------------------------------------
>
>                 Key: FLINK-3394
>                 URL: https://issues.apache.org/jira/browse/FLINK-3394
>             Project: Flink
>          Issue Type: Bug
>          Components: Distributed Runtime
>    Affects Versions: 1.0.0
>            Reporter: Gabor Gevay
>            Priority: Critical
>             Fix For: 1.0.0
>
>
> {{MutableObjectIterator.next(reuse)}} has the following contract (according to [~StephanEwen]'s comment \[1\]):
> 1. The caller may not hold onto {{reuse}} any more
> 2. The iterator implementor may not hold onto the returned object any more.
> This should be documented in its javadoc (with "WARNING" so that people don't overlook it).
> Additionally, since this was a "secret contract" up to now, all the 270 usages of {{MutableObjectIterator.next(reuse)}} should be checked for violations. A few that are suspicious at first glance, are in {{CrossDriver}}, {{UnionWithTempOperator}}, {{MutableHashTable.ProbeIterator.next}}, {{ReusingBuildFirstHashJoinIterator.callWithNextKey}}. (The violating calls in the reduce drivers are being fixed by https://github.com/apache/flink/pull/1626 )
> \[1\] https://issues.apache.org/jira/browse/FLINK-3291?focusedCommentId=15144654&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15144654


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