Unfortunately, none that I know of. Scott Nichol
Do not send e-mail directly to this e-mail address, because it is filtered to accept only mail from specific mail lists. ----- Original Message ----- From: "Tudor, Liviu @Cimage" <[EMAIL PROTECTED]> To: "Scott Nichol" <[EMAIL PROTECTED]> Sent: Wednesday, February 04, 2004 7:49 AM Subject: RE: Long delays experienced with Apache SOAP due to the HTTPUtils.post method Scott, are there some resources on the web that presents comparisons in between Axis and SOAP in terms of performance/speed/memory consumption? Thanks! Liviu Tudor Cimage Novasoft Limited www.cimagenovasoft.com [EMAIL PROTECTED] Fax: +44 (0)1344 767701 Direct Line: +44 (0)1344 767759 Centennial Court, Easthampstead Road, Bracknell, BERKS, RG12 1JZ Real programmers don't comment their code. If it was hard to write, it should be hard to understand. -----Original Message----- From: Scott Nichol [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 04, 2004 12:19 PM To: Tudor, Liviu @Cimage; [EMAIL PROTECTED] Subject: Re: Long delays experienced with Apache SOAP due to the HTTPUtils.post method Handling large SOAP payloads is something Apache SOAP is known to do slowly, but there is no major improvement planned. Several places, the code works with the payload in DOM form. Changing to something that would be faster and require less memory (e.g. using a SAX or pull parser) would require too much work. Axis, the next generation of Apache SOAP, does *not* use a DOM parser. Scott Nichol Do not send e-mail directly to this e-mail address, because it is filtered to accept only mail from specific mail lists. ----- Original Message ----- From: "Tudor, Liviu @Cimage" <[EMAIL PROTECTED]> To: "Scott Nichol" <[EMAIL PROTECTED]> Sent: Wednesday, February 04, 2004 6:13 AM Subject: RE: Long delays experienced with Apache SOAP due to the HTTPUtils.post method Hi Scott, thanks for the reply! Nagling didn't improve the speed too much, however, out of a sudden I think actually the problem relies on the IIS/.NET side -- due to the way the system is configured it looks like .NET takes a while to load/start/run the webservice itself, hence the initial delay. Still, there is the problem of very long XML responses which of course are read in a memory-buffer on Apache SOAP's side, but I suppose this cannot be improved/avoided in any way -- or .. can it? :O Thanks anyway for the response, and sorry for not having checked more thoroughly in the first place! Regards, Liviu Tudor Cimage Novasoft Limited www.cimagenovasoft.com [EMAIL PROTECTED] Fax: +44 (0)1344 767701 Direct Line: +44 (0)1344 767759 Centennial Court, Easthampstead Road, Bracknell, BERKS, RG12 1JZ Real programmers don't comment their code. If it was hard to write, it should be hard to understand. -----Original Message----- From: Scott Nichol [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 03, 2004 5:31 PM To: [EMAIL PROTECTED]; Tudor, Liviu @Cimage Subject: Re: Long delays experienced with Apache SOAP due to the HTTPUtils.post method The parsing itself does not take a second. The delay is presumably in reading data being returned, or even in sending the data, although 1 second is still a very long time. The first suggestion is to disable Nagling. This is done by calling setTcpNoDelay() on the SOAPHTTPConneciton class. Scott Nichol Do not send e-mail directly to this e-mail address, because it is filtered to accept only mail from specific mail lists. ----- Original Message ----- From: "Tudor, Liviu @Cimage" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, February 03, 2004 12:03 PM Subject: Long delays experienced with Apache SOAP due to the HTTPUtils.post method Hi everyone! I am currently using Apache SOAP 2.3.1 together with JDK 1.4 and Xerces-J 2.0.0; I have written some proxy classes to access a few webservices written in .NET and it worked fine; however at some point I came across some delays during the synchronuous calls made from my proxies to the .NET side. I've added extra logging in my classes and it transpired that the actual delay occurs in the Message.send function. Further refinements of my searches showed in the end that the "bottleneck" is actually in the HTTPUtils function in the function send, in between the following lines: BufferedInputStream bInStream = new BufferedInputStream(inStream); /* Read the response status line. */ int statusCode = 0; String statusString = null; StringBuffer linebuf = new StringBuffer(); int b = 0; while (b != '\n' && b != -1) { b = bInStream.read(); if (b != '\n' && b != '\r' && b != -1) linebuf.append((char)b); } String line = linebuf.toString(); try { StringTokenizer st = new StringTokenizer(line); st.nextToken(); // ignore version part statusCode = Integer.parseInt (st.nextToken()); StringBuffer sb = new StringBuffer(); while (st.hasMoreTokens()) { sb.append (st.nextToken()); if (st.hasMoreTokens()) { sb.append(" "); } } statusString = sb.toString(); } catch (Exception e) { throw new IllegalArgumentException( "Error parsing HTTP status line \"" + line + "\": " + e); } It seem that the actual parsing of the status line takes over a second, on a "normal" PIII 800 MHz with 512 MB of RAM, which is quite a delay. Also, the same problem seems to appear in one of our customers' site, who's running BEA WebLogic on a Sparc quad-processor machine with 2 Gb of RAM. Has anyone encountered this before and is there a way to bypass it? Regards, Liviu Tudor Cimage Novasoft Limited www.cimagenovasoft.com [EMAIL PROTECTED] Fax: +44 (0)1344 767701 Direct Line: +44 (0)1344 767759 *Centennial Court, Easthampstead Road, Bracknell, BERKS, RG12 1JZ Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
