I've added a comment to CXF-6837, wondering how much of the time that
would be saved here is actually already addressed by the CXF-6826 patch
(which I believe should be helping here).
Cheers
Alessio
Il 22/03/2016 10:14, Sergey Beryozkin ha scritto:
Hi Neal
I think it can be risky in its own way, and if it is to be done
properly than the strategies for dealing with the in memory cache
should be pluggable.
I'm also assuming that a composite key has to be involved, everything
that is passed to isWriteable/isReadable. Because this is where the
final solution is often made, even after the runtime has statically
determined the best candidate.
But having the option to optimize it can be useful in some cases for
sure,
Can you please attach an initial patch to CXF-6837 for us to look at ?
Cheers, Sergey
On 22/03/16 06:11, neal hu wrote:
Hi,
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.
Neal
--
View this message in context:
http://cxf.547215.n5.nabble.com/MessageBodyReader-Writer-cache-tp5767091.html
Sent from the cxf-dev mailing list archive at Nabble.com.
--
Alessio Soldano
Web Service Lead, JBoss
