Mailing-List: contact issues-help@flink.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@flink.apache.org
Received-SPF: pass (athena.apache.org: message received from 54.191.145.13
 which is an MX secondary for issues@flink.apache.org)
Date: Wed, 29 Apr 2015 12:34:07 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: issues@flink.incubator.apache.org
Message-ID: <JIRA.12822979.1429698792000.20818.1430310847894@Atlassian.JIRA>
In-Reply-To: <JIRA.12822979.1429698792000@Atlassian.JIRA>
References: <JIRA.12822979.1429698792000@Atlassian.JIRA>
 <JIRA.12822979.1429698792823@arcas>
Subject: [jira] [Commented] (FLINK-1927) [Py] Rework operator distribution
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

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

Github user aljoscha commented on the pull request:

    https://github.com/apache/flink/pull/638#issuecomment-97412959
  
    But doesn't this mean that the lambdas now must be stateless, i.e. if a user refers to some variable outside the lambda this will not be serialised with the closure anymore (because there is no serialization of the closure anymore).


> [Py] Rework operator distribution
> ---------------------------------
>
>                 Key: FLINK-1927
>                 URL: https://issues.apache.org/jira/browse/FLINK-1927
>             Project: Flink
>          Issue Type: Improvement
>          Components: Python API
>    Affects Versions: 0.9
>            Reporter: Chesnay Schepler
>            Assignee: Chesnay Schepler
>            Priority: Minor
>             Fix For: 0.9
>
>
> Currently, the python operator is created when execution the python plan file, serialized using dill and saved as a byte[] in the java function. It is then deserialized at runtime on each node.
> The current implementation is fairly hacky, and imposes certain limitations that make it hard to work with. Chaining, or generally saving other user-code, always requires a separate deserialization step after deserializing the operator.
> These issues can be easily circumvented by rebuilding the (python) plan on each node, instead of serializing the operator. The plan creation is deterministic, and every operator is uniquely identified by an ID that is already known to the java function.
> This change will allow us to easily support custom serializers.


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