Affects: Spring Boot 2.0.1 RELEASE, Spring Framework 5.0.5 RELEASE

Issue Description: In a highly concurrent environment(Average 20K transaction per minute) it was observed that 100% of the processing time is being taken by MimeType.checkParameters()

Attached screenshot of the dynatrace

Wondering if this is something related to #25043 / #24886.

Any solution/suggestion would be helpful

Comment From: quaff

Please try latest 5.2.8.RELEASE.

Comment From: bclozel

I don't see a screenshot attached to your bug report. We've made significant performance improvements in the latest releases in this space.

Is the behavior you're seeing unusual? With which Spring Framework version this was behaving as expected?

I don't this this is related to the issues you're pointing to since the changes were introduced in Spring Framework 5.2 with #22340.

Maybe the media types used by your application (or sent by the clients) are a bit unusual and could explain this performance issue?

Comment From: arajitsamanta

@bclozel Please see below

Spring Version Spring Boot 2.0.1 RELEASE, Spring Framework 5.0.5 RELEASE

Content Type Headers Content Type: application/json Accept: text/html, image/gif,image/jpeg, ;q=.2, /* ; q=.2;

Dynatrace Screenshot Spring Issue_Bug

Comment From: bclozel

Is the behavior you're seeing unusual? With which Spring Framework version this was behaving as expected?

Could you answer this question as well? The call stack we're seeing here is not unusual. We've made performance improvements in recent versions about that, but I don't remember a change there around this version.

Comment From: arajitsamanta

@bclozel I have not tried with any other version of either spring boot or spring framework as that requires lot of change. First i want to understand why this is happening and if this is expected behavior.

We have been observing higher percentage(>50%) of contribution of that particular method call towards overall processing time. Lets say overall processing time is 1 sec for a single request. More than 50% being spent on that method invocation which seems to be very unusual.

Is that something expected with spring 5.0.5 version ? IS the solution is to only upgrade to latest spring versions?

Comment From: bclozel

It all depends on the actual processing time of such requests - if it's really short, let's say a few milliseconds, then it might not be unexpected.

As I've said earlier, we've made significant improvements in recent versions in that area - improvements that we cannot backport in earlier versions for stability reasons. Without knowing where to look for, especially in which version this performance problem appeared, I cannot really make progress on this issue: I would just go down the path I've already worked on, which is caching the parsing of media types.

Ideally, changing the Spring Framework version (changing dependency version or going back into your project's history) and and checking whether the problem is still there would help narrowing down the problem. Better, maybe you can reproduce this performance problem on a new sample project?

The problem is that at this point we don't even know if this behavior was there to begin with, hence why the performance work we did recently - or if there's an unrelated change in the 5.0.x line.

Comment From: spring-projects-issues

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

Comment From: arajitsamanta

I tried to re-produce but not being able to. This issue can be closed for now.

Comment From: bclozel

Thanks for checking!

Comment From: HaleLu

I think I found out the truth. It's a bug in jdk. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8137184

else if (this.queue.remove(key)) {
    this.queue.add(key);
    return this.cache.get(key);
}

Calling ConcurrentLinkedQueue#remove in parallel will cause memory leaks

Comment From: bclozel

@HaleLu it's been fixed and released with a bunch of JDK versions. Unless you're running an old JDK this shouldn't be a problem. See https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8054446

Comment From: HaleLu

@bclozel i know. I just want to explain why this is happening for @arajitsamanta