You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Pavel Ausianik <Pa...@epam.com> on 2002/11/13 15:04:00 UTC
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
Re: Using mime parts - huge drawbacks
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <Pa...@epam.com>
To: <so...@xml.apache.org>
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: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Using mime parts - huge drawbacks
Posted by Scott Nichol <sn...@scottnichol.com>.
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" <Pa...@epam.com>
To: <so...@xml.apache.org>
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: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>