One little thing that I've come across in my tests... so far, running
under Java 1.3 (I'm on Mac OS X) I don't have this problem. I haven't
done anything really extensive, but it was coming up fairly quickly as a
problem under 1.3.1, so this may point to something that changed in the
non-native code between 1.3 and 1.3.1. (I say non-native because it
appears to be coming up on Windows as well as various Unixes, but that may
be a big assumption.)
Stuart.
On Thursday, August 9, 2001, at 11:44 pm, Michael Hartle wrote:
> 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]
>
-------------------------------------------------------------------------
Stuart Roebuck [EMAIL PROTECTED]
Lead Developer Java, XML, MacOS X, XP, etc.
ADOLOS <http://www.adolos.com/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]