You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Samuel Isokpunwu (JIRA)" <ji...@apache.org> on 2007/07/18 21:53:04 UTC
[jira] Closed: (WSCOMMONS-191) Attachment caching
[ https://issues.apache.org/jira/browse/WSCOMMONS-191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Samuel Isokpunwu closed WSCOMMONS-191.
--------------------------------------
Resolution: Fixed
Took a different approach that resulted in no code changes in the Axiom code.
> Attachment caching
> ------------------
>
> Key: WSCOMMONS-191
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-191
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Environment: Windows
> Reporter: Samuel Isokpunwu
>
> Samuel Isokpunwu/Austin/IBM@IBMUS wrote on 04/12/2007 10:53:33 AM:
> >
> > Currently debugging a client application that enabled attachment
> > caching using the following Axis2 properties.
> > org.apache.axis2.Constants.Configuration.CACHE_ATTACHMENTS
> > org.apache.axis2.Constants.Configuration.ATTACHMENT_TEMP_DIR
> > org.apache.axis2.Constants.Configuration.FILE_SIZE_THRESHOLD
> >
> > From executing the client application and from stepping through the
> > attachment caching implementation code in Axis2,
> > the attachment is appropriately cached to a specified temp directory
> > in the local file system when the attachment
> > size is greater than the specified attachment size threshold. The
> > apparent problem now is that all cashed attachment (s)
> > for every request/response message are not deleted or reused at the
> > end of every execution hence client application
> > is quickly running out of disk space especially when attachments are
> > fairly large.
> >
> > Any reason(s) for not deleting these cashed attachment after use?
> >
> > Are code already written to delete these attachment(s) from the temp
> > directory after use?
> > If no code exist to clean up the temp directory and I needed to add
> > this support, at what point during the message execution
> > life cycle is it safe to delete these cached attachment from the
> > temp directory?
> >
> > Any thought or suggestion on this will be appreciated.
> I think that attachment file deletion is an Axiom concern.
> The PartOnFile object creates the attachment file. But I cannot find any code that
> deletes the file.
> Here is one idea:
> Change the code to introduce a new object, CachedFile.
> CachedFile will create the attachment file when it is constructed and
> delete the cached file when garbage collected.
> PartOnFile and CachedFileDataSource will be changed to use the CachedFile object.
> This will gurantee that the CachedFile (and thus the attachment file) will exist as
> long as it is needed.
> Any other ideas ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org