[jira] Commented: (CXF-2106) Temp files created for data over 64kb are never deleted

["Daniel Kulp (JIRA)" <ji...@apache.org>]

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

Daniel Kulp commented on CXF-2106:
----------------------------------


I committed what I hope is a fix for this.  However, I don't have a windows box to try it.   On Linux, the files delete fine.   It seems to be a Windows issue.

Could you try and double check it's fixed?


> 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.