[
https://issues.apache.org/jira/browse/CXF-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15228578#comment-15228578
]
Sergey Beryozkin edited comment on CXF-6837 at 4/6/16 4:31 PM:
---------------------------------------------------------------
Which makes me think: the only reason we have a list of values in the cache is
that some TCK tests assert that a given provider can return either false or
true from isReadable/isWriteable which is probably a 1% use case.
You are right that having a list in this case is important but we can not avoid
checking handleMapper if we have a list which kind of defeats the purpose of
the cache in the 1st place.
As such I propose the following:
- the cache is optional and is enabled in the production if the developers know
their providers will return 'true'/'false' consistently for a given MediaType
plus Class combination (99% case)
- the cache has a single value per Key - the runtime guarantees the nearest
provider is selected for this MediaType plus Class before it is added to the
cache
- if the provider is available in the cache - it is not checked again at all
and is immediately returned.
Here I can see the possible benefits
was (Author: sergey_beryozkin):
Which makes me think: the only reason we have a list of values in the cache is
that some TCK tests assert that a given provider can return either false or
true from isReadable/isWriteable which is probably a 1% use case.
You are right that having a list in this case is important but we can not avoid
checking handleMapper if we have a list which kind of defeats the purpose of
the cache in the 1st place.
As such I propose the following:
- the cache is optional and is enabled in the production if the developers know
their providers will return 'true'/'false' consistently for a given MediaType
plus Class combination (99% case)
- the cache has a single value per Key
- if the provider is available in the cache - it is not checked again at all
and is immediately returned.
Here I can see the possible benefits
> Add cache for MessageBodyReader/Writer
> --------------------------------------
>
> Key: CXF-6837
> URL: https://issues.apache.org/jira/browse/CXF-6837
> Project: CXF
> Issue Type: Improvement
> Components: JAX-RS
> Affects Versions: 3.1.5, 3.0.8
> Environment: windows
> Reporter: Neal Hu
> Fix For: 3.2.0
>
> Attachments: ListAProvider.java, ListBProvider.java,
> ProviderCache.java, ProviderFactory.patch, Resource.java, beans.xml, web.xml
>
>
> CXF selects the msgBodyReader/writer in the reader/writer list for every
> request, which has big impact to the performance. Jersey also has the cache
> in
> org.glassfish.jersey.message.internal.MessageBodyFactory._getMessageBodyReader(...).
> I have tried add the cache for CXF in ProviderFactory and been proved that
> it has improved 7-8% for json requests in JMeter. Please let me know if you'd
> like me to add the enhancement for CXF. Thanks.
> http://cxf.547215.n5.nabble.com/MessageBodyReader-Writer-cache-td5767091.html
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
