Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: domain of sberyozkin@gmail.com designates
 209.85.215.172 as permitted sender)
Message-ID: <518D0F92.2070205@gmail.com>
Date: Fri, 10 May 2013 16:17:38 +0100
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: dev@cxf.apache.org
Subject: Re: More cache in jaxrs impl
References: 
 <CACLE=7OSoZiO0+m-oUhKUyJiigexf+J3G1t-QRZNMQQcSoj3WQ@mail.gmail.com>
 <518CC2D9.7060204@gmail.com>
 <CACLE=7MjXNaYBvsfrsHDKh=d-GBm8+ZjZHR9Ci++_p2Cnjxg8g@mail.gmail.com>
In-Reply-To: 
 <CACLE=7MjXNaYBvsfrsHDKh=d-GBm8+ZjZHR9Ci++_p2Cnjxg8g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

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 
moment.
I was thinking more about the servlet level optimization
Cheers, Sergey


> Le 10 mai 2013 11:51, "Sergey Beryozkin"<sberyozkin@gmail.com>  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
>>
>