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/09/21 22:47:28 UTC
[jira] Commented: (AXIS-2221) Attachment Streaming directly from HTTP Request
[ 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
Re: [jira] Commented: (AXIS-2221) Attachment Streaming directly from HTTP Request
Posted by Davanum Srinivas <da...@gmail.com>.
Yep. we need to fix that.
On 9/21/05, Eric Johnson <er...@tibco.com> wrote:
> I had thought so, but I was confused on one point:
>
> The public web site still includes a link to the CVS repository, not the
> SVN repo.
>
> See this page: http://ws.apache.org/axis/cvs.html
>
> -Eric.
>
> Davanum Srinivas wrote:
>
> >Because we've switched to svn :)
> >
> >http://svn.apache.org/repos/asf/webservices/axis/
> >
> >-- dims
> >
> >On 9/21/05, Brian Husted (JIRA) <ax...@ws.apache.org> 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
> >
> >
> >
>
--
Davanum Srinivas : http://wso2.com/ - Oxygenating The Web Service Platform
Re: [jira] Commented: (AXIS-2221) Attachment Streaming directly from
HTTP Request
Posted by Eric Johnson <er...@tibco.com>.
I had thought so, but I was confused on one point:
The public web site still includes a link to the CVS repository, not the
SVN repo.
See this page: http://ws.apache.org/axis/cvs.html
-Eric.
Davanum Srinivas wrote:
>Because we've switched to svn :)
>
>http://svn.apache.org/repos/asf/webservices/axis/
>
>-- dims
>
>On 9/21/05, Brian Husted (JIRA) <ax...@ws.apache.org> 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
>
>
>
Re: [jira] Commented: (AXIS-2221) Attachment Streaming directly from HTTP Request
Posted by Davanum Srinivas <da...@gmail.com>.
Because we've switched to svn :)
http://svn.apache.org/repos/asf/webservices/axis/
-- dims
On 9/21/05, Brian Husted (JIRA) <ax...@ws.apache.org> 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