That gets rid of the xalan file search, but the performance is still awful. For now I guess I'll try to look into xslt, but this looks like a bug that needs to be fixed or something. Who else needs to know about this to get it either fixed, or to tell me what else I might be doing wrong (if anything). Here's more of what truss is spitting out if that helps:
lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0) = 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x00000000) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778) = 0 lwp_mutex_lock(0x0002E778) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 lwp_mutex_unlock(0x0002E848) = 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 lwp_mutex_unlock(0x0002E848) = 0 lwp_mutex_lock(0x0002E848) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 lwp_cond_wait(0x0002E7F8, 0x0002E7E0, 0xEC681B08) = 0 lwp_cond_signal(0x0002E7F8) = 0 lwp_mutex_lock(0x0002E7E0) = 0 lwp_mutex_unlock(0x0002E7E0) = 0 lwp_mutex_lock(0x0002E710) = 0 lwp_cond_wait(0x0002E728, 0x0002E710, 0x00000000) = 0 lwp_cond_broadcast(0x0002E728) = 0 lwp_mutex_unlock(0x0002E778) = 0 lwp_mutex_lock(0x0002E778) = 0 lwp_mutex_lock(0x0002E848) = 0 lwp_cond_broadcast(0x0002E860) = 0 lwp_cond_wait(0x0002E860, 0x0002E848, 0x00000000) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 poll(0xE997FBC0, 0, 50) = 0 It looks like a lot of locking, unlocking and waiting to me, but what do I know? Any help you can get me in escalating this would be much appreciated. Thanks again, Chris -----Original Message----- From: Kris Schneider [mailto:[EMAIL PROTECTED] Sent: Monday, March 15, 2004 3:37 PM To: Tag Libraries Users List Subject: RE: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) Try adding -Dorg.apache.xml.dtm.DTMManager=org.apache.xml.dtm.ref.DTMManagerDefault to JAVA_OPTS. Quoting "Johnson, Chris" <[EMAIL PROTECTED]>: > Thanks, Kris. > > I did all that you suggested (setting the system properties and > installing new jars), and indeed tomcat doesn't seem to be searching > for the jaxp.properties file any longer. But, the performance is > still just about as bad as before. So, I did truss again and now > tomcat is looking for xalan.properties > (stat64("/usr/j2sdk1.4.2_03/jre/lib/xalan.properties", 0xDF47F850) > Err#2 ENOENT), just about as much, if not more, than it was for > jaxp.properties. So how can I fix this? > > Chris > > -----Original Message----- > From: Kris Schneider [mailto:[EMAIL PROTECTED] > Sent: Monday, March 15, 2004 2:32 PM > To: Tag Libraries Users List > Subject: Re: JSTL 1.1 jaxp problem (under tomcat 5.0.19/java 1.4.2_03) > > > Interesting. <x:forEach> has been tagged as a performance problem > before for JSTL 1.1, but without the accompanying truss info. The > XPath engine for JSTL was changed from Jaxen/SAXPath in 1.0 to Xalan > in 1.1. If you can replace <x:forEach> with <x:transform> and an XSLT > stylesheet, that seemed to help with the last performance issue. > Otherwise, you could try explicitly configuring JAXP by setting the > appropriate system properties (assuming Xerces and Xalan): > > env > JAVA_OPTS="-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerce > s. > jaxp.DocumentBuilderFactoryImpl > -Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFac > toryImpl > -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.Tran > sformerFactoryImpl" > $CATALINA_HOME/bin/startup.sh > > That way, jaxp.properties should never be searched for. You may also > want to download the latest Xalan release and dump the following in > $CATALINA_HOME/common/endorsed: > > xalan.jar > xercesImpl.jar > xml-apis.jar > > Quoting "Johnson, Chris" <[EMAIL PROTECTED]>: > > > Hello, > > > > I'm new to the world of JSP/JSTL, but have managed to get some code > > running under tomcat 4.1.29 (bundled with jboss 3.2.3 - as I'm using > > JMS too)/JSTL 1.0. I'm using java 1.4.2_03. > > > > I'm using only the c and x libraries currently, but wanted to use > > the > > new EL functions of JSTL 1.1, so I installed tomcat 5.0.19 alongside > > the previously mentioned jboss/tomcat versions. > > > > I've gotten the code to run under the new tomcat, but the > > performance > > is terrible. I've narrowed the performance problem down to any > > <x:forEach> loop. There wasn't anything of interest in the tomcat > > log, so I did a truss on the tomcat process, and found it spitting out > > > this error over and over: > > stat64("/usr/j2sdk1.4.2_03/jre/lib/jaxp.properties", > > 0xDF97FFF8) Err#2 ENOENT. I understand this to be tomcat looking for > > the jaxp.properties file and not finding it. I never saw this error > > message while trussing the tomcat 4.1.29 process, and it processes the > > xml extremely quickly. > > > > With the older tomcat and JSTL 1.0, I didn't have to do any special > > configuration of jaxp (I understood that to be built into java > > 1.4.2x), so I figured it would be the same with the newer tomcat, but > > I guess not. > > > > So far I've tried setting parser system properties in the web.xml > > and > > in files under META-INF with no change. What am I missing? If > > someone can just point me to some good docs on the subject, I'd > > appreciate it greatly. > > > > Thanks, > > Chris Johnson > > -- > Kris Schneider <mailto:[EMAIL PROTECTED]> > D.O.Tech <http://www.dotech.com/> -- Kris Schneider <mailto:[EMAIL PROTECTED]> D.O.Tech <http://www.dotech.com/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
