Skip to content
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

Change abstraction point for transport protocol #15432

Merged
merged 2 commits into from
Aug 28, 2024

Conversation

andrross
Copy link
Member

The previous implementation had a transport switch point in InboundPipeline when the bytes were initially pulled off the wire. There was no implementation for any other protocol as the canHandleBytes method was hardcoded to return true. I believe this is the wrong point to switch on the protocol. This change makes NativeInboundBytesHandler protocol agnostic beyond the header. With this change, a complete message is parsed from the stream of bytes, with the header schema being unchanged from what exists today. The protocol switch point will now be at InboundHandler::inboundMessage. The header will indicate what protocol was used to serialize the the non-header bytes of the message and then invoke the appropriate handler based on that field.

Check List

  • Functionality includes testing.
  • API changes companion pull request created, if applicable.
  • Public documentation issue/PR created, if applicable.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@andrross
Copy link
Member Author

@reta It was easier to illustrate the change here as a PR as opposed to describing it in an issue. The key changes here are basically:

  • Remove protocol-specific types from NativeInboundBytesHandler (this class is now mis-named, but I didn't rename yet it to avoid polluting the diff).
  • Make ProtocolInboundMessage an abstract class containing the non-protocol-specific parts of the message. Essentially only the StreamInput part is in NativeInboundMessage now.

The upshot of the change here is that the "header" part of the transport protocol remains unchanged, but they payload of each message is what now can be different protocols. The server will be able to freely exchange a mix of protocols on one connection at runtime (required for bwc anyway). The following code is where we will switch to the appropriate payload handler based on the protocol specified in the header:

void inboundMessage(TcpChannel channel, ProtocolInboundMessage message) throws Exception {
final long startTime = threadPool.relativeTimeInMillis();
channel.getChannelStats().markAccessed(startTime);
messageReceivedFromPipeline(channel, message, startTime);
}
private void messageReceivedFromPipeline(TcpChannel channel, ProtocolInboundMessage message, long startTime) throws IOException {
ProtocolMessageHandler protocolMessageHandler = protocolMessageHandlers.get(message.getTransportProtocol());
if (protocolMessageHandler == null) {
throw new IllegalStateException("No protocol message handler found for protocol: " + message.getTransportProtocol());
}
protocolMessageHandler.messageReceived(channel, message, startTime, slowLogThresholdMs, messageListener);
}

Copy link
Contributor

❌ Gradle check result for 0138b6e: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@dblock
Copy link
Member

dblock commented Aug 27, 2024

This looks right to me!

@reta
Copy link
Collaborator

reta commented Aug 27, 2024

This looks right to me!

Double it!

@andrross andrross force-pushed the transport-protocol branch from 0138b6e to d4217c1 Compare August 27, 2024 20:10
Copy link
Contributor

❕ Gradle check result for d4217c1: UNSTABLE

  • TEST FAILURES:
      1 org.opensearch.cluster.MinimumClusterManagerNodesIT.testThreeNodesNoClusterManagerBlock

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

Copy link

codecov bot commented Aug 27, 2024

Codecov Report

Attention: Patch coverage is 84.09091% with 21 lines in your changes missing coverage. Please review.

Project coverage is 71.88%. Comparing base (f5da8c8) to head (f6d5ce9).
Report is 2 commits behind head on main.

Files with missing lines Patch % Lines
.../org/opensearch/transport/InboundBytesHandler.java 88.40% 0 Missing and 8 partials ⚠️
.../java/org/opensearch/transport/InboundMessage.java 84.61% 4 Missing and 2 partials ⚠️
...transport/nativeprotocol/NativeInboundMessage.java 0.00% 3 Missing ⚠️
...in/java/org/opensearch/transport/TcpTransport.java 0.00% 2 Missing ⚠️
.../java/org/opensearch/transport/InboundHandler.java 50.00% 1 Missing ⚠️
...va/org/opensearch/transport/TransportProtocol.java 80.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main   #15432      +/-   ##
============================================
+ Coverage     71.79%   71.88%   +0.09%     
- Complexity    63263    63305      +42     
============================================
  Files          5231     5233       +2     
  Lines        296526   296526              
  Branches      42832    42827       -5     
============================================
+ Hits         212900   213171     +271     
+ Misses        66121    65782     -339     
- Partials      17505    17573      +68     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@andrross andrross force-pushed the transport-protocol branch from d4217c1 to 95eeaf0 Compare August 27, 2024 23:53
Copy link
Contributor

❌ Gradle check result for 95eeaf0: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@andrross andrross force-pushed the transport-protocol branch 3 times, most recently from c3c7a27 to 4c6b24f Compare August 28, 2024 01:07
Copy link
Contributor

❌ Gradle check result for 4c6b24f: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

✅ Gradle check result for 39c14fd: SUCCESS

Copy link
Contributor

✅ Gradle check result for c3c7a27: SUCCESS

@andrross andrross added skip-changelog backport 2.x Backport to 2.x branch labels Aug 28, 2024
@andrross andrross force-pushed the transport-protocol branch from 4c6b24f to 27a7a59 Compare August 28, 2024 02:53
Copy link
Contributor

❌ Gradle check result for 27a7a59: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

@andrross andrross force-pushed the transport-protocol branch from 27a7a59 to 8580ace Compare August 28, 2024 15:34
@andrross andrross marked this pull request as ready for review August 28, 2024 15:35
Copy link
Contributor

❕ Gradle check result for 8580ace: UNSTABLE

Please review all flaky tests that succeeded after retry and create an issue if one does not already exist to track the flaky failure.

…ation (opensearch-project#13126)"

This reverts commit f5c3ef9.

Signed-off-by: Andrew Ross <andrross@amazon.com>
The previous implementation had a transport switch point in
InboundPipeline when the bytes were initially pulled off the wire. There
was no implementation for any other protocol as the `canHandleBytes`
method was hardcoded to return true. I believe this is the wrong point
to switch on the protocol. This change makes NativeInboundBytesHandler
protocol agnostic beyond the header. With this change, a complete
message is parsed from the stream of bytes, with the header schema being
unchanged from what exists today. The protocol switch point will now be
at `InboundHandler::inboundMessage`. The header will indicate what
protocol was used to serialize the the non-header bytes of the message
and then invoke the appropriate handler based on that field.

Signed-off-by: Andrew Ross <andrross@amazon.com>
@andrross andrross force-pushed the transport-protocol branch from 8580ace to f6d5ce9 Compare August 28, 2024 19:36
Copy link
Contributor

❌ Gradle check result for f6d5ce9: FAILURE

Please examine the workflow log, locate, and copy-paste the failure(s) below, then iterate to green. Is the failure a flaky test unrelated to your change?

Copy link
Contributor

✅ Gradle check result for f6d5ce9: SUCCESS

@andrross andrross merged commit 5663b4a into opensearch-project:main Aug 28, 2024
33 of 34 checks passed
@andrross andrross deleted the transport-protocol branch August 28, 2024 23:57
@opensearch-trigger-bot
Copy link
Contributor

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch/backport-2.x
# Create a new branch
git switch --create backport/backport-15432-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 5663b4ae5c5553b358226f15f17b89aa843f9479
# Push it to GitHub
git push --set-upstream origin backport/backport-15432-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-15432-to-2.x.

@dblock
Copy link
Member

dblock commented Aug 29, 2024

@andrross backport manually pls?

@andrross andrross restored the transport-protocol branch August 29, 2024 15:47
@andrross andrross deleted the transport-protocol branch August 29, 2024 16:52
akolarkunnu pushed a commit to akolarkunnu/OpenSearch that referenced this pull request Sep 10, 2024
…5432)

* Revert "Replacing InboundMessage with NativeInboundMessage for deprecation (opensearch-project#13126)"

This reverts commit f5c3ef9.

Signed-off-by: Andrew Ross <andrross@amazon.com>

* Change abstraction point for transport protocol

The previous implementation had a transport switch point in
InboundPipeline when the bytes were initially pulled off the wire. There
was no implementation for any other protocol as the `canHandleBytes`
method was hardcoded to return true. I believe this is the wrong point
to switch on the protocol. This change makes NativeInboundBytesHandler
protocol agnostic beyond the header. With this change, a complete
message is parsed from the stream of bytes, with the header schema being
unchanged from what exists today. The protocol switch point will now be
at `InboundHandler::inboundMessage`. The header will indicate what
protocol was used to serialize the the non-header bytes of the message
and then invoke the appropriate handler based on that field.

Signed-off-by: Andrew Ross <andrross@amazon.com>

---------

Signed-off-by: Andrew Ross <andrross@amazon.com>
dk2k pushed a commit to dk2k/OpenSearch that referenced this pull request Oct 16, 2024
…5432)

