OutgoingChainInterceptor "cxf.io.cacheinput" property

[Adam T Anderson <at...@us.ibm.com>]

Hi all,

I'm working with our performance team to investigate potential performance
improvements in CXF. One area that we identified was the
AbstractHTTPDestination.flushHeaders method. We are caching the request
inputstream every time which is causing a performance bottleneck.

Looking further, I found that we are setting the "cxf.io.cacheinput"
property in OutgoinChainInterceptor with the following comment:

        //if we get this far, we're going to be outputting some valid
content, but we COULD
        //also be "echoing" some of the content from the input.   Thus, we
need to
        //mark it as requiring the input to be cached.

I'm trying to understand the use case where we would be "echoing" the input
content and if we could detect that we needed to cache the input instead of
caching it every time? Would a user creating a ContainerResponseFilter
configured for the POST_INVOKE phase that reads from the input stream
recreate the scenario?

I ran the TCK and the jaxws/jaxrs CXF systests after removing the
cacheInput() method to test for any breaks and no tests failed.

Thanks,
Adam Anderson
IBM Websphere

Re: OutgoingChainInterceptor "cxf.io.cacheinput" property

[Daniel Kulp <dk...@apache.org>]

It’s been a LOONG time since I looked into that code, but I believe the main cases that required that included:


1) One-way’s (possibly with ws-addressing) as the 200 accepted need to be sent back, but the endpoint would not have been invoked yet.   However, this use case may no longer be valid as the OneWayProcessorInterceptor will now trigger the caching if needed.

2) The JAX-WS TCK soap w/ attachment tests - this was the original one as the TCK just echos back the attachments.   Since CXF will default to streaming the attachments, if we didn’t cache the last one, it may not be available to echo back.   If that test is now passing, it may be due to some other change in CXF that now triggers that caching.   Not really sure.  

3) “Filtering” services that would take the InputStream and echo it back to the client while applying some level of filtering.   

4) Async services that may return a result to the client (maybe even a 100 continue) while still processing the input stream.   I THINK various async services case may fall into this, but I’m not really sure.   Again, it’s been a while.


Dan


> 
> I'm working with our performance team to investigate potential performance
> improvements in CXF. One area that we identified was the
> AbstractHTTPDestination.flushHeaders method. We are caching the request
> inputstream every time which is causing a performance bottleneck.
> 
> Looking further, I found that we are setting the "cxf.io.cacheinput"
> property in OutgoinChainInterceptor with the following comment:
> 
>        //if we get this far, we're going to be outputting some valid
> content, but we COULD
>        //also be "echoing" some of the content from the input.   Thus, we
> need to
>        //mark it as requiring the input to be cached.
> 
> I'm trying to understand the use case where we would be "echoing" the input
> content and if we could detect that we needed to cache the input instead of
> caching it every time? Would a user creating a ContainerResponseFilter
> configured for the POST_INVOKE phase that reads from the input stream
> recreate the scenario?
> 
> I ran the TCK and the jaxws/jaxrs CXF systests after removing the
> cacheInput() method to test for any breaks and no tests failed.
> 
> Thanks,
> Adam Anderson
> IBM Websphere

-- 
Daniel Kulp
dkulp@apache.org <ma...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog>
Talend Community Coder - http://talend.com <http://coders.talend.com/>