looking, see problem... > -----Original Message----- > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, November 20, 2002 8:26 AM > To: [EMAIL PROTECTED] > Subject: Re: Using mime parts - huge drawbacks > > > Pavel, > > I applied these patches, but the mime sample does not work. > Please get > this sample working and submit a new patch. > > Thanks. > > Scott Nichol > > ----- Original Message ----- > From: "Pavel Ausianik" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, November 15, 2002 9:59 AM > Subject: RE: Using mime parts - huge drawbacks > > > > > > > > Hi, > > > > I think I managed make it compatible to existing code and yet still > mush > > faster (8-10 sec of 60 I had in the morning ). The Mime part will be > creates > > as soon as it requested, otherwise plain Envelope used > > Also I set up initial buffer in couple of classes... > > > > Please take a look > > > > Also, if comparing to yesterday's picture timeload, we have > 4 big time > > consumers, which I suppose quite logical > > > > 1. DocumentBulder.parse > > 2. RPCMessage.extractFromEnvelope > > 3. EnvelopeMaprshall > > 4. InputStream.read > > > > Pavel > > > > > -----Original Message----- > > > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, November 14, 2002 6:54 PM > > > To: [EMAIL PROTECTED] > > > Subject: Re: Using mime parts - huge drawbacks > > > > > > > > > Thanks for yet another valuable contribution! I've committed this > > > patch. Your others will have to wait a little while > since I have to > > > earn some money today (instead of working on Apache SOAP). > > > > > > I have some questions. > > > > > > 1. What do you use to do this profile? I have very little > experience > > > with profilers, mainly with JInsight, but that was over a > year ago. > > > > > > 2. What is "ComplexRequest"? > > > > > > 3. Do you know what version of JavaMail you are using? > > > > > > Something very interesting that I had not noticed before is that > > > provider.invoke gets on the request and response contexts, so > > > that even > > > "plain" RPCs have their SOAP envelope put into SOAPContext and > > > subsequently extracted. I am thinking that the SOAPContext > > > should gain > > > the ability to hold a SOAP envelope other than simply as the root > part > > > to avoid the expense of extracting it. In fact, > SOAPContext should > be > > > able to keep track of whether there are any attachments > versus just > an > > > evelope to optimize the situation where there is only an envelope. > We > > > would use lazy evaluation to stuff it into the root part > if the root > > > part is requested, but otherwise provide shortcuts to just access > the > > > envelope. > > > > > > Scott Nichol > > > > > > ----- Original Message ----- > > > From: "Pavel Ausianik" <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Thursday, November 14, 2002 9:04 AM > > > Subject: RE: Using mime parts - huge drawbacks > > > > > > > > > > Scott, > > > > > > > > Here is server time picture taken on the Tomcat server , > processing > > > > ComplexRequest. > > > > The red ellipses show that MimePart initialization takes 10-15% > of > > > CPU > > > > load. > > > > The blue ellipses show that ContentType is also quite expensive > for > > > benefits > > > > it provide. I prepared patch for caching ContentType... > > > > > > > > Pavel > > > > > > > > > -----Original Message----- > > > > > From: Scott Nichol [mailto:[EMAIL PROTECTED]] > > > > > Sent: Wednesday, November 13, 2002 5:48 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: Using mime parts - huge drawbacks > > > > > > > > > > > > > > > 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" <[EMAIL PROTECTED]> > > > > > To: <[EMAIL PROTECTED]> > > > > > 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: > > > > <mailto:[EMAIL PROTECTED]> > > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > ---------- > > > -------- > > > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > -- > > > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > -------------------------------------------------------------- > ---------- > -------- > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
