cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Murphy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-2106) Temp files created for data over 64kb are never deleted
Date Thu, 12 Mar 2009 11:40:50 GMT

    [ https://issues.apache.org/jira/browse/CXF-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12681273#action_12681273
] 

Martin Murphy commented on CXF-2106:
------------------------------------

Thanks for that Dan, just tried the version on the trunk and it only seems to work for the
byte array. The temp file for the DataHandler still exists. I'm looking into that now.

> Temp files created for data over 64kb are never deleted
> -------------------------------------------------------
>
>                 Key: CXF-2106
>                 URL: https://issues.apache.org/jira/browse/CXF-2106
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.4, 2.2
>         Environment: Tested against 2.1 branch and the trunk
>            Reporter: Martin Murphy
>            Assignee: Daniel Kulp
>
> CXF saves incoming data greater than 64kb are saved to a temp directory in a [cached
output stream|http://svn.apache.org/viewvc/cxf/trunk/api/src/main/java/org/apache/cxf/io/CachedOutputStream.java?view=markup].
This makes sense since we don't want large messages to cause the JVM to run out of memory.
> The problem is, these never seem to be deleted at the moment. You can see this if you
run the mtom sample. You can change the directory that the temp file is written to using the
org.apache.cxf.io.CachedOutputStream.OutputDirectory property. Notice with the mtom sample
that two files are written to the directory for the client and server. This is because the
the client invokes twice, once with a byte array and once with a data handler.
> If you know the size of all messages that may be received you can avoid this problem
by setting the threshold for creating a temp file to be larger than the largest expected file.
The property for this (measure in bytes) is org.apache.cxf.io.CachedOutputStream.Threshold.
> In my investigation it seems that there are two possible problems here. The first is
that for the byte array the output stream is locked for future use, but not closed. So, when
we try to delete the file a stream is still in use and the file cannot be deleted. If you
close the stream when marking it as locked this problem seems to go away, although I haven't
fully tested this, so I am unsure of the knock on affects :
> {code}
> /**
> * Locks the output stream to prevent additional writes, but maintains
> * a pointer to it so an InputStream can be obtained
> * @throws IOException
> */
> public void lockOutputStream() throws IOException {
>     currentStream.flush();
>     outputLocked = true;
>     // Not sure of the impact of this close - mtom sample still works fine.
>     currentStream.close();
>     streamList.remove(currentStream);
> }
> {code}
> However for the datahandler it seems that there is never any attempt to delete the file.
It seems that the datahandler has no knowledge of the temp file and even if I try to close
the inputstream it is using from the mtom client mainline I still see the temp file is never
deleted.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message