[
https://issues.apache.org/jira/browse/CXF-6826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15189401#comment-15189401
]
Sergey Beryozkin commented on CXF-6826:
---------------------------------------
Hi Alessio,
Sorry, forgot it was accessed statically too. The reason was that going via
MediaType.valueOf() was causing issues in containers with multiple JAX-RS
stacks loaded and we had quite a few such cases :-)
Well, I'd like to avoid the uncontrolled growth of this map. It is true in many
simple services there will be few media types only in the whole container, but
if won't restrict then the users who implement HTTP proxies with CXF or do
something else with complex media types will start reporting leaks.
Clearing the whole map should it reach some threshold is really a safety net
:-). I guess the media type parsing is not really expensive in simple cases,
few index checks, no reg expressions, two index based splits. So the map temp
going empty would only get back the callers to the current level of the parsing
speed which may be not too bad ?
Would be interesting to get some basic speed checks, with & without the map :-)
thanks
> Cache MediaTypeHeaderProvider.valueOf(String mType) results
> -----------------------------------------------------------
>
> Key: CXF-6826
> URL: https://issues.apache.org/jira/browse/CXF-6826
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Reporter: Alessio Soldano
>
> MediaTypeHeaderProvider.valueOf(String mType) ends up being called a lot with
> the same parameter values, as those are basically the contents of the
> @Produce annotations on resources. Each request ends up into the same
> invocation, which is cpu and memory intensive.
> It might make sense to add a map in the MediaTypeHeaderProvider to store the
> result of the static valueOf method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
