TisonKun commented on issue #10408: [FLINK-14992][client] Add job listener to execution environments URL: https://github.com/apache/flink/pull/10408#issuecomment-562389662 > Maybe to outline a bit more how things work: > > As a user you would write this code when submitting a long-running streaming job: > > ``` > try (JobClient client = env.executeAsync().get) { > // maybe do stuff with client > } > // at this point the JobClient will be closed > ``` > > currently (in master) the signature of `executeAsync()` is `CompletableFuture<JobClient> executeAsync()`. As a user you have to close the client. I'm now thinking that maybe we should not always return a `JobClient` but maybe only a `JobContext` (or some name) that allows retrieving a client if you need one. > > If the `JobClient` that the job listener gets is the same one as the one that the user gets as a result of `executeAsync()` the lifecycle is unpredictable and the listener cannot store the JobClient and depend on it working in the future, which is what you want to do in Zeppelin, I assume. > > Now I'm thinking that maybe all cases should return something like a `JobContext` where you can create a client when you need it and then close it again. If the resources attached to JobClient is the same in all cases, we can do that[1]. I try to figure out its possibility and find that we cannot return not a JobClient, but, a JobContext with information/configuration to create a JobClient It's because, given in LocalExecutor case, there will be a unique point we close the underneath MiniCluster on exit. This JobClient is different from all its duplications. [1] return JobContext on `executeAsync`
---------------------------------------------------------------- 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
