[ http://issues.apache.org/jira/browse/AXIS-2221?page=comments#action_12330122 ]
Brian Husted commented on AXIS-2221: ------------------------------------ I did an update from CVS but I do NOT see any of the changes, and I do NOT see the new classes. DimeAttachmentStreams.java, IncomingAttachmentStreams.java, and MultipartAttachmentStreams.java are NEW classes. Please advise. 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
