Skip to content

Respond with same compression scheme received#76372

Merged
Tim-Brooks merged 12 commits intoelastic:masterfrom
Tim-Brooks:compression_echo_scheme
Aug 13, 2021
Merged

Respond with same compression scheme received#76372
Tim-Brooks merged 12 commits intoelastic:masterfrom
Tim-Brooks:compression_echo_scheme

Conversation

@Tim-Brooks
Copy link
Copy Markdown
Contributor

This is related to #73497. Currently, we only use the configured
transport.compression_scheme setting when compressing a request or a
response. Additionally, the cluster.remote.*.compression_scheme
setting is ignored. This commit fixes this behavior by respecting the
per-cluster setting. Additionally, it resolves confusion around inbound
and outbound connections by always responding with the same scheme that
was received. This allows remote connections to have different schemes
than local connections.

@Tim-Brooks Tim-Brooks added >enhancement :Distributed/Network Http and internode communication implementations v8.0.0 v7.15.0 labels Aug 11, 2021
@elasticmachine elasticmachine added the Team:Distributed Meta label for distributed team. label Aug 11, 2021
@elasticmachine
Copy link
Copy Markdown
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

Copy link
Copy Markdown
Contributor

@henningandersen henningandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I think we should add the compression scheme setting to docs for remote clusters:
https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-remote-clusters.html#remote-cluster-settings
(follow-up is fine, perhaps together with removing experimental flag on the setting(s)).
(edit: now saw the other PR that is already merged, thanks!)

}

private static boolean uncompressedOrSchemeDefinited(Header header) {
return header.isCompressed() == false || header.getCompressionScheme() != null;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this be tightened to:

Suggested change
return header.isCompressed() == false || header.getCompressionScheme() != null;
return header.isCompressed() == (header.getCompressionScheme() != null);

final Compression.Scheme compressionScheme = header.getCompressionScheme();
if (header.isCompressed()) {
assertNotNull(compressionScheme);
}
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we add else assertNull(compressionScheme); ? (or embed it into the other assertion).

final TransportResponse response, final Compression.Scheme compressionScheme, final boolean isHandshake)
throws IOException {
Version version = Version.min(this.version, nodeVersion);
final Compression.Scheme compressionScheme;
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can now assert that if compressionScheme == LZ4 we are on a new enough version. Something like:

assert compressionScheme != Compression.Scheme.LZ4 || version.onOrAfter(Compression.Scheme.LZ4_VERSION);

I am sure this will break a test or two and I am OK with deferring this if it adds too much trouble.

@Tim-Brooks Tim-Brooks merged commit e6fd459 into elastic:master Aug 13, 2021
Tim-Brooks added a commit to Tim-Brooks/elasticsearch that referenced this pull request Aug 13, 2021
This is related to elastic#73497. Currently, we only use the configured
transport.compression_scheme setting when compressing a request or a
response. Additionally, the cluster.remote.*.compression_scheme
setting is ignored. This commit fixes this behavior by respecting the
per-cluster setting. Additionally, it resolves confusion around inbound
and outbound connections by always responding with the same scheme that
was received. This allows remote connections to have different schemes
than local connections.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

:Distributed/Network Http and internode communication implementations >enhancement Team:Distributed Meta label for distributed team. v7.15.0 v8.0.0-alpha2

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants