cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Akitoshi Yoshida (JIRA)" <>
Subject [jira] [Commented] (CXF-6228) Using XSLTFeature with large messages creates unremovable temporary files
Date Fri, 30 Jan 2015 10:46:36 GMT


Akitoshi Yoshida commented on CXF-6228:

If a file doesn't get deleted, that means someone is holding the stream (which you have also
found out in observing the non-empty stramList). Can you reproduce this problem is a small
example or you get it only sporadically? If you can reproduce this problem by setting the
threshhold to a very small value, that will help in finding the cause.

> Using XSLTFeature with large messages creates unremovable temporary files
> -------------------------------------------------------------------------
>                 Key: CXF-6228
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 3.0.3
>            Reporter: Papp István Péter
>            Priority: Minor
> 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

View raw message