ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AXIOM-185) Temporary copies of MTOM attachments are not deleted from the file system in a timely manner
Date Sun, 11 Dec 2011 16:20:40 GMT

    [ https://issues.apache.org/jira/browse/AXIOM-185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167127#comment-13167127
] 

Andreas Veithen commented on AXIOM-185:
---------------------------------------

Answering my own questions (since IBM never responded...):

- Of course Java guarantees that the finalizer is called when an object is garbage collected.
However, one still needs a solution to delete the file when the JVM stops before the object
is garbage collected. Since File#deleteOnExit is known to create a (native) memory leak, this
needs to be implemented using a shutdown hook.

- It is indeed not possible for application code to get access to the FileAccessor object.
However, the DataHandler objects created by Axiom (for attachment parts buffered on disk)
are backed by CachedFileDataSource objects. CachedFileDataSource extends javax.activation.FileDataSource
which gives access to the java.io.File object. There is code in Axis2 that explicitly relies
on this to clean up the temporary files.
                
> Temporary copies of MTOM attachments are not deleted from the file system in a timely
manner
> --------------------------------------------------------------------------------------------
>
>                 Key: AXIOM-185
>                 URL: https://issues.apache.org/jira/browse/AXIOM-185
>             Project: Axiom
>          Issue Type: Bug
>            Reporter: Wendy Raschke
>            Assignee: Rich Scheuerle
>         Attachments: WSCOMMONS-506.patch
>
>
> When customers send MTOM attachments having a certain size, the Axis2 runtime uses Axiom
to make copies of these attachments and name them with a pattern of AxisXXXXXX.att, where
XXXXXX is an arbitrary sequence of integers. These copies may not be deleted in a timely manner,
and may be removed only when the JVM exits. This can cause a lot of files to accumulate on
the customer's file system and eat up disk space, and some of these files can be quite large.
> Note that the internal sizeThreshold property controls whether attachment files are written
to memory or as files to the disk.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org


Mime
View raw message