cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hartle <>
Subject Re: IT BREAKS !!!
Date Thu, 09 Aug 2001 22:44:28 GMT
Hello all,

I do not want to spoil the party, but today I had a real nightmare 
regarding exactly this topic at a customer's site. On a P3/550 with 128 
MB RAM running a Windows 2000 Server plus MS SQL-Server 8(?), I tried 
every combination of elements from the following categories to get a 
rock stable system setup, without any chance.

(JDK1.3.1 | JDK1.4),  (Server VM | Hotspot VM), (Tomcat 3.23 | Tomcat 
3.3b1 | Tomcat 4.0b6 | Resin 2.01), (Cocoon2.0b2 with current 
Batik1.0RC?), (freetds_jdbc)

The symptoms were all the same; when coming under high load / situations 
when many network connections arrive, the process containing the VM 
running the servlet container either disappears without any trace at all 
or shows access violations outside of the VM; I had violations in 
ntdl.dll (something like that), zip.dll (in the JDK-dir, especially with 
Resin) and the like. I wasn't able to keep a server up and running for 
longer than 20-30 minutes without loosing the process containing the VM.

All of the JDK1.3.1 combinations basically worked at first glance and 
got tested; testing the system with both JMeter and manually under load, 
I could easily crash all setups using a sample page containing 15 
buttons with JavaScript rollovers which are all batik-generated; moving 
the mouse over the buttons in IE 5 when the buttons and their rollovers 
have not been completely loaded was a sure killer for any setup ! Tomcat 
3.3b1 made the most stable impression (it survived several "rollover 
mouse whooshes") and still had quite good performance results compared 
to the others, but a classloader bug which got discussed some time ago 
(confirmed by Berin in one posting, IIRC) prevents changes in XSPs 
without restarting the servlet container; quite a showstopper when 
developing applications.

In combination with JDK1.4, Tomcat 4.0b6 was the only servlet container 
which I got starting at all; sadly, all SVG2JPG output via batik was 
blank, and as this is a major requirement for me, I did no further 
testing here, but the basic stuff leaving out critical JDK1.4 issues 
like JDBC 3.0 database access and the like worked until it died like the 
rest. All other servlet containers failed in combination with JDK1.4 due 
to Cocoon complaining on missing lexical handler support of the crimson 
XML parser, although I haven't got the slightest idea how this error 
could result as I removed all other parser.jars, jaxp.jars and the like, 
put xerces in the relevant lib directory and even updated the tools.jar 
in cocoon/WEB-INF/lib to the one provided with the JDK1.4; changing the 
JDK back to 1.3.1 and changing back the tools.jar made this particularly 
irritating problem disappear.

Tomorrow (ouch... ok, today) I will try putting a servlet container 
behind either IIS or Apache; I currently hope that what I assume as VM 
crashes results in problems with the native networking code in both JDKs 
when it comes to rapidly opened/closed connections or the like, which 
might be prevented when putting something rock-solid in front. Another 
hope is that playing around with -Xmx and similar options provides a 
reliable solution which I *badly* need.

Best regards,


To unsubscribe, e-mail:
For additional commands, email:

View raw message