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] Created: (CXF-2106) Temp files created for data over 64kb are never deleted
Date Wed, 11 Mar 2009 19:04:50 GMT
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


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