Opened a PR for this issue: https://github.com/apache/flink/pull/2766
To explain, the PR refactors the NettyClient/NettyServer to be reusable for the ever-growing set of endpoints within Flink. The procedure for defining an endpoint would now be: 1. Create a configuration subclass of `NettyConfig`. e.g. `PartitionRequestNettyConfig`. 2. Define a protocol subclass of `NettyProtocol` to encapsulate the channel pipeline. 3. Add the `SSLProtocolHandler` to your pipeline as needed. 4. Instantiate `NettyServer` with an instance of your protocol. 5. Instantiate `NettyClient`. Supply an instance of your client pipeline initializer via the protocol or via the `connect` method. The latter makes it easy to correlate responses with higher-level client flow. e.g. fulfilling a response promise in a channel handler. 6. Create unit tests employing the `EmbeddedChannel` class to test your pipeline. Eron > On Oct 24, 2016, at 4:16 PM, Eron Wright (JIRA) <j...@apache.org> wrote: > > Eron Wright created FLINK-4898: > ----------------------------------- > > Summary: Refactor HTTP handlers and Netty server/client > Key: FLINK-4898 > URL: https://issues.apache.org/jira/browse/FLINK-4898 > Project: Flink > Issue Type: Sub-task > Reporter: Eron Wright > Assignee: Eron Wright > Priority: Minor > > > The dispatcher requires an HTTP stack, ideally with a minimum of dependencies > and able to interoperate with Netty 4.0.28 (on which Flink currently > depends). The `runtime-web` module has some home-grown HTTP handlers > already, and the `runtime` module has some low-level Netty code worth reusing. > > > > > -- > This message was sent by Atlassian JIRA > (v6.3.4#6332)
