-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Support compression for reactive routes and resteasy reactive #24558
Conversation
What's missing:
|
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.
LGTM! I just had a few questions, but it looks great (exactly what I had in mind).
What I like is that it will ease the integration of other compression mechanism once they will be supported by the engine.
* List of media types for which the compression should be enabled automatically, unless declared explicitly via {@link Compressed} or {@link Uncompressed}. | ||
*/ | ||
@ConfigItem(defaultValue = "text/html,text/plain,text/xml,text/css,text/javascript,application/javascript") | ||
public Optional<List<String>> compressMediaTypes; |
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.
Are this list also used when you return a response from resteasy reactive?
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.
Yes, it should be. Although it's not tested yet. It's however not used for resteasy classic.
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.
It's tested now.
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.
I wonder if we should honor this config property for reasteasy-classic or ignore it completely? Currently, reasteasy-classic has a separate config and annotation.
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.
For now this config property and enableCompression
is just ignored, i.e. it has no effect on http compression of resteasy classic endpoints.
/** | ||
* The compression level used when compression support is enabled. | ||
*/ | ||
public OptionalInt compressionLevel; |
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.
Should we have both enableCompression and compressionLevel? Should we infer "enable" if the level is set?
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.
Hm, I don't think it's convenient to say: use quarkus.http.compression-level=6
to enable compression with the default compression level. In other words, enable=true
should work in most cases and is simple and expressive.
@@ -12,6 +13,10 @@ | |||
|
|||
Limits limits(); | |||
|
|||
boolean enableCompression(); | |||
|
|||
Set<String> compressMediaTypes(); |
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.
shouldn't it be compressed
?
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.
Well, we have HttpConfiguration.compressMediaTypes
so I just wanted to keep this aligned. HttpConfiguration.compressedMediaTypes
is ok though. Should I rename both?
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.
FTR I used the verb (compress
) to keep consistency with enableCompression
..
...loyment/src/test/java/io/quarkus/resteasy/reactive/server/test/compress/CompressionTest.java
Show resolved
Hide resolved
171a9ba
to
c38c2bd
Compare
|
||
@Override | ||
public void handle(RoutingContext context) { | ||
context.addEndHandler(new Handler<AsyncResult<Void>>() { |
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.
To avoid that interception, we could imagine moving that code directly to the HTTP Server "root" request handler. Just an idea if we see a large decrease in terms of performance.
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, so this handler should only be used if compression is enabled and I think that there will be other much more expensive calls in such case ;-)
247e06b
to
ef05d35
Compare
I believe that this PR is ready for review. Note that it's a breaking change in the sense that previously |
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.
LGTM
The |
This comment has been minimized.
This comment has been minimized.
Ah, |
@FroMage @gsmet could you pls take a look at the functionality description and share your opinion? ;-) |
Sorry I was busy on other stuff. TBH, I'm on the verge of including it for 2.8.0.Final if we get it merged before this evening. But maybe we can backport it later once people ask for it. |
No problem. I was just curious if it meets your expectations.
+1 |
👍🏼 |
It's great! |
That's just awesome, bravo! |
Coming back to this: Is there a good reason for making compression a runtime property? |
@geoand speaking a bit about the future. At the moment, we only support one compression algorithm. This "set" will soon be expanded, and the other algorithms may (very likely) require native bits. We would need to pre-package the native bits (user config, of course). Following that logic, I would say that making it a build time property would make sense. If compression is disabled, it will avoid adding the native libs into the native executable and also tweak substitutions. |
I agree. If @mkouba also agrees, I'll fix it and hopefully get the change in 2.8.1 |
Yeah it seems more reasonable to me too. For now I haven’t backported this work. But we could backport it if we all agree it’s worth it. |
Hm... I see that |
Yes, +1 too. As said, that change would happen eventually when we will be able to integrate Vert.x 4.3. |
#24984 is the PR moving the configuration to build time |
I don't think it's a good idea to backport a breaking change. Anyway, it probably makes sense to move the config property to the build time. Although it makes the config a bit inflexible, i.e. you'll need to rebuild your app in order to enable compression. |
Indeed, but what is the legitimate case for having differ between deployments of an artifact? I don't think there is one... |
I'm not following ;-). What I'm talking about is the use case where you build an app and in one deployment you want to enable compression because the data sent over the network are expensive and in other deployment the CPU is expensive but you don't care about the number of bytes sents. Right now, you can use the same app and change the config property. After this change, you'll have to build two versions of the app. |
We are saying the same thing :) What I am asking is if there a real scenario were one would actually do that... |
I have no idea.. |
Functionality:
quarkus.http.enable-compression=true
then an HTTP response body of a static resource, reactive route and resteasy-reactive resource method is compressed if:@io.quarkus.vertx.http.Compressed
, ORquarkus.http.compress-media-types
(text/html,text/plain,text/xml,text/css,text/javascript,application/javascript
by default).@io.quarkus.vertx.http.Uncompressed
Impl. notes:
quarkus.http.enable-compression=true
then every response has theContent-Encoding: identity
header set by default; this effectively disables the compressionServerRestHandler
that is added to the chain for any resource method unless@Uncompressed
is used@Uncompressed
is usedNote that it's a breaking change in the sense that previously
quarkus.http.enable-compression=true
enabled compression for every HTTP response which is not the case anymore. The configuration property is effectively ignored forreasteasy-classic
endpoints and routes registered manually.