ws-commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rich Scheuerle (JIRA)" <>
Subject [jira] Created: (WSCOMMONS-292) Attachment Part Performance Speedup
Date Fri, 11 Jan 2008 22:38:34 GMT
Attachment Part Performance Speedup

                 Key: WSCOMMONS-292
             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

     * 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 PartFactory.

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