[
https://issues.apache.org/jira/browse/CXF-2106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved CXF-2106.
------------------------------
Resolution: Fixed
Fix Version/s: 2.1.5
2.0.11
> 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
> Fix For: 2.0.11, 2.1.5
>
>
> 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.