* Revert "Replacing InboundMessage with NativeInboundMessage for deprecation (opensearch-project#13126)"

This reverts commit f5c3ef9.

Signed-off-by: Andrew Ross <andrross@amazon.com>

* Change abstraction point for transport protocol

The previous implementation had a transport switch point in
InboundPipeline when the bytes were initially pulled off the wire. There
was no implementation for any other protocol as the `canHandleBytes`
method was hardcoded to return true. I believe this is the wrong point
to switch on the protocol. This change makes NativeInboundBytesHandler
protocol agnostic beyond the header. With this change, a complete
message is parsed from the stream of bytes, with the header schema being
unchanged from what exists today. The protocol switch point will now be
at `InboundHandler::inboundMessage`. The header will indicate what
protocol was used to serialize the the non-header bytes of the message
and then invoke the appropriate handler based on that field.

Signed-off-by: Andrew Ross <andrross@amazon.com>

---------

Signed-off-by: Andrew Ross <andrross@amazon.com>
dk2k pushed a commit to dk2k/OpenSearch that referenced this pull request Oct 17, 2024
…5432)

* Revert "Replacing InboundMessage with NativeInboundMessage for deprecation (opensearch-project#13126)"

This reverts commit f5c3ef9.

Signed-off-by: Andrew Ross <andrross@amazon.com>

