Because we've switched to svn :) http://svn.apache.org/repos/asf/webservices/axis/
-- dims On 9/21/05, Brian Husted (JIRA) <[email protected]> wrote: > [ > 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 > > -- Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
