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

Too many CacheEvaluationContext instances #31580

Closed
liudaac opened this issue Nov 9, 2023 · 4 comments
Closed

Too many CacheEvaluationContext instances #31580

liudaac opened this issue Nov 9, 2023 · 4 comments
Labels
for: stackoverflow A question that's better suited to stackoverflow.com

Comments

@liudaac
Copy link

liudaac commented Nov 9, 2023

Recently, I discovered a phenomenon where there is a large amount of CacheEvaluationContext instances in the jmap histo from my Spring Boot 2.7.15 application. When I examined the creation points in the source code, I found that the creation of this instance is triggered by three methods in CacheOperationContext: canPutToCache, generateKey, and isConditionPassing. The triggering conditions for these methods are StringUtils.hasText(unless), StringUtils.hasText(this.metadata.operation.getKey()), and StringUtils.hasText(this.metadata.operation.getCondition()) respectively. How should I optimize to reduce the number of CacheEvaluationContext instances?

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

snicoll commented Nov 9, 2023

@liudaac you have described a situation but didn't explain how it was a problem. CacheEvaluationContext is a support for SpEL expression handling and shouldn't be costly. We don't keep references to those so they will be garbage collected when the JVM decides it should. Without any description of a concrete problem this issue is not actionable and looks more like a question.

If you meat to ask a question, please use StackOverlfow, as mentioned in the guidelines for contributing, we prefer to use the issue tracker only for bugs and enhancements.

@snicoll snicoll closed this as not planned Won't fix, can't repro, duplicate, stale Nov 9, 2023
@snicoll snicoll removed the status: waiting-for-triage An issue we've not yet triaged or decided on label Nov 9, 2023
@sbrannen sbrannen added the for: stackoverflow A question that's better suited to stackoverflow.com label Nov 9, 2023
@snicoll
Copy link
Member

snicoll commented Nov 17, 2023

In the meantime, we've found something trying to fix an unrelated issue that goes in the direction of the report, see #31617 for more details.

@liudaac
Copy link
Author

liudaac commented Nov 17, 2023

Thank you very much for your attention. We hope the bug can be fixed as soon as possible.

@snicoll
Copy link
Member

snicoll commented Nov 17, 2023

@liudaac if you felt this was a bug, feel free to add a comment. Me closing the issue as not actionable was because I felt this was a question. But that doesn't mean you can't provide more context to change our mind. In this case, we don't feel this is a bug, but it's true that it's putting a bit of unnecessary pressure on GC and that's what the linked issue intends to fix. If you want to make sure whatever issue you've discovered is fixed, please watch the related issue and don't hesitate to comment there if the fix doesn't meet your expectations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: stackoverflow A question that's better suited to stackoverflow.com
Projects
None yet
Development

No branches or pull requests

4 participants