[GitHub] flink issue #2766: [FLINK-4898] Refactor HTTP handlers and Netty server/clie...

[uce <gi...@git.apache.org>]

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.
---