[ 
https://issues.apache.org/jira/browse/WSCOMMONS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766156#action_12766156
 ] 

Andreas Veithen commented on WSCOMMONS-506:
-------------------------------------------

Rich,

There are two points in your analysis that don't seem very convincing to me:

- If I understand correctly, you're saying that Java doesn't provide enough 
guarantees to use finalization to reliably clean up temporary files. If 
finalization is used together with File#deleteOnExit (or a shutdown hook), can 
you give me an example where this would cause a leak (and where a timeout based 
solution doesn't)?

- Your argument about FileAccessor is only relevant if client code can get 
access to that object. However, I fail to see how you can get from the 
Attachments object to any of the FileAccessor instances. Can you point me to 
the code that allows this?

> Temporary copies of MTOM attachments are not deleted from the file system in 
> a timely manner
> --------------------------------------------------------------------------------------------
>
>                 Key: WSCOMMONS-506
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-506
>             Project: WS-Commons
>          Issue Type: Bug
>          Components: AXIOM
>            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.
-
You can reply to this email to add a comment to the issue online.

Reply via email to