[
https://issues.apache.org/jira/browse/CXF-5891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessio Soldano updated CXF-5891:
---------------------------------
Attachment: headers-perf.diff
> ReadHeadersInterceptor performances improvement
> -----------------------------------------------
>
> Key: CXF-5891
> URL: https://issues.apache.org/jira/browse/CXF-5891
> Project: CXF
> Issue Type: Improvement
> Components: JAX-WS Runtime
> Reporter: Alessio Soldano
> Attachments: headers-perf.diff
>
>
> It has been noticed by running some benchmarks that CXF performances could
> possibly be improved for dealing of SOAP messages with no SOAP headers. The
> ReadHeadersInterceptor builds a DOM Document for each SOAP message; while
> that's fine if there actually are headers in the message, it looks like a
> waste of time and memory if the message has no header. The document has big
> memory footprint, which ends up in high heap memory pressure when running our
> benchmarks. The final result is performance penalty.
> I've been reasoning on a solution for starting parsing the message with StAX
> (envelope and header part only, as per the PartialXMLStreamReader already in
> place), buffering the stream events and optionally generating the DOM doc if
> a soap header is actually found.
> The initial patch is attached, some local tests show that the
> ReadHeadersInterceptor performance (processing time) is ~*16%* better for
> messages with no headers and ~*3%* worse for messages with 2 not trivial
> headers.
> Ideally, we could switch this patched processing method by default and give
> the user a mean for disabling it (prop in the message/exchange ?). Moreover,
> we could automatically disable it whenever WS-* interceptors are installed in
> the chain (as WS-Security, WS-Addressing, WS-RM, etc. all imply headers being
> added to the messages).
> In terms of memory allocation, the patched version is dramatically better for
> messages with no headers.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
