You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "Brian Husted (JIRA)" <ax...@ws.apache.org> on 2005/10/06 22:44:48 UTC

[jira] Commented: (AXIS-2221) Attachment Streaming directly from HTTP Request

    [ http://issues.apache.org/jira/browse/AXIS-2221?page=comments#action_12331530 ] 

Brian Husted commented on AXIS-2221:
------------------------------------

dims,

After checking out via SVN, I verified everything looked good.  

Thanks,
Brian

> Attachment Streaming directly from HTTP Request
> -----------------------------------------------
>
>          Key: AXIS-2221
>          URL: http://issues.apache.org/jira/browse/AXIS-2221
>      Project: Apache Axis
>         Type: Improvement
>   Components: SAAJ
>     Versions: current (nightly)
>  Environment: Java/J2EE
>     Reporter: Brian Husted
>  Attachments: Attachments.java.diff, Attachments.java.diff, AttachmentsImpl.java, AttachmentsImpl.java.diff, Axis_Java_SoapStreamsIterator_Design.doc, DimeAttachmentStreams.java, IncomingAttachmentStreams.java, MultipartAttachmentStreams.java, resource.properties.diff
>
> The uploading of large attachments is a usual occurrence in production systems using Apache Axis (Java).  Unfortunately, such an action has shown to degrade the performance when high volumes of attachments or large attachments are submitted.  In order to realize optimal peformance for receiveing SOAP attachments, this document proposes a new implementation of handling attachments in Axis (Java).  The changes proposed in this document PRESERVES backwards compatibility and allows the developer to decide how they would like to retreive the attachments.
> Currently, depending on the size of the attachment, Axis reads the entire HTTP stream and caches all attachments in memory or onto disk.  The caching permits all of the attachments to be fully available to the business software by the time the request is passed to them for processing.  The drawback to this approach is that it forces Axis to either allocate addition memory buffers or to engage in expensive file IO transactions in order to store the data from the HTTP stream.  The extraction of the attachment data from the HTTP stream can be delegated to business tier which may be using Fiber channel SAN or databases to store the attachment data.  This option will allow the business delegate to decide how to process the data and may do so without the necessity of caching the data to local disk.
> The proposal is to add a method to the Attachments interface allowing access to the underlying HTTP stream so that attachments can be streamed to the business objects instead of providing them with cached versions.  This change will also require edits to the AttachmentImpl class and the addition of several new classes that will become the interfacing classes to the users of this new feature.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira