Pavel,
I could not use patch on these patches, apparently because they are done
against older CVS versions. I need the diffs against the current CVS
sources. Also, please send diffs for all 5 files (SOAPContext, Call,
TransportMessage, RPCJavaProvider, RPCRouterServlet).
Thanks.
Scott Nichol
----- Original Message -----
From: "Pavel Ausianik" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, November 20, 2002 6:09 AM
Subject: RE: Using mime parts - huge drawbacks
> Scott,
>
> It seems like two bugs fixed.
>
> One is related to missed fillRootPart() in SOAPContext.writeTo()
> Second is relates on how content type identified in case envelope is
set
> Attaching a patch against current cvs
>
> During mime test execution I had one error related to SOAP registry
>
> Generated fault: [Attributes={}] [faultCode=SOAP-ENV:Server]
> [faultString=java.l
> ang.IllegalArgumentException: No mapping found for 'java.lang.Object'
using
> enco
> ding style 'http://schemas.xmlsoap.org/soap/encoding/'.]
> [faultActorURI=/soap/se
> rvlet/rpcrouter] [DetailEntries=] [FaultEntries=]
>
> This should not be related to Mime Part, and I'll look at this Friday
(sorry
> busy today-tomorrow)
>
> Best regards,
> Pavel
>
>
>
> > -----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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
