New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring to make MessageChannelHandler extensible #6915
Conversation
LGTM |
requestDecoder.setMaxCumulationBufferCapacity(Integer.MAX_VALUE); | ||
} else { | ||
requestDecoder.setMaxCumulationBufferCapacity((int) transport.maxCumulationBufferCapacity.bytes()); | ||
public ChannelPipelineFactory configureServerChannelPipelineFactory() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can the implementation still be a static factory class that is returned?
LGTM |
created static classes and added tests, should be ready now |
|
||
private final NettyHttpServerTransport transport; | ||
private static class HttpChannelPipelineFactory implements ChannelPipelineFactory { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you make it protected
few comments, other than that LGTM |
LGTM |
Small refactorings to make the MessageChannelHandler more extensible. Also allowed access to the different netty pipelines This is the fix after the first version had problems with the HTTP transport due to wrong reusing channel handlers, which is the reason why tests failed. Relates elastic#6889 Closes elastic#6915
Small refactorings to make the MessageChannelHandler more extensible. Also allowed access to the different netty pipelines This is the fix after the first version had problems with the HTTP transport due to wrong reusing channel handlers, which is the reason why tests failed. Relates #6889 Closes #6915
Awesome, this should make it possible for someone to write the SSL transport support as a plugin. I had investigated going down this route a while back but got stuck because of the shading of the Netty jar. It tossed a bunch of the Netty code that was not used in ES but needed if I wanted to add the SSL support. |
Small refactorings to make the MessageChannelHandler more extensible.
Also allowed access to the different netty pipelines
This is the fix after the first version had problems with the HTTP
transport due to wrong reusing channel handlers, which is the reason
why tests failed. This version now uses its own ChannelPipelineFactory
again.
Relates #6889 (which had been reverted in the first place)