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
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.
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.
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.