[jira] Work started: (WSCOMMONS-292) Attachment Part Performance Speedup

["Rich Scheuerle (JIRA)" <ji...@apache.org>]

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

Work on WSCOMMONS-292 started by Rich Scheuerle.

> Attachment Part Performance Speedup
> -----------------------------------
>
>                 Key: WSCOMMONS-292
>                 URL: https://issues.apache.org/jira/browse/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() method.  
>      * 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 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org