[
https://issues.apache.org/jira/browse/WSCOMMONS-506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766059#action_12766059
]
Rich Scheuerle commented on WSCOMMONS-506:
------------------------------------------
Scenario A:
Customer client code receives a web service response containing a message
containing a small attachment (memory)
The customer client code (not the axiom or axis2 project) has the
responsibility of the end of life of the received message.
The customer may even persist or copy the message.
Even if the customer code is ill-behaved, the garbage collector will eventually
free the memory once the message is no
longer referenced.
Scenario B:
Same scenario as A, except that the message contains a large attachment. Thus
the attachment data is kept in a
file. If the customer's code makes copies of the message, both copies will
still reference the same file.
If the customer's code is ill-behaved, eventually the garbage collector will
free the in-core memory. However
there is no guarantee that the file associated with the attachment is deleted.
(The message may not be referenced, but
threads in the system may still be accessing the file contents). Managing when
the file can be deleted is difficult.
There are some solutions that have already been applied using finalizers and
temp delete code, but these approaches
are not guaranteed by Java...and there is still opportunities for leaks.
Scenario C:
The same as scenario B, except now think of the situation from an enterprise
perspective. Vendor1 provided the "ill-behaved customer code".
Vendor2 purchased the code and is the administrator of a system that contains
Vendor1 code. Over a long period of time (days or weeks) under high load,
the file system of Vendor2 fills. Vendor2 is an administrator and cannot
change either Axiom or the Vendor1 code.
-------------------------------
The point of this fix is to address the C scenario. Now an administrator can
set a property to at least prevent a catastrophic file system failure.
--------------------------------
I agree that there are problems with the resource management of Attachments.
From my own knowledge, there are some things that could or should be improved.
All access to the cache file should be done in a way that Axiom (Attachments)
has full knowledge of the access. For example, there is a FileAccessor (good)
but
unfortunately the FileAccessor leaks out information about the file
(bad). FileAccessor is not doing its job if it is simple a bridge to the
File. It should be manage
access to the file.
Examples:
FileAccessor allows a caller to do a getFile() to the File
object.
Ouch, we have just lost control of who is
touching the file, thus it is hard to know when we can delete it.
This should be eliminated or done via a wrapper
so that we can know the accesses.
FileAccessor getInputStream() returns a FileInputStream
(ouch). Once again we give up control to the caller. We don't know the
lifetime of the
FileInputStream...thus it is hard to know when
it is safe to delete the attachment.
The solution (or partial solution) is to start digging on these places where
the actual File or access is leaked outside of the Attachment. Once all of
these leaks are blocked, then we will have more information to know when it is
safe or not safe to delete the File.
My thought is that these leaks should be addressed in a separate JIRA.
> 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.
