Ray, I think what you're asking is org.apache.axis.utils. XMLUtils.java. If you're using Axis 1.1 final, you can see the synchronized block around the line 317. The thread dump also pointed out the code.
-- Toshi <[EMAIL PROTECTED]> On Mon, 6 Oct 2003, Sutton, Ray wrote: > 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. > > > -- Toshi <[EMAIL PROTECTED]>
