axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samuel Isokpunwu (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (AXIS2-2596) Clean up cached attachment files
Date Thu, 19 Jul 2007 22:59:06 GMT

     [ https://issues.apache.org/jira/browse/AXIS2-2596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Samuel Isokpunwu reopened AXIS2-2596:
-------------------------------------


With attachment caching to the disk enabled, cached attachment file created is not deleted
after use. This will lead to an out of space condition especially with large attachment files.

Added a method to org.apache.axis2.transport.TransportUtils.java and org.apache.axis2.jaxws.message.attachments.AttachmentUtils.java
to delete server and client side cached attachment files after use respectively.

Initially, The cache attachment file deletion seem to be a simple problem to resolve by adding
a line of code to the org.apache.axiom.attachments.PartOnFile.java constructor to execute
deleteOnExit() method call on the cached attachment file as soon as the file is created. With
this approach, the cached file created on the client side after processing the client response
message is deleted after use but the one created on the server side after processing the request
message is not deleted after use. Was Not able to determine the reasons for failure within
the time spent on debugging but suspected that the file object may still be held in memory
after use.

Also tried to create a CachedFile.java wrapper that implements object.finalize() method to
delete the cached attachment file once the GC is executed by the JVM. Apart from the inherent
performance problem with this approach, some of the test scenario also failed perhalp due
to JVM object reactivation policy for an object that was initially garbage collected.

The best working solution, so far, to cover all known testcase scenarios and to avoid deleting
the cached attachment file prematurely or before it is read, was to --
1. Delete the server side cached attachment file after the server response message is processed.

    In the case of the Application Server I was working with, the cached attachment file delete
was done within a finally
    block in the doPost() method of a servlet that extends the org.apache.axis2.transport.http.AxisServlet.java
2. Leaving the file.deleteOnExit() method call in org.apache.axiom.attachments.PartOnFile.java
to take care of the client
    side cached attachment file deletion was causing data fragmentation that resulted in a
significant performance
    degradation. To resolve the data fragementation problem, the deleteOnExit() method call
was removed from
    PartOnFile.java and then add a method to jaxws client code to check response message for
cached attachment file and
    if a cached file exist, execute the cached file object's deleteOnExit() method.

Will include a patch to show all the file changes and for the patch to be committed if the
changes are acceptable to the community.

> Clean up cached attachment files
> --------------------------------
>
>                 Key: AXIS2-2596
>                 URL: https://issues.apache.org/jira/browse/AXIS2-2596
>             Project: Axis 2.0 (Axis2)
>          Issue Type: Bug
>          Components: transports
>         Environment: Win XP
>            Reporter: Samuel Isokpunwu
>            Assignee: Thilina Gunarathne
>
> Added some code to clean up cached attachement files after use.

-- 
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org


Mime
View raw message