Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Mon, 2 Feb 2015 12:54:34 +0000 (UTC)
From: "Akitoshi Yoshida (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12771032.1422542416000.228939.1422881674808@Atlassian.JIRA>
In-Reply-To: <JIRA.12771032.1422542416000@Atlassian.JIRA>
References: <JIRA.12771032.1422542416000@Atlassian.JIRA>
 <JIRA.12771032.1422542416262@arcas>
Subject: [jira] [Commented] (CXF-6228) Using XSLTFeature with large messages
 creates unremovable temporary files
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/CXF-6228?page=3Dcom.atlassian.j=
ira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D143012=
32#comment-14301232 ]=20

Akitoshi Yoshida commented on CXF-6228:
---------------------------------------

[~pip25]
thanks for the test. The problem is reproducible.
I'll look into it.
regards, aki

> 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=C3=A1n P=C3=A9ter
>            Assignee: Akitoshi Yoshida
>            Priority: Minor
>         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 config=
ured threshold, a temporary file will be created to store the message on th=
e disk; however, this file is not deleted after the message is sent.
> Based on info available on similar problems encountered with CachedOutput=
Stream and attachments, I tried using an interceptor in the SETUP_ENDING ph=
ase to close the stream manually - this, however, did not work because even=
 after closing the stream, the "streamList" variable was not empty, which r=
esulted in the closing logic skipping file deletion in the "maybeDeleteTemp=
File" method. Attempts to delete the file directly also fail for obvious re=
asons.
> 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. (A=
ctually, the issue was discovered when the temp files filled the disk compl=
etely on a production server.)
> The only viable workaround I found so far was to set the CachedOutputStre=
am threshold high enough to avoid caching the data to disk altogether.


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