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 [email protected] or file a JIRA ticket
with INFRA.
---
