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