Toshi, Thanks, I downloaded the source (1.1) late Friday but haven't had a chance to look at it yet. What you're saying is definitely consistent with my findings. Don't know if it's workable but I was going to look at using a ThreadLocal to bypass synchronization but as I said I haven't looked at the code yet.
The testing scenario definitely is a factor it was specifically designed to trip over synchronization; I expected to find it in our App which is brand new. I only discovered this issue because I started trying to isolate it working in from the front (since I've never performance tuned Linux/Tomcat before I felt I'd get a better feel for having got it right if I understood how the various components behaved) rather than working back from our App. Interestingly I saw a similar pattern just retrieving a gif from Tomcat, albeit at 950 users with a 520mS response time, so perhaps the test was a little too brutal. Thanks Ray Sutton Systems Engineer -----Original Message----- From: Toshiyuki Kimura [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 7:03 PM To: '[EMAIL PROTECTED]' Subject: RE: Axis Response Time appears linear with load Hi Ray, It seems your problem is from a synchronized block for a DocumentBuilderFactory. Axis is pooling parser instances, however the current is using only one dbf instance at least. But, I think also this bottle-neck might be caused by your testing scenarios.I mean the neck might make it hard to find out if you use a real implementation of your business-logics as an end-point. Anyway, if you hope to clear the matter and also you help us to fix it, we may provide a snapshot patch for testing. -- Toshi <[EMAIL PROTECTED]> On Fri, 3 Oct 2003, Sutton, Ray wrote: > > To answer Toshi's comment, the configuration I was testing loop a response > back in the method proxy, the test payload is an echo request so I was able > to simply instantiate our response object and move the payload without > entering our application framework. The only non-Axis/infrastructure > processing is instantiate, move object reference, return. I'll double check > the instantiate doesn't involve a synchronize though. > > The thread dump as requested, I've trimmed it to the lock holder and one on > the waiters, the other two were at the same location in code. > > "Thread-23" daemon prio=5 tid=0x03650408 nid=0xfd8 runnable > [43df000..43dfd94] > at > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(Unknown > Source) > at org.apache.axis.utils.XMLUtils.newDocument(XMLUtils.java:318) > - locked <0x10ac8688> (a > org.apache.xerces.jaxp.DocumentBuilderFactoryImpl) > at The information in this electronic mail message is sender's business Confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this Internet electronic mail message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. The sender believes that this E-mail and any attachments were free of any virus, worm, Trojan horse, and/or malicious code when sent. This message and its attachments could have been infected during transmission. By reading the message and opening any attachments, the recipient accepts full responsibility for taking protective and remedial action about viruses and other defects. Galileo International is not liable for any loss or damage arising in any way from this message or its attachments.