xml-xalan-j-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Hersht <ig...@ca.ibm.com>
Subject RE: intermittent XALAN performance issue
Date Tue, 25 May 2004 19:26:23 GMT




It is really difficult to understand from this dump if it is a XALAN
performance issue,
but  we implemented some performance improvements (removing an extra
synchronization). The effects are important (but nothing like 15 seconds ->
27 minutes).
You might want to try the xalan from the latest CVS.
Let us know if you find that it is a XALAN.


Igor Hersht
XSLT Development
IBM Canada Ltd., 8200 Warden Avenue, Markham, Ontario L6G 1C7
Office D2-260, Phone (905)413-3240 ; FAX  (905)413-4839


                                                                           
             "Lagomasino,                                                  
             Adolfo (Adolfo)"                                              
             <adolfo@lucent.c                                           To 
             om>                      "'xalan-j-users@xml.apache.org'"     
                                      <xalan-j-users@xml.apache.org>       
             05/21/2004 03:15                                           cc 
             PM                                                            
                                                                   Subject 
                                      RE: intermittent XALAN performance   
                                      issue                                
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Each of these:
"ExecuteThread: '4' for queue: 'default'" daemon prio=5 tid=0x11dee0
nid=0x11 waiting on monitor [0xcfa81000..0xcfa819d8]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:415)
        at
weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:105)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)

means that there is a synchronized block of code that is waiting to be
notified. In the meantime the thread that is executing that code is doing
nothing.

If plenty of threads are in this state (100s) this will slow down the
system significantly. Those threads are being spun by weblogic, but I don't
know how or for what purpose.

Adolfo

-----Original Message-----
From: Holk, David A [mailto:david_a_holk@groton.pfizer.com]
Sent: Friday, May 21, 2004 2:58 PM
To: 'xalan-j-users@xml.apache.org'
Subject: RE: intermittent XALAN performance issue


Interesting.

I know this may be heading off-topic...

So it appears to you that threads 1,3,4 are hung? Because of the
Object.wait()? And from the trace it looks like these threads were spawned
by Weblogic?

Am I understanding this properly?

I apologize if these are dumb questions. I was unable to decipher the
thread
dump and your insight is GREATLY appreciated.

Dave



-----Original Message-----
From: Lagomasino, Adolfo (Adolfo) [mailto:adolfo@lucent.com]
Sent: Friday, May 21, 2004 2:30 PM
To: 'xalan-j-users@xml.apache.org'
Subject: RE: intermittent XALAN performance issue


Wild guess, but given that there are a large number of threads waiting to
be
notified, it might be possible that the Weblogic detects those hung threads
and cleans them after a while, putting the additional delay (27 minutes!)
in
your application.
The performance impact might have nothing to do with xalan, but with app
server.

Just a thought...
Adolfo

-----Original Message-----
From: Holk, David A [mailto:david_a_holk@groton.pfizer.com]
Sent: Friday, May 21, 2004 12:28 PM
To: 'xalan-j-users@xml.apache.org'
Subject: intermittent XALAN performance issue


Hi everyone, I've got a fun one here I hope one of you enlightened souls
can
help me with.

I am experiencing an intermittent performance problem with the
javax.xml.transform.Transformer.transform(src, res) call. I am using xalan
2.4.1.

 - When I run a specific transformation job (exact files data every time)
in
my development environment (Windows2000, Weblogic 7.1) it always takes
approximately 15 seconds.

 - When I run this same job in our test and production environments
(Solaris, Weblogic 7.1) it normally takes 15 seconds but sometimes takes
between 15 and 27 minutes to run.

 -  Sometimes if I restart the Weblogic server instance I am deploying to,
the job will go back to taking 15 seconds.

 - When the job appears to be hung, there are plenty of threads and plenty
of RAM available according to the Weblogic console.

I included a thread dump below from one of the Solaris boxes that was taken
while the job was hanging in hopes one of you can make more sense of it
than
I can.

Any insight or suggestions would be appreciated.

David Holk


"ExecuteThread: '4' for queue: 'default'" daemon prio=5 tid=0x11dee0
nid=0x11 waiting on monitor [0xcfa81000..0xcfa819d8]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:415)
        at
weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:105)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)

"ExecuteThread: '3' for queue: 'default'" daemon prio=5 tid=0x11d5a0
nid=0x10 waiting on monitor [0xcfb81000..0xcfb819d8]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:415)
        at
weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:105)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)

"ExecuteThread: '2' for queue: 'default'" daemon prio=5 tid=0x238510
nid=0xf
runnable [0xcfc81000..0xcfc819d8]
        at
java.io.ObjectOutputStream.writeStreamHeader(ObjectOutputStream.java:700)
        at java.io.ObjectOutputStream.<init>(ObjectOutputStream.java:154)
        at
weblogic.rjvm.OutboundMsgAbbrev.writeObject(OutboundMsgAbbrev.java:80)
        at
weblogic.rjvm.OutboundMsgAbbrev.writeAbbrevs(OutboundMsgAbbrev.java:60)
        at weblogic.rjvm.OutboundMsgAbbrev.write(OutboundMsgAbbrev.java:43)
        at
weblogic.rjvm.MsgAbbrevJVMConnection.writeMsgAbbrevs(MsgAbbrevJVMConnection.

java:186)
        at
weblogic.rjvm.MsgAbbrevJVMConnection.sendMsg(MsgAbbrevJVMConnection.java:154

)
        at
weblogic.rjvm.ConnectionManager.sendMsg(ConnectionManager.java:537)
        at weblogic.rjvm.RJVMImpl.send(RJVMImpl.java:541)
        at
weblogic.rjvm.MsgAbbrevOutputStream.flushAndSendRaw(MsgAbbrevOutputStream.ja

va:250)
        at
weblogic.rjvm.MsgAbbrevOutputStream.flushAndSend(MsgAbbrevOutputStream.java:

258)
        at
weblogic.rjvm.MsgAbbrevOutputStream.send(MsgAbbrevOutputStream.java:319)
        at
weblogic.t3.srvr.ClientRequest.tryToSendObject(ClientContext.java:646)
        at weblogic.t3.srvr.ClientRequest.execute(ClientContext.java:696)
        at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)

"ExecuteThread: '1' for queue: 'default'" daemon prio=5 tid=0x2383d0
nid=0xe
waiting on monitor [0xcfd81000..0xcfd819d8]
        at java.lang.Object.wait(Native Method)
        at java.lang.Object.wait(Object.java:415)
        at
weblogic.kernel.ExecuteThread.waitForRequest(ExecuteThread.java:105)
        at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:129)


LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential and may be
privileged. It is intended for the addressee(s) only. Access to this E-mail
by anyone else is unauthorized. If you are not an addressee, any disclosure
or copying of the contents of this E-mail or any action taken (or not
taken)
in reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately.



Mime
View raw message