[
https://issues.apache.org/jira/browse/CXF-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291824#comment-14291824
]
Abel Salgado Romero commented on CXF-6219:
------------------------------------------
Thanks :), that will certainly be usefull in the future. However, currently
we're just trying to solve this doubt to decide if we should disable base64
completely.
Going back to your comment Sergey, afaik the current problem is that since
Base64 travels embedded in the XML, the whole message is parsed at some point,
loading its content into memory. The parser creates several copies of the
message requiring a lot of memory.
That does not happen when dealing with MTOM because the attachment can be
processed separately and is streamed to disc instead of memory. If only the XML
parser could do the same, that is, when an attachment is detected, it should
stream the Base64 to disc while parsing the XML.
> Handling concurrent Base64 files causes memory overflow
> -------------------------------------------------------
>
> Key: CXF-6219
> URL: https://issues.apache.org/jira/browse/CXF-6219
> Project: CXF
> Issue Type: Improvement
> Components: Soap Binding, WS-* Components
> Affects Versions: 2.7.4
> Environment: Production
> Reporter: Abel Salgado Romero
> Labels: documentation
>
> In a previous issue (https://issues.apache.org/jira/browse/CXF-5912) we were
> advised to update CXF version to avoid OOM errors.
> We did so (to 2.74) and the problem was fixed, we also applied a size limit
> of 20MB using the `org.apache.cxf.stax.maxTextLength` property.
> However, the memory consumption in the server is extremely higher than the
> actual data sent, having 1GB of Heap we get OOM sending just 6 concurrent
> requests of 20 MB.
> Reviewing some documents and other JIRA issues, we understand that Base64 is
> not optimized and not recomended. Can you confirm if this is the case or if
> there is a way to optimize how Base64 attachments are processed.
> Otoh, MTOM works like a charm ;)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
