You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by "Till Rohrmann (JIRA)" <ji...@apache.org> on 2016/03/21 14:59:25 UTC

[jira] [Created] (FLINK-3642) Disentangle ExecutionConfig

Till Rohrmann created FLINK-3642:
------------------------------------

             Summary: Disentangle ExecutionConfig
                 Key: FLINK-3642
                 URL: https://issues.apache.org/jira/browse/FLINK-3642
             Project: Flink
          Issue Type: Improvement
    Affects Versions: 1.1.0
            Reporter: Till Rohrmann


Initially, the {{ExecutionConfig}} started out being a configuration to configure the behaviour of the system with respect to the associated job. As such it stored information about the restart strategy, registered types and the parallelism of the job. However, it happened that the {{ExecutionConfig}} has become more of an easy entry-point to pass information into the system. As such, the user can now set arbitrary information as part of the {{GlobalJobParameters}} in the {{ExecutionConfig}} which is piped to all kinds of different locations in the system, e.g. the serializers, JM, ExecutionGraph, TM, etc. 

This mixture of user code classes with system parameters makes it really cumbersome to send system information around, because you always need a user code class loader to deserialize it. Furthermore, there are different means how the {{ExecutionConfig}} is passed to the system. One is giving it to the {{Serializers}} created in the JavaAPIPostPass and another is giving it directly to the {{JobGraph}}, for example. The problem is that the {{ExecutionConfig}} contains information which is required at different stages of a program execution.

I think it would be beneficial to disentangle the {{ExecutionConfig}} a little bit along the lines of the different concerns for which the {{ExecutionConfig}} is used currently. 



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