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,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
