Are you using binary data as an attachment? Data binding is done by Axis engine or you are processing the SOAP stack? We would like to migrate to Axis2, because Axis2 support MTOM/XOP which treat the binary attachment as a inline data of SOAP envelope not as SwA. MTOM/XOP specification says that keeps the advantage of both "pass by value" and "pass by reference" which increase the performance. Whats ur thought on this?
Peter Makoi wrote: > > I am actually using axis 2 > As to what the reason might be, I have not really drawn any conclusion > about it but I think it must have something to do with the way > DataHandler handles the streaming > I have had some valuable tips from alex[one of the contributors in this > forum]regarding a buffering machinisme that acures when calling the > writTo() method of DataHandler, and he suggested that I shuld flush the > outputstream > I tried that but it didn't work either > I have alse cheked the getInputStream() of the dataHandler and I found > out that it's calling PipedOutputStream object that uses a circular > buffer witch is accessed by PipedInputStream and I am still trying to > find out if the problem lies there > Furthermore I have come across some achieve documentations dating back > to 2005 that rule out the possibility of streaming a MIME type soap with > attachments > You can check the rest of the posted by user Alex regarding Streaming > Soap with Attachments > succes > > > -----Original Message----- > From: DeepaJes [mailto:[EMAIL PROTECTED] > Sent: Monday, July 09, 2007 3:52 PM > To: [email protected] > Subject: Re: Streaming Soap with Attachments > > > Hi, > > In our project, we are using Axis1.1 and we are facing the same > issue. > When a binary SOAP attachment of size 1.5MB or more is sent, in the > webservice server end, the Axis Engine takes few seconds to process the > large attachment before the actual business logic starts. I guess this > problem occurs even with DataHandler. We are in the process of > migrating > Axis1.1 to Axis2, because Axis2 handles the attachments in different way > !!! > > Do you know why it takes more tiem to process the large binary > attachment(we > are sending plain java string values as binary attahcment) ? > > Have you find any solution for this issue? > > Thanks > Deepa > > > Peter Makoi wrote: >> >> Does soap with attachments using MIME multipart support streaming? >> >> I have goggled around trying to find out if there is a possibility of >> doing that but i end up getting some old postings and documentations >> that suggest that SwA does not support streaming >> >> I have also tried to simulate streaming a considerably large amount of >> data by sending it as a data handler and then use the streaming >> capability of the activation framework to stream the data into an > output >> stream >> >> But what I got is an overhead equivalent to the time spend to transmit >> the whole file to the client before the streaming begins(my conclusion >> was that the data is received in a one-go and because of it's large > size >> it take's the processor sometime to allocate some memory space to save >> it before the streaming even begins).... Does anyone have any >> explanation? Thanks in advance >> >> >> > > -- > View this message in context: > http://www.nabble.com/Streaming-Soap-with-Attachments-tf4022786.html#a11 > 502202 > Sent from the Axis - User mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Streaming-Soap-with-Attachments-tf4022786.html#a11503874 Sent from the Axis - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
