ws-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rich Scheuerle (JIRA)" <>
Subject [jira] Reopened: (WSCOMMONS-292) Attachment Part Performance Speedup
Date Thu, 17 Jan 2008 13:19:34 GMT


Rich Scheuerle reopened WSCOMMONS-292:

I am working on an enhancement to the recently committed change.

Problem:  ByteArrayOutputStream and ByteArrayInputStream use a backing byte[] to hold the
data.  Using these classes for very larger attachments (i.e. 75K) results in a lot of buffer
resizing and copying. 

I am introducing two new utility classes BAAOutputStream and BAAInputStream.  These classes
use an Array of byte[] to hold the attachment data.  Each byte[] is a 4K chunk of data.  Using
non-contiguous chunks of data will prevent unnecessary resizing and copying.   

The PartFactory is changed to replace the ByteArray*Stream usages with BAA*Stream usages.
 In addition, I enhanced the readHeaders method in PartFactory to avoid the use of single
byte read() calls.

Tim Hefele has run some tests on the new code and is seeing an increase in throughput.  

Next Step:
I am cleaning up the code this morning and will be committing it today after I complete the
Axis2 testing.  

> Attachment Part Performance Speedup
> -----------------------------------
>                 Key: WSCOMMONS-292
>                 URL:
>             Project: WS-Commons
>          Issue Type: Improvement
>          Components: AXIOM
>            Reporter: Rich Scheuerle
>            Assignee: Rich Scheuerle
> I am working on changes to the Attachment Part implementation code.  The changes should
improve the performance and understandability of the code.
> Brief Design Description
> ---------------------------------
> A) Introduce an org.apache.axiom.attachments.impl package.  The use of an impl package
meshes with the other packages structures in Axiom.
> B) Introduce an org.apache.axiom.attachments.impl.PartFactory class.  The PartFactory
will have a "public static Part createPart(...) " method. 
> Most of the complicated logic of Attachments.getPart() will be moved to the new PartFactory.createPart()
>      * The createPart() method will separate the attachment into a Headers map and the
content.  This will be done
>         in a way that limits the amount of buffering.  This should improve performance
and understandability.
>      * The headers (plus the threshhold information) will be used to create either a
PartOnMemory or PartOnFile object.
> C) Introduce a org.apache.axiom.attachments.impl.AbstractPart.  The AbstractPart is the
abstract base class of PartOnMemory and PartOnFile.  It is 
>      similar to the DynamicPart concept that Nikhil recently committed.  The header methods
are contained in the AbstractPart
>      (The DynamicPart will be removed and replaced with this new class).  
> D) Introduce an org.apache.axiom.attachments.impl.PartOnFile class.  This will be similar
to the existing PartOnFile class.
>        * One difference is that the UUIDGenerator will be used to generate the file name.
 This is done to reduce the synchronization locking.
>        * The constructor of the class is different than the existing PartOnFile classes.
 The new constructor meshes with PartFactory and reduces the 
>          amount of buffering.  Also note that a PartOnFile can only be created  by the
> E) Introduce an org.apache.axiom.attachments.impl.PartOnMemory class.  This is similar
in design to the existing PartOnByteArray class.
>         * One difference is the reuse of the byte array buffer from the PartFactory.
> F) The pre-existing org.apache.axiom.attachments.part.* and PartOnFile and PartOnMemory
classes will be eliminated.
> Nikhil Thaker participated in the design of this code.  Tim Hefele (IBM) is doing the
performance analysis of this code.

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:
For additional commands, e-mail:

View raw message