Since Exceutor is a new interface, why is backward compatibility a concern?
I could see that become an issue later when replacing Executor execute with executeAsync. Or are both targeted for 1.10? On Tue, Sep 24, 2019 at 10:24 AM Zili Chen <wander4...@gmail.com> wrote: > Hi Thomas, > > >Should the new Executor execute method be defined as asynchronous? It > could > >return a job handle to interact with the job and the legacy environments > >can still block to retain their semantics. > > During our discussion there will be a method > > executeAsync(...): CompletableFuture<JobClient> > > where JobClient can be regarded as job handle in your context. > > I think we remain > > execute(...): JobExecutionResult > > just for backward compatibility because this effort towards 1.10 which is > not a > major version bump. > > BTW, I am drafting details of JobClient(as FLIP-74). Will start a separated > discussion > thread on that interface as soon as I finish an early version. > > Best, > tison. > > > Thomas Weise <t...@apache.org> 于2019年9月25日周三 上午1:17写道： > > > Thanks for the proposal. These changes will make it significantly easier > to > > programmatically use Flink in downstream frameworks. > > > > Should the new Executor execute method be defined as asynchronous? It > could > > return a job handle to interact with the job and the legacy environments > > can still block to retain their semantics. > > > > (The blocking execution has also made things more difficult in Beam, we > > could simply switch to use Executor directly.) > > > > Thomas > > > > > > On Tue, Sep 24, 2019 at 6:48 AM Kostas Kloudas <kklou...@apache.org> > > wrote: > > > > > Hi all, > > > > > > In the context of the discussion about introducing the Job Client API > > [1], > > > there was a side-discussion about refactoring the way users submit jobs > > in > > > Flink. There were many different interesting ideas on the topic and 3 > > > design documents that were trying to tackle both the issue about code > > > submission and the Job Client API. > > > > > > This discussion thread aims at the job submission part and proposes the > > > approach of introducing the Executor abstraction which will abstract > the > > > job submission logic from the Environments and will make it API > agnostic. > > > > > > The FLIP can be found at [2]. > > > > > > Please keep the discussion here, in the mailing list. > > > > > > Looking forward to your opinions, > > > Kostas > > > > > > [1] > > > > > > > > > https://lists.apache.org/thread.html/ce99cba4a10b9dc40eb729d39910f315ae41d80ec74f09a356c73938@%3Cdev.flink.apache.org%3E > > > [2] > > > > > > > > > https://cwiki.apache.org/confluence/display/FLINK/FLIP-73%3A+Introducing+Executors+for+job+submission > > > > > >
