You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Rich Scheuerle (JIRA)" <ji...@apache.org> on 2008/01/14 22:37:34 UTC
[jira] Resolved: (WSCOMMONS-292) Attachment Part Performance
Speedup
[ 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 611943
> 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