flink-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aljoscha Krettek <aljos...@apache.org>
Subject Re: [DISCUSS] Unifying client code
Date Fri, 17 Jul 2015 11:52:43 GMT
+1
Very good idea


On Thu, 16 Jul 2015 at 17:57 Fabian Hueske <fhueske@gmail.com> wrote:

> Yes definitely.
> The client and submission code is spread out over multiple classes and
> different clients follow different paths. This is a bit messy right now,
> IMO.
> A big +1 to unify and restructure the client.
>
> 2015-07-16 17:52 GMT+02:00 Till Rohrmann <trohrmann@apache.org>:
>
> > I like the idea to have a single point of access. That would improve
> > maintainability and makes the code easier to understand. Thus +1.
> >
> > On Thu, Jul 16, 2015 at 4:45 PM, Matthias J. Sax <
> > mjsax@informatik.hu-berlin.de> wrote:
> >
> > > Hi,
> > >
> > > I just had a look into CliFrontend and Client and it seems to me, that
> > > there is no uniform design.
> > >
> > > For example, CliFrontend uses Client to execute "run" and "info"
> > > command. However, for "cancel" and "list" it does not (because
> > > org.apache.flink.client.program.Client) lacks those methods.
> > >
> > > I would recommend to extend Client and adapt CliFrontend.
> > >
> > > There is already a pull request for "cancel":
> > > https://github.com/apache/flink/pull/642
> > > However, this PR does not adapt CliFrontend and I am not sure if it
> will
> > > be finished at all. A three week old discussion resulted in no
> progress.
> > >
> > > In the current pull request for the new STOP signal, there is also some
> > > mess with this regard. CliFrontend does not use Client.stop() -> I will
> > > update this soon (this issues was the trigger to discover this "mess"),
> > > or include those changes into this work (if we start it).
> > >
> > > Additionally, we might want to uniform WebClient and job manager
> > > WebFrontend, too. I have an open PR that changed WebClient to use
> > > CliFrontend to avoid code duplication. But now, this seems not the
> right
> > > way to go. JobManagerInfoServlet duplicate this code, too.
> > >
> > > I think Client should be the unique class that offers methods for all
> > > request and is used by all other clients.
> > >
> > > What do you think about this?
> > >
> > >
> > > -Matthias
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message