[
https://issues.apache.org/jira/browse/CXF-6837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15226152#comment-15226152
]
Sergey Beryozkin edited comment on CXF-6837 at 4/5/16 12:24 PM:
----------------------------------------------------------------
1. "handleMapper doen't check the genericType of the messagebody can be
addressed in another jira, not cache relavant."
No - it is very much cache relevant. handleMapper doen't check the genericType
yet - but it must and once it does check it it starts being relevant to the
cache.
3. Why keep providers which have returned 'false' in the cache - I see no point
in that. Therefore it has to be a single value - while the provider keeps
returning true in isReadable/isWriteable - it stays. Otherwise it goes. If we
keep the list of values then assuming we have 10 providers which will return
true/false depending on the context then we will end up with all of them
migrating to the cache and staying there.
4. What is the point of delaying the creation of the cache till the providers
are required ? IMHO it does not buy us anything.
5. The caches must be controlled - I will take care of it
was (Author: sergey_beryozkin):
1. "handleMapper doen't check the genericType of the messagebody can be
addressed in another jira, not cache relavant."
No - it is very much cache relevant. handleMapper doen't check the genericType
yet - but it must and once it does check it it starts being relevant to the
cache.
3. Why keep providers which have returned 'false' in the cache - I see no point
in that. Therefore it has to be a single value - while the provider keeps
returning true in isReadable/isWriteable - it stays. Otherwise it goes. If we
keep the list of values then assuming we have 10 providers which will return
true/false depending on the context then we will end up with all of them
migrating to the cache and staying there. In fact - when it is really then we
can have more than one provider for the same media type and class ? I do not
think this has been TCK tested - CXF code returns the 1st matching MBR or MBW
(which was indeed TCK tested).
4. What is the point of delaying the creation of the cache till the providers
are required ? IMHO it does not buy us anything.
5. The caches must be controlled - I will take care of it
> 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)
