Opened a PR for this issue:
https://github.com/apache/flink/pull/2766To 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) <
[hidden email]> 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)
Locked
