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.

Sign up for GitHub

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

Jump to bottom

ContentCachingRequestWrapper may allocate too much memory #32987

Closed
bclozel opened this issue Jun 7, 2024 · 0 comments
Closed

ContentCachingRequestWrapper may allocate too much memory #32987

bclozel opened this issue Jun 7, 2024 · 0 comments
Assignees
@bclozel
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: bug A general bug
Milestone
6.1.9

Comments

@bclozel
Copy link
Member

bclozel commented Jun 7, 2024

See 0970b1d#r142863433
@bclozel bclozel added in: web Issues in web modules (web, webmvc, webflux, websocket) type: bug A general bug labels Jun 7, 2024
@bclozel bclozel added this to the 6.1.9 milestone Jun 7, 2024
@bclozel bclozel self-assigned this Jun 7, 2024
bclozel referenced this issue Jun 7, 2024
@bclozel
Optimize ContentCachingRequestWrapper allocation
0970b1d 
This commit builds on top of changes made in gh-29775 and gh-31737.
Before this change, we would allocate several byte arrays even in cases
of known request size. This could decrease performance when getting the
cached content as it requires merging several arrays and data is not
colocated in memory.

This change ensures that we create a `FastByteArrayOutputStream`
instance with the known request size so that the first allocated segment
can contain the entire content.
If the request size is not know, we will default back on the default
allocation size for the `FastByteArrayOutputStream`.

Closes gh-31834
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bclozel bclozel

Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: bug A general bug
Projects
None yet
Milestone
6.1.9
Development

No branches or pull requests
1 participant
@bclozel