Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-2106

Temp files created for data over 64kb are never deleted

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • 2.1.4, 2.2
    • 2.0.11, 2.1.5
    • Core
    • None
    • Tested against 2.1 branch and the trunk

    Description

      CXF saves incoming data greater than 64kb are saved to a temp directory in a cached output stream. 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 :

      /**
      * 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);
      }
      

      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.

      Attachments

        Issue Links

          Activity

            People

              dkulp Daniel Kulp
              martinmurphy Martin Murphy
              Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: