Return-Path: Mailing-List: contact soap-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list soap-dev@xml.apache.org Received: (qmail 76155 invoked from network); 13 Nov 2002 15:44:14 -0000 Received: from smtp.comcast.net (24.153.64.2) by daedalus.apache.org with SMTP; 13 Nov 2002 15:44:14 -0000 Received: from fastdata (pcp01349834pcs.lowmrn01.pa.comcast.net [68.80.227.176]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 1.5 (built Sep 23 2002)) with SMTP id <0H5I0041XUCZWV@mtaout02.icomcast.net> for soap-dev@xml.apache.org; Wed, 13 Nov 2002 10:43:48 -0500 (EST) Date: Wed, 13 Nov 2002 10:47:33 -0500 From: Scott Nichol Subject: Re: Using mime parts - huge drawbacks To: soap-dev@xml.apache.org Message-id: <002a01c28b2b$fbbce370$c900a8c0@fastdata> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4920.2300 X-Mailer: Microsoft Outlook Express 5.50.4920.2300 Content-type: text/plain; charset=WINDOWS-1251 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <0418A01B842BD6118C7E00D0B7B6B60E24E215@EPMSA005> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Pavel, Yes, this is a good observation. In the case where there are no attachments, the process could be streamlined by serializing directly. I am still actively working on this part of the code (TransportMessage, SOAPContext, Call) and will look at sidestepping some of the activity where there are no attachments, just a SOAP envelope, which as you point out is the typical scenario. Scott Nichol ----- Original Message ----- From: "Pavel Ausianik" To: Sent: Wednesday, November 13, 2002 9:04 AM Subject: Using mime parts - huge drawbacks > Hello, > > thinking more on the current code I have found interesting thing. Most > requests we have a simple, straight SOAP envelopes, without any attachments. > Looking how it is processed I have found following (traced from > httpconnection): > > In SOAPHTTPConnection.send() we call TransportMessage.save(). > Let's look into it (see my comment how I understand it: > > String rootContentType = null; > > // Root Part is Not set for Simple Envelope ! > > if (ctx.isRootPartSet()) { > //... Not in use for simple case > } > > if (rootContentType == null) > rootContentType = Constants.HEADERVAL_CONTENT_TYPE_UTF8; > if (getEnvelope() != null) { > > // Now really create root part - how important it is if we now how to write > this Envelope without involving Mime !!! > > ctx.setRootPart(envelope, rootContentType); > } else { > //... Not in use for simple case > } > > // Print the whole response to a byte array. > // Tracing into this code we'll found that all it will do it add > unnecessary header to envelope > // The headers include Content-Type - we know which is, > // Content-id - do we need it? Even if yes we can create any id > // Content-Transfer-Encoding - not for HTTp, anyway we force it to 8 bit > // Content-Lenght - easy to calculate > > ByteArrayOutputStream payload = > new ByteArrayOutputStream(1024); > ctx.writeTo(payload); > bytes = payload.toByteArray(); > > // Now strip off the headers. (Grmbl, get rid of JavaMail > // for MIME support). Just intercept the Content-Type > // Remove headers which created right now.... > > .... > > // TODO: should not send for HTTP response > headers.put("Accept-Encoding", "x-gzip"); > if (Boolean.TRUE.equals(ctx.getGzip())) { > // Deflate > ByteArrayOutputStream baos = > new ByteArrayOutputStream(bytes.length * 2); > GZIPOutputStream gzos = new GZIPOutputStream(baos); > gzos.write(bytes, offset, bytes.length - offset); > gzos.close(); > baos.close(); > bytes = baos.toByteArray(); > offset = 0; > > headers.put("Content-Encoding", "x-gzip"); > } > > Seems like we are doing wonderful job of running a lot unnecessary > operations, involving a lot of memory allocations... It could be most > advanced improvement we ever done! > > Best regards, > Pavel > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > >