TisonKun commented on issue #10311: [FLINK-14762][client] Enrich JobClient API URL: https://github.com/apache/flink/pull/10311#issuecomment-558413695 > Hi @TisonKun , thanks a lot for the work. As an overarching comment, I noticed that you add a flag `moveOwnership` to the `ClusterClientJobClientAdapter` and this also bubbles up till the `ClusterClient.submitJob()`. > > I am wondering if this is needed, and from a conceptual point of view, I lean towards the _no_. As a first point, I noticed that the only places that this is set to `false` are the `ClientUtils.submitJob...` which are mainly used in tests. And second, why not closing the `ClusterClient` always, when the `JobClient` closes (which is the responsibility of the call-site), and just let the user decide when to close the job client. > > If the user wants to do something with the `JobClient`, he/she can create a new one (although we still need to figure out how to "retrieve" a `jobClient`). > > WDYT? Yes I also tend *not* to do so. At that moment I was a bit delirious for thinking about whether or not close cluster client on job client closed :/ for shutting down things, I think it is still a configurable action whether or not we close cluster client on job client close because cluster client "spawns" job client and maybe we call `submitJob` multiple times within one cluster client(normally for job management platform). Neither we want to spawn cluster client per job nor we want to close the shared cluster client on job client closed. The point here is "who is responsible for closing cluster client? job client or the caller?" I push a commit daf85a75b9c24918058b8bfe09416b2828bd02a5 for customizing actions on closed for define such manner while considering code quality. Does it make sense to you?
---------------------------------------------------------------- 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: [email protected] With regards, Apache Git Services
