Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Fri, 30 Jan 2015 11:25:34 +0000 (UTC)
From: =?utf-8?Q?Papp_Istv=C3=A1n_P=C3=A9ter_=28JIRA=29?= <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: <JIRA.12771032.1422542416000.214403.1422617134683@Atlassian.JIRA>
In-Reply-To: <JIRA.12771032.1422542416000@Atlassian.JIRA>
References: <JIRA.12771032.1422542416000@Atlassian.JIRA>
 <JIRA.12771032.1422542416262@arcas>
Subject: [jira] [Updated] (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.=
jira.plugin.system.issuetabpanels:all-tabpanel ]

Papp Istv=C3=A1n P=C3=A9ter updated CXF-6228:
-----------------------------------
    Attachment: bug6228reproduction.zip

Small test project that can reproduce 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=C3=A1n P=C3=A9ter
>            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)