cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuartroeb...@mac.com (BlueYonder)>
Subject Re: IT BREAKS !!!
Date Fri, 10 Aug 2001 00:19:49 GMT
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: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                           <http://www.adolos.com/>

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message