* Change abstraction point for transport protocol

The previous implementation had a transport switch point in
InboundPipeline when the bytes were initially pulled off the wire. There
was no implementation for any other protocol as the `canHandleBytes`
method was hardcoded to return true. I believe this is the wrong point
to switch on the protocol. This change makes NativeInboundBytesHandler
protocol agnostic beyond the header. With this change, a complete
message is parsed from the stream of bytes, with the header schema being
unchanged from what exists today. The protocol switch point will now be
at `InboundHandler::inboundMessage`. The header will indicate what
protocol was used to serialize the the non-header bytes of the message
and then invoke the appropriate handler based on that field.

Signed-off-by: Andrew Ross <andrross@amazon.com>

---------

Signed-off-by: Andrew Ross <andrross@amazon.com>
dk2k pushed a commit to dk2k/OpenSearch that referenced this pull request Oct 21, 2024
…5432)

* Revert "Replacing InboundMessage with NativeInboundMessage for deprecation (opensearch-project#13126)"

This reverts commit f5c3ef9.

Signed-off-by: Andrew Ross <andrross@amazon.com>

* Change abstraction point for transport protocol

The previous implementation had a transport switch point in
InboundPipeline when the bytes were initially pulled off the wire. There
was no implementation for any other protocol as the `canHandleBytes`
method was hardcoded to return true. I believe this is the wrong point
to switch on the protocol. This change makes NativeInboundBytesHandler
protocol agnostic beyond the header. With this change, a complete
message is parsed from the stream of bytes, with the header schema being
unchanged from what exists today. The protocol switch point will now be
at `InboundHandler::inboundMessage`. The header will indicate what
protocol was used to serialize the the non-header bytes of the message
and then invoke the appropriate handler based on that field.

Signed-off-by: Andrew Ross <andrross@amazon.com>

---------

Signed-off-by: Andrew Ross <andrross@amazon.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants