flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From uce <...@git.apache.org>
Subject [GitHub] flink issue #2766: [FLINK-4898] Refactor HTTP handlers and Netty server/clie...
Date Tue, 24 Jan 2017 11:02:27 GMT
Github user uce commented on the issue:

    https://github.com/apache/flink/pull/2766
  
    Sorry for the very long delay on this one. I really like the idea of deduping code at
that level, but I don't think that we can merge this as it is. What's the current state of
the things that depend on this for the Mesos dispatcher? And how much code is actually duplicated
there? I think that this generifcation only works well for Flink's data exchange layer and
your new additions.
    
    - In general, I think that bootstrapping a Netty client/server is very easy and in most
cases you actually don't need to configure that much. For example in the queryable state network
client and server, the setup of the client and server are only a couple of dozens lines.
    - The centralized `NettyConfig` and protocol work well for projects in `flink-runtime`,
but you don't want to always couple this. For example with a separate slim module for the
queryable state client, this would require it to depend on `flink-runtime` if it wanted to
use it.
    - Futhermore, we are moving to using the `ConfigOption` gathered in `<Component>Options`
classes (like `HighAvailabilityOptions`).
    - This also would not work with the web runtime server where we don't even have a client.
    
    All in all, I just don't think that the approach taken for trying to make the data exchange
network layer generic with the "protocols" and "configurations" was a good idea in the first
place when we implemented it a few years ago.
    
    ---
    
    What about moving to the generic components to the Netty based components you require
for the Mesos dispatcher (e.g. make it part of the dispatcher PR) and leave the current data
exchange implementation as it is.
    
    I would keep the SSL handlers separate in order to allow users to easily use them as you
suggest.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---

Mime
View raw message