cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <>
Subject Re: More cache in jaxrs impl
Date Fri, 10 May 2013 15:17:38 GMT
Hi Romain
On 10/05/13 11:03, Romain Manni-Bucau wrote:
> Hi,
> It doesnt urge (and im cleaning up tomee after the owb update which broke a
> bunch of stuff for weeks so no real time ATM ;) but saw it several times
> integrating cxf in tomee and each time i tested/debugged doing a POST data
> provisioning i was womdering why it was so complicated since it was the
> same than previous query. Finally found time to start discussing it here :)
> What would be great: ok for a param but on server factory bean too to let
> tomee activate it if possible, backported in 2.6.x otherwise tomee 1.x will
> not be able to be certified :(
> Then the key of the cache should only be composed of the fixed uri, http
> method, consume  and produce media type no? Kind of light
> OperationResourceInfo

We'll have to think carefully about it; at the moment I'm not sure 
if/how it will work, perhaps a limited optimization is possible, I'm 
thinking more about eliminating the possibly redundant checkups after a 
first candidate has been found, etc or when the resource has such 
operations that it can become safe to cache, I'm not sure really at the 
I was thinking more about the servlet level optimization
Cheers, Sergey

> Le 10 mai 2013 11:51, "Sergey Beryozkin"<>  a écrit :
>> Hi Romain
>> On 10/05/13 10:27, Romain Manni-Bucau wrote:
>>> Hi guys
>>> Excepted if i didnt get the code right it seems the endpoint resolution is
>>> done each time in rs impl.
>>> Couldnt it be cached a bit more? (i think to fixed uri which is common for
>>> not GET cases). In such a case cxf could skip a bunch of logic no?
>>> The idea is to get perf closer to servlets since jaxrs is close to them (i
>>> never said it was the same ;)
>>> Wdyt?
>>>   I think it is a not a bad idea at all. We can try to experiment with it
>> by introducing an optional servlet parameter so that we can always resort
>> to the existing tried and tested approach if needed. The only thing it can
>> be tricky to do completely right.
>> For SOAP endpoints it can be more predicatable, for RS endpoints a bit
>> less, as we effectively have a stem match. Please start experimenting if
>> you need it fast, I'm all into JAX-RS 2.0 work now with some other planned
>> work to do, but can help with/look into it later on too.
>> Thanks, Sergey

View raw message