cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin (JIRA)" <>
Subject [jira] [Commented] (CXF-6826) Cache MediaTypeHeaderProvider.valueOf(String mType) results
Date Thu, 10 Mar 2016 15:08:40 GMT


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 :-)


> Cache MediaTypeHeaderProvider.valueOf(String mType) results
> -----------------------------------------------------------
>                 Key: CXF-6826
>                 URL:
>             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

View raw message