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

zhijiang updated FLINK-12497:
-----------------------------
    Description: 
In current {{ConnectionManager#start(ResultPartitionProvider, 
TaskEventDispatcher)}}, the parameters in start are only reasonable for 
{{NettyConnectionManager}} implementation, reductant for 
{{LocalConnectionManager}}. 

We could put these parameters in the constructor of {{NettyConnectionManager}}, 
then {{ConnectionManager#start()}} would be more cleaner for both 
implementations. And it could also bring benefits for calling start in 
{{NetworkEnvironment}} which does not need to maintain private 
{{TaskEventDispatcher}} in future.

  was:
In current `ConnectionManager#start(ResultPartitionProvider, 
TaskEventDispatcher)`, the parameters in start are only reasonable for 
`NettyConnectionManager` implementation, reductant for 
`LocalConnectionManager`. 

We could put these parameters in the constructor of `NettyConnectionManager`, 
then `ConnectionManager#start()` would be more cleaner for both 
implementations. And it also bring benefits for calling start in 
`NetworkEnvironment` which does not need to maintain private 
`TaskEventDispatcher`.


> Refactor the start method of ConnectionManager
> ----------------------------------------------
>
>                 Key: FLINK-12497
>                 URL: https://issues.apache.org/jira/browse/FLINK-12497
>             Project: Flink
>          Issue Type: Sub-task
>          Components: Runtime / Network
>            Reporter: zhijiang
>            Assignee: zhijiang
>            Priority: Minor
>
> In current {{ConnectionManager#start(ResultPartitionProvider, 
> TaskEventDispatcher)}}, the parameters in start are only reasonable for 
> {{NettyConnectionManager}} implementation, reductant for 
> {{LocalConnectionManager}}. 
> We could put these parameters in the constructor of 
> {{NettyConnectionManager}}, then {{ConnectionManager#start()}} would be more 
> cleaner for both implementations. And it could also bring benefits for 
> calling start in {{NetworkEnvironment}} which does not need to maintain 
> private {{TaskEventDispatcher}} in future.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to