[
https://issues.apache.org/jira/browse/WSCOMMONS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12764984#action_12764984
]
Andreas Veithen commented on WSCOMMONS-506:
-------------------------------------------
Rich,
I'm not suggesting to provide a "keep until" property, but to clearly identify
the root cause of this issue and to implement a solution that fixes it once and
for all. A timeout implementation may be a workaround, but IMHO it is not a
good solution because it doesn't address the root cause, which is that
Axiom/Axis2 is unable to properly manage the lifecycle of the resources it
allocates.
> 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.
