You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Sanjin Tulac (JIRA)" <ji...@apache.org> on 2015/09/15 00:20:46 UTC

[jira] [Created] (CXF-6591) Aegis DataSourceType.getBytes fails to close the InputStream fetched from DataSource, which prevents the underlying file to be deleted on Windows

Sanjin Tulac created CXF-6591:
---------------------------------

             Summary: Aegis DataSourceType.getBytes fails to close the InputStream fetched from DataSource, which prevents the underlying file to be deleted on Windows
                 Key: CXF-6591
                 URL: https://issues.apache.org/jira/browse/CXF-6591
             Project: CXF
          Issue Type: Bug
          Components: Aegis Databinding
    Affects Versions: 3.1.2, 2.7.17
         Environment: Microsoft Windows (7 for sure, and most likely any other version)
            Reporter: Sanjin Tulac
            Priority: Critical


At CodeObjects, Inc., we're using CXF for all SOAP-based communication between internal application servers. In one of the calls, we pass contents of a temporary file from one server to another via CXF, and then delete temporary file after the remote server call. We use [javax.activation.DataSource|http://docs.oracle.com/javase/6/docs/api/javax/activation/DataSource.html] as input parameter in this service interface and Aegis data binding with MTOM disabled to convert file contents to base64 encoded payload. 

When running on Windows 7 machines, we noticed that these temporary files are not being deleted on the client side, thus consistently filling up hard disk and running the risk of completely clogging it.

I've reproduced the issue and traced the issue to org.apache.cxf.aegis.type.mtom.DataSourceType class, whose getBytes method calls DataSource.getInputStream method, but never closes it, which causes the behavior described above.

I've implemented and tested a simple patch for 2.7 branch, which instead of IOUtils.copy calls IOUtils.copyAndCloseInput, and thus eliminates the described problem.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)