You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Sean Barnett (JIRA)" <ax...@ws.apache.org> on 2004/11/08 06:18:32 UTC
[jira] Created: (AXIS-1654) Small attachments creating attachment files that are not cleaned up
Small attachments creating attachment files that are not cleaned up
-------------------------------------------------------------------
Key: AXIS-1654
URL: http://nagoya.apache.org/jira/browse/AXIS-1654
Project: Axis
Type: Bug
Versions: beta-3
Reporter: Sean Barnett
Priority: Minor
The class AttachmentPart wraps ManagedMemoryDataSource. The latter determines whether to store attachments to disk or in memory based upon attachment size, and AttachmentPart notes this decision through the member variable "attachmentFile"
public AttachmentPart(javax.activation.DataHandler dh) {
setMimeHeader(HTTPConstants.HEADER_CONTENT_ID,
SessionUtils.generateSessionId());
datahandler = dh;
if(dh != null) {
setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, dh.getContentType());
javax.activation.DataSource ds = dh.getDataSource();
if (ds instanceof ManagedMemoryDataSource) {
extractFilename((ManagedMemoryDataSource)ds); //and get the filename if appropriate
}
}
}
If the programmer gets the data source from underneath the attachment part by calling "getDataHandler().getDataSource()", and then calls getName() on that data source the ManagedMemoryDataSource forces storage to disk by internally calling flushToDisk().
public java.lang.String getName() {
String ret = null;
try {
flushToDisk();
if (diskCacheFile != null) {
ret = diskCacheFile.getAbsolutePath();
}
} catch (Exception e) {
diskCacheFile = null;
}
return ret;
}
AttachmentPart does not know that a disk file has been created underneath it, and when dispose() is called fails to call delete on the ManagedMemoryDataSource ...
public synchronized void dispose() {
if (attachmentFile != null) {
javax.activation.DataSource ds = datahandler.getDataSource();
if (ds instanceof ManagedMemoryDataSource) {
((ManagedMemoryDataSource) ds).delete(); //and delete the file
} else {
File f = new File(attachmentFile);
//no need to check for existence here.
f.delete();
}
//set the filename to null to stop repeated use
setAttachmentFile(null);
}
//clean up the datahandler, as it will have been
//invalidated if it was bound to a file; if it wasnt
//we get to release memory anyway
datahandler = null;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1654) Small attachments creating attachment files that are not cleaned up
Posted by "Ashutosh Shahi (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]
Ashutosh Shahi updated AXIS-1654:
---------------------------------
Attachment: patch1654_new.txt
Attaching a new patch incorporating changes as suggested by Sean.
Thanks,
Ashutosh
> Small attachments creating attachment files that are not cleaned up
> -------------------------------------------------------------------
>
> Key: AXIS-1654
> URL: http://nagoya.apache.org/jira/browse/AXIS-1654
> Project: Axis
> Type: Bug
> Versions: beta-3
> Reporter: Sean Barnett
> Priority: Minor
> Attachments: AttachmentPartTest.java, AttachmentPartTest.java, patch1654_new.txt, patch_1654.txt
>
> The class AttachmentPart wraps ManagedMemoryDataSource. The latter determines whether to store attachments to disk or in memory based upon attachment size, and AttachmentPart notes this decision through the member variable "attachmentFile"
> public AttachmentPart(javax.activation.DataHandler dh) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_ID,
> SessionUtils.generateSessionId());
> datahandler = dh;
> if(dh != null) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, dh.getContentType());
> javax.activation.DataSource ds = dh.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> extractFilename((ManagedMemoryDataSource)ds); //and get the filename if appropriate
> }
> }
> }
> If the programmer gets the data source from underneath the attachment part by calling "getDataHandler().getDataSource()", and then calls getName() on that data source the ManagedMemoryDataSource forces storage to disk by internally calling flushToDisk().
> public java.lang.String getName() {
> String ret = null;
> try {
> flushToDisk();
> if (diskCacheFile != null) {
> ret = diskCacheFile.getAbsolutePath();
> }
> } catch (Exception e) {
> diskCacheFile = null;
> }
> return ret;
> }
> AttachmentPart does not know that a disk file has been created underneath it, and when dispose() is called fails to call delete on the ManagedMemoryDataSource ...
> public synchronized void dispose() {
> if (attachmentFile != null) {
> javax.activation.DataSource ds = datahandler.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> ((ManagedMemoryDataSource) ds).delete(); //and delete the file
> } else {
> File f = new File(attachmentFile);
> //no need to check for existence here.
> f.delete();
> }
> //set the filename to null to stop repeated use
> setAttachmentFile(null);
> }
> //clean up the datahandler, as it will have been
> //invalidated if it was bound to a file; if it wasnt
> //we get to release memory anyway
> datahandler = null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1654) Small attachments creating attachment files that are not cleaned up
Posted by "Sean Barnett (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]
Sean Barnett updated AXIS-1654:
-------------------------------
Attachment: AttachmentPartTest.java
My previous unit test was only half there - the patch code didn't take into account that detachAttachmentFile had been called (the file would still go). Please find attached new unit test.
Suggested code fix - add a boolean to track call to detachAttachmentFile - as per snippets below. This code passes the modified unit test.
/**
* Indicates that file has been detached and should not to be deleted.
*/
private boolean fileDetached = false;
public void detachAttachmentFile() {
fileDetached = true;
attachmentFile=null;
}
public synchronized void dispose()
{
if (fileDetached == false)
{
javax.activation.DataSource ds = datahandler.getDataSource();
if (attachmentFile != null || ds instanceof ManagedMemoryDataSource)
{
((ManagedMemoryDataSource) ds).delete(); // and delete the file
if(attachmentFile != null)
{
// set the filename to null to stop repeated use
setAttachmentFile(null);
}
}
else
{
File f = new File(attachmentFile);
// no need to check for existence here.
f.delete();
}
} // if
// clean up the datahandler, as it will have been
// invalidated if it was bound to a file; if it wasnt
// we get to release memory anyway
datahandler = null;
}
> Small attachments creating attachment files that are not cleaned up
> -------------------------------------------------------------------
>
> Key: AXIS-1654
> URL: http://nagoya.apache.org/jira/browse/AXIS-1654
> Project: Axis
> Type: Bug
> Versions: beta-3
> Reporter: Sean Barnett
> Priority: Minor
> Attachments: AttachmentPartTest.java, AttachmentPartTest.java, patch_1654.txt
>
> The class AttachmentPart wraps ManagedMemoryDataSource. The latter determines whether to store attachments to disk or in memory based upon attachment size, and AttachmentPart notes this decision through the member variable "attachmentFile"
> public AttachmentPart(javax.activation.DataHandler dh) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_ID,
> SessionUtils.generateSessionId());
> datahandler = dh;
> if(dh != null) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, dh.getContentType());
> javax.activation.DataSource ds = dh.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> extractFilename((ManagedMemoryDataSource)ds); //and get the filename if appropriate
> }
> }
> }
> If the programmer gets the data source from underneath the attachment part by calling "getDataHandler().getDataSource()", and then calls getName() on that data source the ManagedMemoryDataSource forces storage to disk by internally calling flushToDisk().
> public java.lang.String getName() {
> String ret = null;
> try {
> flushToDisk();
> if (diskCacheFile != null) {
> ret = diskCacheFile.getAbsolutePath();
> }
> } catch (Exception e) {
> diskCacheFile = null;
> }
> return ret;
> }
> AttachmentPart does not know that a disk file has been created underneath it, and when dispose() is called fails to call delete on the ManagedMemoryDataSource ...
> public synchronized void dispose() {
> if (attachmentFile != null) {
> javax.activation.DataSource ds = datahandler.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> ((ManagedMemoryDataSource) ds).delete(); //and delete the file
> } else {
> File f = new File(attachmentFile);
> //no need to check for existence here.
> f.delete();
> }
> //set the filename to null to stop repeated use
> setAttachmentFile(null);
> }
> //clean up the datahandler, as it will have been
> //invalidated if it was bound to a file; if it wasnt
> //we get to release memory anyway
> datahandler = null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1654) Small attachments creating attachment files that are not cleaned up
Posted by "Ashutosh Shahi (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]
Ashutosh Shahi updated AXIS-1654:
---------------------------------
Attachment: patch_1654.txt
Sean,
Am posting a patch for the above issue. But i don't have a test case to verify it works. Can u test it at your end or post your wsdl and client code so that i can test the changes?
Ashutosh
> Small attachments creating attachment files that are not cleaned up
> -------------------------------------------------------------------
>
> Key: AXIS-1654
> URL: http://nagoya.apache.org/jira/browse/AXIS-1654
> Project: Axis
> Type: Bug
> Versions: beta-3
> Reporter: Sean Barnett
> Priority: Minor
> Attachments: patch_1654.txt
>
> The class AttachmentPart wraps ManagedMemoryDataSource. The latter determines whether to store attachments to disk or in memory based upon attachment size, and AttachmentPart notes this decision through the member variable "attachmentFile"
> public AttachmentPart(javax.activation.DataHandler dh) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_ID,
> SessionUtils.generateSessionId());
> datahandler = dh;
> if(dh != null) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, dh.getContentType());
> javax.activation.DataSource ds = dh.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> extractFilename((ManagedMemoryDataSource)ds); //and get the filename if appropriate
> }
> }
> }
> If the programmer gets the data source from underneath the attachment part by calling "getDataHandler().getDataSource()", and then calls getName() on that data source the ManagedMemoryDataSource forces storage to disk by internally calling flushToDisk().
> public java.lang.String getName() {
> String ret = null;
> try {
> flushToDisk();
> if (diskCacheFile != null) {
> ret = diskCacheFile.getAbsolutePath();
> }
> } catch (Exception e) {
> diskCacheFile = null;
> }
> return ret;
> }
> AttachmentPart does not know that a disk file has been created underneath it, and when dispose() is called fails to call delete on the ManagedMemoryDataSource ...
> public synchronized void dispose() {
> if (attachmentFile != null) {
> javax.activation.DataSource ds = datahandler.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> ((ManagedMemoryDataSource) ds).delete(); //and delete the file
> } else {
> File f = new File(attachmentFile);
> //no need to check for existence here.
> f.delete();
> }
> //set the filename to null to stop repeated use
> setAttachmentFile(null);
> }
> //clean up the datahandler, as it will have been
> //invalidated if it was bound to a file; if it wasnt
> //we get to release memory anyway
> datahandler = null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
[jira] Updated: (AXIS-1654) Small attachments creating attachment files that are not cleaned up
Posted by "Sean Barnett (JIRA)" <ax...@ws.apache.org>.
[ http://nagoya.apache.org/jira/browse/AXIS-1654?page=history ]
Sean Barnett updated AXIS-1654:
-------------------------------
Attachment: AttachmentPartTest.java
This is a quick junit test that fails without the patch, and works with the patch.
> Small attachments creating attachment files that are not cleaned up
> -------------------------------------------------------------------
>
> Key: AXIS-1654
> URL: http://nagoya.apache.org/jira/browse/AXIS-1654
> Project: Axis
> Type: Bug
> Versions: beta-3
> Reporter: Sean Barnett
> Priority: Minor
> Attachments: AttachmentPartTest.java, patch_1654.txt
>
> The class AttachmentPart wraps ManagedMemoryDataSource. The latter determines whether to store attachments to disk or in memory based upon attachment size, and AttachmentPart notes this decision through the member variable "attachmentFile"
> public AttachmentPart(javax.activation.DataHandler dh) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_ID,
> SessionUtils.generateSessionId());
> datahandler = dh;
> if(dh != null) {
> setMimeHeader(HTTPConstants.HEADER_CONTENT_TYPE, dh.getContentType());
> javax.activation.DataSource ds = dh.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> extractFilename((ManagedMemoryDataSource)ds); //and get the filename if appropriate
> }
> }
> }
> If the programmer gets the data source from underneath the attachment part by calling "getDataHandler().getDataSource()", and then calls getName() on that data source the ManagedMemoryDataSource forces storage to disk by internally calling flushToDisk().
> public java.lang.String getName() {
> String ret = null;
> try {
> flushToDisk();
> if (diskCacheFile != null) {
> ret = diskCacheFile.getAbsolutePath();
> }
> } catch (Exception e) {
> diskCacheFile = null;
> }
> return ret;
> }
> AttachmentPart does not know that a disk file has been created underneath it, and when dispose() is called fails to call delete on the ManagedMemoryDataSource ...
> public synchronized void dispose() {
> if (attachmentFile != null) {
> javax.activation.DataSource ds = datahandler.getDataSource();
> if (ds instanceof ManagedMemoryDataSource) {
> ((ManagedMemoryDataSource) ds).delete(); //and delete the file
> } else {
> File f = new File(attachmentFile);
> //no need to check for existence here.
> f.delete();
> }
> //set the filename to null to stop repeated use
> setAttachmentFile(null);
> }
> //clean up the datahandler, as it will have been
> //invalidated if it was bound to a file; if it wasnt
> //we get to release memory anyway
> datahandler = null;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira