[
https://issues.apache.org/jira/browse/WSCOMMONS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle resolved WSCOMMONS-292.
--------------------------------------
Resolution: Fixed
Committed New Update: 612822
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
