[ 
https://issues.apache.org/jira/browse/CXF-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Papp István Péter resolved CXF-6228.
------------------------------------
       Resolution: Fixed
    Fix Version/s: 2.7.15
                   3.0.4

I'm not if I should be the one who's doing this, but since the fix has already 
been committed I guess I'll resolve the issue.

> Using XSLTFeature with large messages creates unremovable temporary files
> -------------------------------------------------------------------------
>
>                 Key: CXF-6228
>                 URL: https://issues.apache.org/jira/browse/CXF-6228
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.0.3
>            Reporter: Papp István Péter
>            Assignee: Akitoshi Yoshida
>            Priority: Minor
>             Fix For: 3.0.4, 2.7.15
>
>         Attachments: bug6228reproduction.zip
>
>
> Using the XSLT transformation feature causes the outgoing message to use a 
> CachedOutputStream object. If the size of the message is above the configured 
> threshold, a temporary file will be created to store the message on the disk; 
> however, this file is not deleted after the message is sent.
> Based on info available on similar problems encountered with 
> CachedOutputStream and attachments, I tried using an interceptor in the 
> SETUP_ENDING phase to close the stream manually - this, however, did not work 
> because even after closing the stream, the "streamList" variable was not 
> empty, which resulted in the closing logic skipping file deletion in the 
> "maybeDeleteTempFile" method. Attempts to delete the file directly also fail 
> for obvious reasons.
> Some (sometimes all, not sure what makes the difference) of the temporary 
> files are removed during a clean server shutdown, but since this is a rare 
> event in production environments, it does not really solve the problem. 
> (Actually, the issue was discovered when the temp files filled the disk 
> completely on a production server.)
> The only viable workaround I found so far was to set the CachedOutputStream 
> threshold high enough to avoid caching the data to disk altogether.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to