Update hibernate core #7451
Open
Update hibernate core #7451
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![renovate[bot]](https://avatars.githubusercontent.com/in/2740?s=60&v=4){kind=small}
|
Kudos, SonarCloud Quality Gate passed!
|
renovate
bot
force-pushed
the
renovate/hibernate-core
branch
7 times, most recently
from
7d530df to
840f80e
Compare
renovate
bot
force-pushed
the
renovate/hibernate-core
branch
3 times, most recently
from
f933cc5 to
a9cc52f
Compare
renovate
bot
force-pushed
the
renovate/hibernate-core
branch
3 times, most recently
from
61d5872 to
b5cbec8
Compare
renovate
bot
changed the title
renovate
bot
force-pushed
the
renovate/hibernate-core
branch
14 times, most recently
from
519bff4 to
9bb1570
Compare
#9128) This PR replaces the HttpStreamsServerHandler, HandlerPublisher, HttpRequestDecoder and HttpResponseDecoder by a new PipeliningServerHandler. PipeliningServerHandler directly receives netty HttpMessages, combines them into a FullHttpRequest or StreamedHttpRequest, and passes them on to a handler. It also takes care of pipelining, so that the responses for different requests are sent in the same order those requests came in, which fixes some old bugs in RoutingInboundHandler. PipeliningServerHandler optimizes the read and write operations. Concurrent reads are handled safely, removing the need for the FlowControlHandler even in the streaming case. Flushes are delayed until readComplete, so that multiple requests in the same TCP packet can be responded to in a single TCP packet as well. The biggest performance win comes from message aggregation, however. While PipeliningServerHandler can handle a FullHttpRequest from FULL_CONTENT, it can also do some basic aggregation on its own. Small requests commonly have the HttpRequest and HttpContent come in in the same read call. PipeliningServerHandler will "hold back" the HttpRequest until readComplete to merge it with the HttpContent if available, into a FullHttpRequest. This gives a performance benefit downstream, it's actually ~600ns faster in FullHttpStackBenchmark by default than 4.0.x with FULL_CONTENT. The big advantage over FULL_CONTENT is that this aggregation is always enabled and is not a compatibility issue. Large requests will still safely fall back to StreamedHttpRequest. FULL_CONTENT is still useful for customizers that want to observe the full HTTP message, however, and may give some perf benefit for medium-sized request bodies. The reason this PR is so big is that now, many small requests are processed using the FullHttpRequest APIs. There are many subtle differences in this code path. For example, form items are parsed immediately and then passed to FormRouteCompleter, where previously parsing and processing would be interleaved (the reactive code path). This exposed some bugs because it moves some `if (refCnt > 0) release` calls to before the processing.
This fails in 4.0.0 as the response is OK
Merge 3.9.x, fix TCK test and document breakage
* Use StringIntMap for propertyIndexOf This patch replaces the propertyIndexOf method generated for each introspection with an optimized String->int map. For cases where propertyIndexOf may be called for many different types, this avoids a megamorphic call site (benchmark about 5x as fast). On the other hand, for cases where propertyIndexOf is only called with one or two different introspections at the same call site, this is slightly slower (benchmark about 0.65x as fast). imo this tradeoff is acceptable, because the speedup for megamorphic case far exceeds the slowdown for the monomorphic case. Monomorphic call sites should also be less "hot" in practical code, so performance of propertyIndexOf matters less. Finally, the absolute performance difference is quite small for the monomorphic case, in the benchmark it's 70ns so roughly 1.5ns per item, while for the megamorphic case it's roughly 30ns per item. Benchmark results, before this change: Benchmark (itemCount) (typeCount) Mode Cnt Score Error Units PropertyIndexBenchmark.test 50 1 avgt 5 115.205 ± 1.016 ns/op PropertyIndexBenchmark.test 50 2 avgt 5 118.745 ± 0.106 ns/op PropertyIndexBenchmark.test 50 3 avgt 5 832.091 ± 8.271 ns/op After this change: Benchmark (itemCount) (typeCount) Mode Cnt Score Error Units PropertyIndexBenchmark.test 50 1 avgt 5 183.315 ± 0.435 ns/op PropertyIndexBenchmark.test 50 2 avgt 5 162.453 ± 0.881 ns/op PropertyIndexBenchmark.test 50 3 avgt 5 162.690 ± 1.004 ns/op * Use array instead of list --------- Co-authored-by: Denis Stepanov <[email protected]>
We had to disable Predictive Test Selection and Test Distribution for Kotest tests as Kotest was unsupported. As of micronaut-test-4.0.0-M2, we use a supported version of Kotest 5, so this pr reverses #8612 To re-enable these Gradle features
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
renovate
bot
force-pushed
the
renovate/hibernate-core
branch
from
1cffbaa to
81c9f5c
Compare
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
6.1.6.Final->6.2.5.Final5.5.9.Final->5.6.15.FinalRelease Notes
hibernate/hibernate-validator
v6.2.5.FinalCompare Source
v6.2.4.FinalCompare Source
v6.2.3.FinalCompare Source
v6.2.2.FinalCompare Source
v6.2.1.FinalCompare Source
v6.1.7.FinalCompare Source
hibernate/hibernate-orm
v5.6.15.FinalCompare Source
v5.6.14.FinalCompare Source
v5.6.13.FinalCompare Source
v5.6.12.FinalCompare Source
v5.6.11.FinalCompare Source
v5.6.10.FinalCompare Source
v5.6.9.FinalCompare Source
v5.6.8.FinalCompare Source
v5.6.7.FinalCompare Source
v5.6.6.FinalCompare Source
v5.6.5.FinalCompare Source
v5.6.4.FinalCompare Source
v5.6.3.FinalCompare Source
v5.6.2.FinalCompare Source
v5.6.1.FinalCompare Source
v5.6.0.FinalCompare Source
Configuration
📅 Schedule: Branch creation - "every weekend" in timezone Europe/Prague, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate. View repository job log here.