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.

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

ResponseEntity objects are accumulated in ConcurrentReferenceHashMap #28232

Closed
KangChanSong opened this issue Mar 25, 2022 · 4 comments
Closed
Assignees
Labels
in: messaging Issues in messaging modules (jms, messaging) in: web Issues in web modules (web, webmvc, webflux, websocket) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@KangChanSong
Copy link

KangChanSong commented Mar 25, 2022

Affects: 5.2.8


First of all, sorry for my bad english. If you're hard to understand my sentence, please comment

Ive been testing my team's project and monitoring it with scouter APM.

And found that "used heap" keeps going high whenever I call an different API .

I debugged and found that Spring accumulates ResponseEntity in ConcurrentReferenceHashMap of ResolvableType.cache.

It puts the whole response body of each ResponseEntity in ConcurrentReferenceHashMap which is static.

I believe that the Spring developers intended it for some reasons but I cannot find any even if I googled a lot.

If It it's an issue , please fix this.
if it's not, I would very appreciate you for giving me some explanation why Spring accumulates the ResponseEntity objects
even if it has a BIG BIG body.

Thank you.
Best Regard.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 25, 2022
@snicoll
Copy link
Member

snicoll commented Mar 25, 2022

@KangChanSong the cache that you mention is a cache of resolvable types. ResolvableType does not have a link to ResponseEntity so I am afraid I don't understand the report. Can you point to the code that you believe is caching ResponseEntity objects?

@snicoll snicoll added the status: waiting-for-feedback We need additional information before we can continue label Mar 25, 2022
@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Mar 26, 2022
@bclozel bclozel added status: waiting-for-feedback We need additional information before we can continue and removed status: feedback-provided Feedback has been provided labels Mar 26, 2022
@KangChanSong
Copy link
Author

KangChanSong commented Mar 28, 2022

This is a stack trace where ResponseEntity object is cached in to ConcurrentReferenceHashMap
스크린샷 2022-03-28 오전 9 21 42

And another screenshot of a ResponseEntity object and its incoming reference tree

스크린샷 2022-03-28 오전 9 18 36

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue labels Mar 28, 2022
@snicoll snicoll added this to the Triage Queue milestone Mar 29, 2022
@snicoll
Copy link
Member

snicoll commented Mar 29, 2022

I can see that we have a MethodParameter implementation, ReturnValueMethodParameter, that keeps a reference to the actual return value. Spring HATEOAS seems to be using ResolvableType#forMethodParameter passing the actual MethodParameter implementation.

If the type is using MethodParameterTypeProvider I can see how that could have the side effect of keeping the return value in the cache there.

@jhoeller
Copy link
Contributor

Indeed, and ReturnValueMethodParameter does not even do anything with the value itself, just obtaining the return value type on demand. Let's change this to a ReturnTypeMethodParameter that just holds on to the pre-determined value type.

@jhoeller jhoeller added in: messaging Issues in messaging modules (jms, messaging) in: web Issues in web modules (web, webmvc, webflux, websocket) type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Mar 29, 2022
@jhoeller jhoeller modified the milestones: Triage Queue, 5.3.18 Mar 29, 2022
@jhoeller jhoeller self-assigned this Mar 29, 2022
@snicoll snicoll removed the status: feedback-provided Feedback has been provided label Mar 29, 2022
@snicoll snicoll modified the milestones: 5.3.18, 5.3.19 Mar 31, 2022
@jhoeller jhoeller added the status: backported An issue that has been backported to maintenance branches label Apr 1, 2022
jhoeller added a commit that referenced this issue Apr 8, 2022
RangerRick pushed a commit to OpenNMS/spring-framework that referenced this issue Jul 26, 2022
RangerRick pushed a commit to OpenNMS/spring-framework that referenced this issue Jul 26, 2022
RangerRick pushed a commit to OpenNMS/spring-framework that referenced this issue Jul 26, 2022
RangerRick pushed a commit to OpenNMS/spring-framework that referenced this issue Jul 26, 2022
RangerRick pushed a commit to OpenNMS/spring-framework that referenced this issue Jul 26, 2022
RangerRick pushed a commit to OpenNMS/spring-framework that referenced this issue Jul 28, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: messaging Issues in messaging modules (jms, messaging) in: web Issues in web modules (web, webmvc, webflux, websocket) status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

5 participants