[GitHub] [flink] zjffdu commented on issue #10474: [FLINK-15116] Make JobClient stateless, remove AutoCloseable

[GitBox <gi...@apache.org>]

zjffdu commented on issue #10474: [FLINK-15116] Make JobClient stateless, remove AutoCloseable
URL: https://github.com/apache/flink/pull/10474#issuecomment-562857131
 
 
   @aljoscha @TisonKun I am thinking what is the exact difference between `JobClient` & `ClusterClient`. In user's or resource's perspective, `JobClient` & `ClusterClient` both represent the connection between client and flink JM. They just have difference in the scope of api, `JobClient` focus on job level api while `ClusterClient` represent the cluster level api. 
   So I am thinking do we really need to introduce 2 kinds of client for interacting with flink JM. Is it possible to just expose one unified client to users. (Maybe we can call it `FlinkClient`). I think it can solve 2 issues we discussed so far.
   
   1. How to control the lifecycle of this Client. 
   If we unify them into one client (Let me call it `FlinkClient` afterwards), then user don't need to manage its lifecycle, Flink should take care of it. I believe we could close it in the client jvm's shutdown hook
   2. What to return for executeAsync
   In this approach, we don't need to care about it, just return void. User can always manipulate the job via the `FlinkClient`. Flink just need to expose `FlinkClient` to user, I think `ExecutionEnvironment` is the right place to expose `FlinkClient`.
   
   This is just my rough understanding of `JobClient` & `ClusterClient`, feel free to correct me if I am wrong @aljoscha @TisonKun 
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services