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/04/12 21:35:15 UTC
[jira] Created: (WSCOMMONS-191) Attachment caching
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
[jira] Closed: (WSCOMMONS-191) Attachment caching
Posted by "Samuel Isokpunwu (JIRA)" <ji...@apache.org>.
[ 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