Fix for a bug in ManagedMemoryDataSource

[Ananth Krishna <ak...@it-innovation.soton.ac.uk>]

I am sending this mail to the developers list as I have noticed what
seems to me like a bug in the ManagedMemoryDataSource class in axis1_2
beta version. We are using javax.activation.DataHandler for soap
attachments and are aware that axis manages data sources in 1_2 beta
with the ManagedMemoryDataSource class. 

Since then, we had also noticed that temp files created by axis when
handling soap attachments weren't being cleaned up. Hence, we are
explicitly calling 'delete' method on ManagedMemoryDataSource after
ensuring that the data source returned from javax.activation.DataHandler
is of the right type.

For small attachments up to a few kilobytes this worked well but when we
try to upload larger soap attachments of the order of 5-6 megabytes the
delete operation on ManagedMemoryDataSource complained with a
java.util.ConcurrentModificationException on a WeakHashMap used in this
class. 

I dug deeper into the code and didn't quite realise why a WeakHashMap
was used here but it seemed to me that there can be a potential race
condition here and we seem to be hitting it by uploading larger soap
attachments. 

The delete() method of the main ManagedMemoryDataSource class, while
iterating over the elements of the defined WeakHashMap, deletes elements
of the WeakHashMap. As most of us know, this usually is a cause for
ConcurrentModificationException to be thrown on HashMaps/WeakHashMaps. 

Deleting elements in the WeakHashMap is actually done in the close()
method of the private class inside ManagedMemoryDataSource which is
invoked from the delete() method. As the close() method is used all over
the place in this class, I have created a separate closeStream() method
which doesn't attempt to delete/modify elements of this HashMap and is
invoked as before from inside the delete method. This shouldn't affect
elements of the HashMap being removed as the HashMap is cleared at the
end of the delete() method anyway.

I am submitting the changes I have done to this class with this email.
We have tested this class in the context that I have just described and
it seems to work well and were hoping this patch can be included in the
next release of axis..

Thanks & Regards
 Ananth

Ananth Krishna
IT Innovation Centre
2 Venture Road
Chilworth Science Park
Southampton, SO16 7NP, UK

tel:  +44 23 8076 0834
fax: +44 23 8076 0833

mailto:ak@it-innovation.soton.ac.uk
http://www.it-innovation.soton.ac.uk 

Re: Fix for a bug in ManagedMemoryDataSource

[Davanum Srinivas <da...@gmail.com>]

Ananth,

Can you please open a bug report in JIRA
(http://issues.apache.org/jira) and submit the patch (guidelines at
http://nagoya.apache.org/wiki/apachewiki.cgi?AxisProjectPages/SubmitPatches).
So that we don't forget this patch/fix.

thanks,
dims


On Thu, 30 Sep 2004 16:24:12 +0100, Ananth Krishna
<ak...@it-innovation.soton.ac.uk> wrote:
> I am sending this mail to the developers list as I have noticed what
> seems to me like a bug in the ManagedMemoryDataSource class in axis1_2
> beta version. We are using javax.activation.DataHandler for soap
> attachments and are aware that axis manages data sources in 1_2 beta
> with the ManagedMemoryDataSource class.
> 
> Since then, we had also noticed that temp files created by axis when
> handling soap attachments weren't being cleaned up. Hence, we are
> explicitly calling 'delete' method on ManagedMemoryDataSource after
> ensuring that the data source returned from javax.activation.DataHandler
> is of the right type.
> 
> For small attachments up to a few kilobytes this worked well but when we
> try to upload larger soap attachments of the order of 5-6 megabytes the
> delete operation on ManagedMemoryDataSource complained with a
> java.util.ConcurrentModificationException on a WeakHashMap used in this
> class.
> 
> I dug deeper into the code and didn't quite realise why a WeakHashMap
> was used here but it seemed to me that there can be a potential race
> condition here and we seem to be hitting it by uploading larger soap
> attachments.
> 
> The delete() method of the main ManagedMemoryDataSource class, while
> iterating over the elements of the defined WeakHashMap, deletes elements
> of the WeakHashMap. As most of us know, this usually is a cause for
> ConcurrentModificationException to be thrown on HashMaps/WeakHashMaps.
> 
> Deleting elements in the WeakHashMap is actually done in the close()
> method of the private class inside ManagedMemoryDataSource which is
> invoked from the delete() method. As the close() method is used all over
> the place in this class, I have created a separate closeStream() method
> which doesn't attempt to delete/modify elements of this HashMap and is
> invoked as before from inside the delete method. This shouldn't affect
> elements of the HashMap being removed as the HashMap is cleared at the
> end of the delete() method anyway.
> 
> I am submitting the changes I have done to this class with this email.
> We have tested this class in the context that I have just described and
> it seems to work well and were hoping this patch can be included in the
> next release of axis..
> 
> Thanks & Regards
>  Ananth
> 
> Ananth Krishna
> IT Innovation Centre
> 2 Venture Road
> Chilworth Science Park
> Southampton, SO16 7NP, UK
> 
> tel:  +44 23 8076 0834
> fax: +44 23 8076 0833
> 
> mailto:ak@it-innovation.soton.ac.uk
> http://www.it-innovation.soton.ac.uk
> 
> 
> 
> 



-- 
Davanum Srinivas - http://webservices.apache.org/~dims/