[
https://issues.apache.org/jira/browse/WSCOMMONS-292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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.
Solution:
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: 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]
