Fixed compression support for h2c protocol#4944
Fixed compression support for h2c protocol#4944andrross merged 2 commits intoopensearch-project:mainfrom
Conversation
|
@VachaShah fyi |
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
| final ChannelPipeline pipeline = ctx.pipeline(); | ||
| pipeline.addAfter(ctx.name(), "handler", getRequestHandler()); | ||
| pipeline.replace(this, "aggregator", aggregator); | ||
| pipeline.replace(this, "decoder_compress", new HttpContentDecompressor()); |
There was a problem hiding this comment.
I haven't looked through this deeply yet so apologies in advance if this comment is not helpful...but I find this all this "replace", "addAfter", "addBefore", etc makes it very hard to reason about the state of the pipeline when this is done. I'm wondering if it is possible to simplify this.
One thing that jumps out is that we're adding handlers before "handler" (which is added above). Could that be re-written as the following where it's more of a simple chaining of handlers?
final ChannelPipeline pipeline = ctx.pipeline();
pipeline.addAfter(ctx.name(), "request_creator", ...
pipeline.addAfter("request_creator", "response_creator", ...
pipeline.addAfter("response_creator", "pipelining", ...
pipeline.addAfter("pipelining", "handler", ...
Also sometimes we're using the pipeline local variable and sometimes we're using ch.pipeline(). I'm assuming those refer to the same instance?
In any case, making the Netty pipeline setup as simple as possible can really help with long term maintainability.
There was a problem hiding this comment.
Even better, if we know that ctx.name() is the last handler in the pipeline (this handler was just added via an addLast call so I think it should be), then you can just add the new handlers via addLast calls, which I find is the simplest way to construct a pipeline.
There was a problem hiding this comment.
Thanks @andrross
Also sometimes we're using the pipeline local variable and sometimes we're using ch.pipeline(). I'm assuming those refer to the same instance?
Yes, thanks for noticing, I will change that to use pipeline in this block
One thing that jumps out is that we're adding handlers before "handler" (which is added above). Could that be re-written as the following where it's more of a simple chaining of handlers?
The order of handler is super important, and in this particular block - we really need to replace the handler and restart the processing again. The whole kind of purpose of that is to process the upgrade request first and than run the original request as it have been processed the normal way.
Even better, if we know that ctx.name() is the last handler in the pipeline (this handler was just added via an addLast call so I think it should be), then you can just add the new handlers via addLast calls, which I find is the simplest way to construct a pipeline.
The ctx.name() is the current handler which we are replacing with decoder_compress, there are a few other handlers added before and/or after (by means of HttpServerUpgradeHandler and CleartextHttp2ServerUpgradeHandler).
There was a problem hiding this comment.
The order of handler is super important
Understood. I'm trying to see if there's a more straightforward way to achieve the desired order so that the actual order is more apparent/easier to understand when reading the code. It looks to me light we add "handler" to the pipeline, then 10 lines later start adding handlers before it. Seems like that could all happen together, and potentially invert the order of adding them so that you don't have to mix "addAfter" and "addBefore".
There was a problem hiding this comment.
I think in general it is possible to rewrite the pipeline configuration a bit, it took me a while to understand why some handlers are either not invoked or invoked when they shouldn't, luckily we have test for it now :-) (not like affraid to touch it but it took me really a lot of time today to troubleshoot) :-)
There was a problem hiding this comment.
Fair enough...I did start this comment with "apologies in advance" :)
There was a problem hiding this comment.
Fair enough...I did start this comment with "apologies in advance" :)
Thanks a lot for review
CHANGELOG.md
Outdated
| - Fix a bug on handling an invalid array value for point type field #4900([#4900](https://github.com/opensearch-project/OpenSearch/pull/4900)) | ||
| - [BUG]: Allow decommission to support delay timeout ([#4930](https://github.com/opensearch-project/OpenSearch/pull/4930)) | ||
| - Fix failing test: VerifyVersionConstantsIT ([#4946](https://github.com/opensearch-project/OpenSearch/pull/4946)) | ||
| - [BUG]: Allow decommission to support delay timeout [#4930](https://github.com/opensearch-project/OpenSearch/pull/4930)) |
There was a problem hiding this comment.
Sorry, "extra line" referred to this "Allow decommission..." line which shouldn't come in as a part of this PR
There was a problem hiding this comment.
Oh right, sorry about that, removed :)
| final ChannelPipeline pipeline = ctx.pipeline(); | ||
| pipeline.addAfter(ctx.name(), "handler", getRequestHandler()); | ||
| pipeline.replace(this, "aggregator", aggregator); | ||
| pipeline.replace(this, "decoder_compress", new HttpContentDecompressor()); |
There was a problem hiding this comment.
Fair enough...I did start this comment with "apologies in advance" :)
|
@andrross thanks a lot for review |
Gradle Check (Jenkins) Run Completed with:
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #4944 +/- ##
============================================
- Coverage 71.37% 71.37% -0.01%
- Complexity 58338 58352 +14
============================================
Files 4689 4689
Lines 277022 277000 -22
Branches 40315 40311 -4
============================================
- Hits 197718 197698 -20
+ Misses 63304 63277 -27
- Partials 16000 16025 +25 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Gradle Check (Jenkins) Run Completed with:
|
Gradle Check (Jenkins) Run Completed with:
|
Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
Signed-off-by: Andriy Redko <andriy.redko@aiven.io>
Gradle Check (Jenkins) Run Completed with:
|
Signed-off-by: Andriy Redko andriy.redko@aiven.io
Description
Fixed compression support for h2c protocol (upgrade handler). There were 2 issues (quite nasty ones, to be fair):
decoder_compresshandler was run afteraggregatorand was not able to decode the requestencoderis not needed, it is already present in theHttpServerCodecconfigured beforeWhy our tests did not catch it: the default
CloseableHttpAsyncClientdoes not support compression out of the box so that applies to RestClient and RestHighLevelClient which are used for all kind of tests.To check the compression works on both sides, crafting the request using
CloseableHttpClientinstead which uses compression by default (or 3rd party clients like https://github.com/opensearch-project/opensearch-go).Issues Resolved
Closes opensearch-project/opensearch-go#163
Check List
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.