[jira] Resolved: (WSCOMMONS-349) Improved Large Attachment Performance

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

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

Rich Scheuerle resolved WSCOMMONS-349.
--------------------------------------

    Resolution: Fixed

> Improved Large Attachment Performance
> -------------------------------------
>
>                 Key: WSCOMMONS-349
>                 URL: https://issues.apache.org/jira/browse/WSCOMMONS-349
>             Project: WS-Commons
>          Issue Type: Improvement
>          Components: AXIOM
>            Reporter: Rich Scheuerle
>            Assignee: Rich Scheuerle
>
> Tim Hefele (IBM) has been running tests on the performance of large attachments.
> Using this profile data, Tim and I have made several localized improvements to the 
> attachment processing. 
> Summary of Changes:
> 1) Larger Threshold Toleration
>    Currently a user can specify (via Axis config) a file threshold for attachments.
>    If an attachment is larger than the threshold, the attachment is stored in a backing 
>    file.  This improves the memory footprint but can degrade performance.
>    This code has been improved.  Now users can supply a much larger attachment threshold.
>    The axiom PartFactory will automatically reduce the threshold if it appears that the
>    Runtime is low on memory.  This allows users to choose a much higher
>    threshold and get better performance throughput.
> 2) PartFactory.createPart Synchronization
>    The createPart method is used to create an attachment part from the input stream.  In 
>    normal operation, this input stream is an HTTP InputStream and the message is (assumed) chunked.
>    If too many threads are allowed to operate in this section of the code, there tends to be
>    a lot of thrashing.  By reducing the number of operating threads, the total throughput of 
>    the system seems to increase.
> 3) Improved BAAInputStream and BAAOutputStream
>    The BAAInputStream is like a ByteArrayInputStream except that the content is an array of 
>    byte arrays.  Likewise for BAAOutputStream.
>    
>    The BAAInputStream now has a writeTo(OutputStream) method.  This allows the Axiom layer
>    to directly write out the stream without additional buffer copies.
>    In addition, the BAAOutputStream now has a receive(InputStream) method.  This allows the 
>    BAAOutputStream to be built directly from an InputStream without excessive buffer copies.
> 4) Upgraded the BufferUtils code to take advantage of (3)
> 5) Added a verification test
> Kudos to Tim Hefele, David Strite and Nikhil Thaker for their efforts on this issue.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.