-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Remove parameterization from TcpTransport #27407
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
Remove parameterization from TcpTransport #27407
Conversation
This commit is a follow up to the work completed in elastic#27132. Essentially it transitions two more methods (sendMessage and getLocalAddress) from Transport to TcpChannel. With this change, there is no longer a need for TcpTransport to be aware of the specific type of channel a transport returns. So that class is no longer parameterized by channel type.
|
As a note, I have realized that it does not make sense for NioChannel to extend TcpChannel. NioChannel is selectable channel that can be handled by nio. TcpChannel is a channel that provides the functionality for our tcp binary protocol. We eventually will have some http channel that is an NioChannel, but not a TcpChannel. Right now this causes some issues for parameterized listener types in the nio transport. Once this is merged, I will follow this PR up with another PR that fixes this issue. |
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.
so much goodness! LGTM
| } | ||
|
|
||
| @Override | ||
| public void sendMessage(BytesReference reference, ActionListener<TcpChannel> listener) { |
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 we have a more verbose TODO?
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.
Yeah. I'm not sure what happened to the rest of the comment.
|
|
||
| @Override | ||
| public void sendMessage(BytesReference reference, ActionListener<TcpChannel> listener) { | ||
| // TODO: temporar |
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't you just use the passed in listener?
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.
No. ActionListener<TcpChannel> != ActionListener<NioChannel> to the compiler. I will fix this in a follow up (#27407 (comment)).
…from_tcp_transport
…from_tcp_transport
This commit is a follow up to the work completed in #27132. Essentially it transitions two more methods (sendMessage and getLocalAddress) from Transport to TcpChannel. With this change, there is no longer a need for TcpTransport to be aware of the specific type of channel a transport returns. So that class is no longer parameterized by channel type.
This is a followup to elastic#27407. That commit removed the channel type parameter from TcpTransport. This commit removes the parameter from the handshake response handler.
This is a followup to #27407. That commit removed the channel type parameter from TcpTransport. This commit removes the parameter from the handshake response handler.
This is a followup to #27407. That commit removed the channel type parameter from TcpTransport. This commit removes the parameter from the handshake response handler.
This commit is a follow up to the work completed in #27132. Essentially
it transitions two more methods (sendMessage and getLocalAddress) from
TcpTransport to TcpChannel. With this change, there is no longer a need for
TcpTransport to be aware of the specific type of channel a transport
returns. So that class is no longer parameterized by channel type.