You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Berin Loritsch <bl...@apache.org> on 2001/08/09 17:23:06 UTC
IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load
Tests)
Berin Loritsch wrote:
>
> My initial JMeter load tests show no error messages and plenty of reason to smile.
> I simulated 20 users each hitting the server every 300ms. When the JVM was in
> a garbage collection cycle, the longest response time was 842ms. During normal
> opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10, 5% at 20)
> with occasional spikes around 100ms.
>
> I am going to up the JMeter load test to allow for 100 simultaneous users just to
> try and break it.
I ran it with 100 simultaneous users--and the longest processing times were still
less than 1.6 seconds (my magic "it takes too long on the server" time).
I wasn't satisfied, so I went with 200 simultaneous users. My longest processing
time was 3.135 seconds with one Resin Server through Apache, on a 750 MHz Athlon
and 256 MB RAM.
I can't break it with my hardware--can someone with an SMP machine (Symetric Multi-
Processing) try to break it?
Avalon + Cocoon ROCKS!
(sorry, I got a little enthusiastic there).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT BREAKS !!!
Posted by Donald Ball <ba...@webslingerZ.com>.
On Fri, 10 Aug 2001, Michael Hartle wrote:
> okay, I found the bastard that was causing all this trouble and almost
> made me believe Java as a whole isn't mature ;)
oh, no, say it ain't so... (sarcasm intended)
> Batik while generating images; the reason seems to be a concurrency
> issue in Suns sun.awt.image.codec.JPEGImageEncoderImpl.writeJPEGStream()
> function. If multiple users access dynamically generated images and a
> user disconnects while the image is being streamed, the VM blows in Suns
> JDK1.3.1, JDK1.4beta and in IBMs JDK1.3; at least the IBM implementation
> writes a proper dump file that contains useful information.
do you think that's something that batik could synchronize around? if so,
you should really post this to batik-dev.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT BREAKS !!!
Posted by Michael Hartle <mh...@hartle-klug.com>.
Hi all,
okay, I found the bastard that was causing all this trouble and almost
made me believe Java as a whole isn't mature ;)
Berin was right, the VM got killed due to the complex interaction of
Batik while generating images; the reason seems to be a concurrency
issue in Suns sun.awt.image.codec.JPEGImageEncoderImpl.writeJPEGStream()
function. If multiple users access dynamically generated images and a
user disconnects while the image is being streamed, the VM blows in Suns
JDK1.3.1, JDK1.4beta and in IBMs JDK1.3; at least the IBM implementation
writes a proper dump file that contains useful information.
Best regards,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT BREAKS !!!
Posted by Berin Loritsch <bl...@apache.org>.
> 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.
By the way, Avalon Excalibur can be compiled under JDK 1.4 to give you
support for JDBC 3.0--and the classes will still work with previous
JDKs.
The support was added in about 3 weeks ago (has it been that long
already?).
BATIK is another story altogether.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT BREAKS !!!
Posted by Berin Loritsch <bl...@apache.org>.
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.
I have found that certain things work without hitch (after today's
updates)
and others do not. I would place Batik at an experimental stage for the
server side. The reason being is that Batik itself is reliant on the
server's
graphic system--the complexities involved rank this a bad performer and
not suitable for repeated access. I would recommend serializing the png
or jpg that Batik produces to a file, and serve that up in a production
environment.
I have also found (today) that the XSP system is in serious need of
refactoring. Again, it is a very complex beast with many moving parts.
There is a memory "leak" in there somewhere, and I am trying to narrow
it
down, but I haven't been able to do that yet.
In order to bypass these issues, I suggest generating the XSP classes
using the command line approach. Then JAR the resulting classes and
place them in the libs directory. The painful part is what comes next:
everyplace you use a serverpages generator, you have to replace that
generator with the one created by Cocoon for you. For example:
<map:generators>
<!-- Remove this: <map:generator name="serverpages"
class="org.apache.cocoon.generators.ServerPagesGenerator"/> -->
<map:generator name="specific"
class="org.apache.cocoon.www.file_c_.webapp.cocoon.Specific_xsp"/>
</map:generators>
<!-- skip -->
<map:match pattern="specific.html">
<map:generator type="specific"/>
<map:serializer/>
</map:match>
This bypasses the entire XSP system at runtime. Normal Generators,
Transformers,
Serializers, and Readers all function well under load. With XML file
generation
through transformation and serialization, I was able to sustain 200
users slamming
my system without problem. The Batik and XSP subsystems are apparently
fragile though.
Hopefully the XSP system will be able to be repaired and work flawlessly
again soon.
Until then we might need a system to generate a "production" war from a
development
war. (I.e. makes all the XSP conversions and Batik conversions for
you).
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT BREAKS !!!
Posted by "Stuart Roebuck (BlueYonder)" <st...@mac.com>.
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
Re: IT BREAKS !!!
Posted by Michael Hartle <mh...@hartle-klug.com>.
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
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon
Load Tests)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>
> Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
> And may be not. :-/
I wonder if there are issues getting the builtin logicsheets from the jar under extreme load...
Checking the logs, I am seeing the same EXCEPTION_ACCESS_VIOLATION message--though I don't get
a stacktrace.
>
> ------------------------------
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
> Function name=ZIP_Open
> Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
>
> Current Java thread:
> at java.util.zip.ZipFile.getEntry(Native Method)
> at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
> at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
> at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
> at com.caucho.vfs.Jar.isFile(Jar.java:142)
> at com.caucho.vfs.Jar.canRead(Jar.java:207)
> at com.caucho.vfs.JarPath.canRead(JarPath.java:145)
> at com.caucho.util.DirectoryClassLoader.getPath(DirectoryClassLoader.java:213)
> at com.caucho.util.DynamicClassLoader.getResourceAsStream(DynamicClassLoader.java:566)
> at org.apache.xml.dtm.DTMManager.findFactory(DTMManager.java:474)
> at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:175)
> at org.apache.xpath.XPathContext.reset(XPathContext.java:337)
> at org.apache.xalan.transformer.TransformerImpl.reset(TransformerImpl.java:469)
> at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1197)
> at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3094)
> at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:467)
> at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:52)
> at org.apache.cocoon.generation.ServerPagesGenerator.endDocument(ServerPagesGenerator.java:253)
> at www.docs.samples.xsp.simple_xsp.generate(simple_xsp.java:406)
> at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:183)
> at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:219)
> at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:363)
> at www.sitemap_xmap.wildcardMatchN41A(sitemap_xmap.java:5557)
> at www.sitemap_xmap.process(sitemap_xmap.java:2453)
> at www.sitemap_xmap.process(sitemap_xmap.java:2094)
> at org.apache.cocoon.sitemap.Handler.process(Handler.java:160)
> at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:103)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:423)
> at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:518)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
> at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:82)
> at com.caucho.server.http.Invocation.service(Invocation.java:272)
> at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:216)
> at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:158)
> at com.caucho.server.TcpConnection.run(TcpConnection.java:140)
> at java.lang.Thread.run(Thread.java:484)
> ----------------------------------------
>
> Vadim
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, August 09, 2001 2:37 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
> >
> >
> > Stuart Roebuck wrote:
> > >
> > > That sounds like a problem I'm just having too, I've got quite a bit of
> > > XSP in my test cases, and Tomcat is just dieing without any errors
> > > displayed at all. In fact I've looked in every log I can think of (tomcat,
> > > cocoon, system) and I can't see any evidence of anything going wrong!
> > >
> > > Stuart.
> > >
> > > On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
> > >
> > > > I found a problem:
> > > >
> > > > Cocoon takes all available memory after ~ 500-600 accesses to
> > > > http://localhost:8080/cocoon/xsp/simple
> > > > and Resin crashes:
> > > > #
> > > > # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> > > > code outside the VM.
> > > > # Program counter=0x50397707
> > > > #
> > > >
> > > > Clearly, something is wrong with XSP... Some resources are not released.
> > > > cocoon.log file does not have any errors.
> > > >
> > > > Berin,
> > > > could you verify this behaviour?
> >
> > Ok, I verified it. Let me do some more checking--the issues in this
> > case lie on the Cocoon side of things. I _think_ I have an idea
> > what it is--but no guarantees.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo yourCocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
Donald,
You are right about Resin: it have a problem with Zip files...
Under Tomcat (4.0b5) I have got another interesting exception:
2001-08-09 15:59:25 StandardWrapperValve[Cocoon2]: Servlet.service() for servlet Cocoon2 threw exception
java.lang.NullPointerException
at org.apache.cocoon.components.source.URLSource.getInfos(URLSource.java:100)
at org.apache.cocoon.components.source.URLSource.getLastModified(URLSource.java:115)
at org.apache.cocoon.Cocoon.modifiedSince(Cocoon.java:320)
at org.apache.cocoon.servlet.CocoonServlet.getCocoon(CocoonServlet.java:719)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:461)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:254)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:194)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:255)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:225)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2252)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:163)
at org.apache.catalina.core.StandardPipeline.invokeNext(StandardPipeline.java:566)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:472)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:943)
at org.apache.catalina.connector.http.HttpProcessor.process(HttpProcessor.java:875)
at org.apache.catalina.connector.http.HttpProcessor.run(HttpProcessor.java:952)
at java.lang.Thread.run(Thread.java:484)
This is from tomcat.log, cocoon.log is empty. URL is /cocoon/xsp/simple, 50 threads, gaussian timer on 100ms.
I have got 17 exceptions per 1900 processed requests.
Is it possible that URLSource object is used by more then one thread?
Vadim
> -----Original Message-----
> From: Donald Ball [mailto:balld@webslingerZ.com]
> Sent: Thursday, August 09, 2001 3:14 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo yourCocoon Load Tests)
>
>
> On Thu, 9 Aug 2001, Vadim Gritsenko wrote:
>
> > Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
> > And may be not. :-/
> >
> > ------------------------------
> > An unexpected exception has been detected in native code outside the VM.
> > Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
> > Function name=ZIP_Open
> > Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
> >
> > Current Java thread:
> > at java.util.zip.ZipFile.getEntry(Native Method)
> > at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
> > at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
> > at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
> > at com.caucho.vfs.Jar.isFile(Jar.java:142)
> > at com.caucho.vfs.Jar.canRead(Jar.java:207)
>
> i think you've probably found a synchronization bug in resin, actually.
> there was a little thread about this on resin-interest a few days ago. do
> you get the same results in tomcat? you might want to post this stacktrace
> to resin-interest.
>
> - donald
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your
Cocoon Load Tests)
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 9 Aug 2001, Vadim Gritsenko wrote:
> Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
> And may be not. :-/
>
> ------------------------------
> An unexpected exception has been detected in native code outside the VM.
> Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
> Function name=ZIP_Open
> Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
>
> Current Java thread:
> at java.util.zip.ZipFile.getEntry(Native Method)
> at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
> at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
> at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
> at com.caucho.vfs.Jar.isFile(Jar.java:142)
> at com.caucho.vfs.Jar.canRead(Jar.java:207)
i think you've probably found a synchronization bug in resin, actually.
there was a little thread about this on resin-interest a few days ago. do
you get the same results in tomcat? you might want to post this stacktrace
to resin-interest.
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
Hm, with JDK1.3.1 I have got some interesting info; may be it can help you to find the problem.
And may be not. :-/
------------------------------
An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0x6d3c76aa
Function name=ZIP_Open
Library=C:\Java\jdk1.3.1\jre\bin\zip.dll
Current Java thread:
at java.util.zip.ZipFile.getEntry(Native Method)
at java.util.zip.ZipFile.getEntry(ZipFile.java:146)
at com.caucho.vfs.Jar.getJarEntry(Jar.java:346)
at com.caucho.vfs.Jar.getSafeJarEntry(Jar.java:325)
at com.caucho.vfs.Jar.isFile(Jar.java:142)
at com.caucho.vfs.Jar.canRead(Jar.java:207)
at com.caucho.vfs.JarPath.canRead(JarPath.java:145)
at com.caucho.util.DirectoryClassLoader.getPath(DirectoryClassLoader.java:213)
at com.caucho.util.DynamicClassLoader.getResourceAsStream(DynamicClassLoader.java:566)
at org.apache.xml.dtm.DTMManager.findFactory(DTMManager.java:474)
at org.apache.xml.dtm.DTMManager.newInstance(DTMManager.java:175)
at org.apache.xpath.XPathContext.reset(XPathContext.java:337)
at org.apache.xalan.transformer.TransformerImpl.reset(TransformerImpl.java:469)
at org.apache.xalan.transformer.TransformerImpl.transformNode(TransformerImpl.java:1197)
at org.apache.xalan.transformer.TransformerImpl.run(TransformerImpl.java:3094)
at org.apache.xalan.transformer.TransformerHandlerImpl.endDocument(TransformerHandlerImpl.java:467)
at org.apache.cocoon.xml.AbstractXMLPipe.endDocument(AbstractXMLPipe.java:52)
at org.apache.cocoon.generation.ServerPagesGenerator.endDocument(ServerPagesGenerator.java:253)
at www.docs.samples.xsp.simple_xsp.generate(simple_xsp.java:406)
at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:183)
at org.apache.cocoon.components.pipeline.CachingEventPipeline.process(CachingEventPipeline.java:219)
at org.apache.cocoon.components.pipeline.CachingStreamPipeline.process(CachingStreamPipeline.java:363)
at www.sitemap_xmap.wildcardMatchN41A(sitemap_xmap.java:5557)
at www.sitemap_xmap.process(sitemap_xmap.java:2453)
at www.sitemap_xmap.process(sitemap_xmap.java:2094)
at org.apache.cocoon.sitemap.Handler.process(Handler.java:160)
at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:103)
at org.apache.cocoon.Cocoon.process(Cocoon.java:423)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:518)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:103)
at com.caucho.server.http.FilterChainServlet.doFilter(FilterChainServlet.java:82)
at com.caucho.server.http.Invocation.service(Invocation.java:272)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:216)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:158)
at com.caucho.server.TcpConnection.run(TcpConnection.java:140)
at java.lang.Thread.run(Thread.java:484)
----------------------------------------
Vadim
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, August 09, 2001 2:37 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
>
>
> Stuart Roebuck wrote:
> >
> > That sounds like a problem I'm just having too, I've got quite a bit of
> > XSP in my test cases, and Tomcat is just dieing without any errors
> > displayed at all. In fact I've looked in every log I can think of (tomcat,
> > cocoon, system) and I can't see any evidence of anything going wrong!
> >
> > Stuart.
> >
> > On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
> >
> > > I found a problem:
> > >
> > > Cocoon takes all available memory after ~ 500-600 accesses to
> > > http://localhost:8080/cocoon/xsp/simple
> > > and Resin crashes:
> > > #
> > > # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> > > code outside the VM.
> > > # Program counter=0x50397707
> > > #
> > >
> > > Clearly, something is wrong with XSP... Some resources are not released.
> > > cocoon.log file does not have any errors.
> > >
> > > Berin,
> > > could you verify this behaviour?
>
> Ok, I verified it. Let me do some more checking--the issues in this
> case lie on the Cocoon side of things. I _think_ I have an idea
> what it is--but no guarantees.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon
Load Tests)
Posted by Berin Loritsch <bl...@apache.org>.
Stuart Roebuck wrote:
>
> That sounds like a problem I'm just having too, I've got quite a bit of
> XSP in my test cases, and Tomcat is just dieing without any errors
> displayed at all. In fact I've looked in every log I can think of (tomcat,
> cocoon, system) and I can't see any evidence of anything going wrong!
>
> Stuart.
>
> On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
>
> > I found a problem:
> >
> > Cocoon takes all available memory after ~ 500-600 accesses to
> > http://localhost:8080/cocoon/xsp/simple
> > and Resin crashes:
> > #
> > # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> > code outside the VM.
> > # Program counter=0x50397707
> > #
> >
> > Clearly, something is wrong with XSP... Some resources are not released.
> > cocoon.log file does not have any errors.
> >
> > Berin,
> > could you verify this behaviour?
Ok, I verified it. Let me do some more checking--the issues in this
case lie on the Cocoon side of things. I _think_ I have an idea
what it is--but no guarantees.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Stuart Roebuck <st...@adolos.co.uk>.
That sounds like a problem I'm just having too, I've got quite a bit of
XSP in my test cases, and Tomcat is just dieing without any errors
displayed at all. In fact I've looked in every log I can think of (tomcat,
cocoon, system) and I can't see any evidence of anything going wrong!
Stuart.
On Thursday, August 9, 2001, at 07:11 pm, Vadim Gritsenko wrote:
> I found a problem:
>
> Cocoon takes all available memory after ~ 500-600 accesses to
> http://localhost:8080/cocoon/xsp/simple
> and Resin crashes:
> #
> # An EXCEPTION_ACCESS_VIOLATION exception has been detected in native
> code outside the VM.
> # Program counter=0x50397707
> #
>
> Clearly, something is wrong with XSP... Some resources are not released.
> cocoon.log file does not have any errors.
>
> Berin,
> could you verify this behaviour?
>
> Vadim
>
>> -----Original Message-----
>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>> Sent: Thursday, August 09, 2001 12:24 PM
>> To: cocoon-dev@xml.apache.org
>> Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your
>> Cocoon Load Tests)
>>
>>
>> Vadim Gritsenko wrote:
>>>
>>>> -----Original Message-----
>>>> From: Berin Loritsch [mailto:bloritsch@apache.org]
>>>> Sent: Thursday, August 09, 2001 11:23 AM
>>>> To: cocoon-dev@xml.apache.org
>>>> Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your
>>>> Cocoon Load Tests)
>>>>
>>>>
>>>> Berin Loritsch wrote:
>>>>>
>>>>> My initial JMeter load tests show no error messages and plenty of
>>>>> reason to smile.
>>>>> I simulated 20 users each hitting the server every 300ms. When the
>>>>> JVM was in
>>>>> a garbage collection cycle, the longest response time was 842ms.
>>>>> During normal
>>>>> opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10,
>>>>> 5% at 20)
>>>>> with occasional spikes around 100ms.
>>>>>
>>>>> I am going to up the JMeter load test to allow for 100 simultaneous
>>>>> users just to
>>>>> try and break it.
>>>>
>>>> I ran it with 100 simultaneous users--and the longest processing
>>>> times were still
>>>> less than 1.6 seconds (my magic "it takes too long on the server"
>>>> time).
>>>>
>>>> I wasn't satisfied, so I went with 200 simultaneous users. My
>>>> longest processing
>>>> time was 3.135 seconds with one Resin Server through Apache, on a 750
>>>> MHz Athlon
>>>> and 256 MB RAM.
>>>>
>>>
>>> I assume this results are for static resource (/welcome?), how about
>>> dynamic resources?
>>> (simple sql or esql)?
>>
>> I'll let you know in a bit. in the mean time, run some tests of your
>> own and give some
>> feedback.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
>> For additional commands, email: cocoon-dev-help@xml.apache.org
>>
>
> ---------------------------------------------------------------------
> 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
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
I found a problem:
Cocoon takes all available memory after ~ 500-600 accesses to http://localhost:8080/cocoon/xsp/simple
and Resin crashes:
#
# An EXCEPTION_ACCESS_VIOLATION exception has been detected in native code outside the VM.
# Program counter=0x50397707
#
Clearly, something is wrong with XSP... Some resources are not released.
cocoon.log file does not have any errors.
Berin,
could you verify this behaviour?
Vadim
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, August 09, 2001 12:24 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
>
>
> Vadim Gritsenko wrote:
> >
> > > -----Original Message-----
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > > Sent: Thursday, August 09, 2001 11:23 AM
> > > To: cocoon-dev@xml.apache.org
> > > Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
> > >
> > >
> > > Berin Loritsch wrote:
> > > >
> > > > My initial JMeter load tests show no error messages and plenty of reason to smile.
> > > > I simulated 20 users each hitting the server every 300ms. When the JVM was in
> > > > a garbage collection cycle, the longest response time was 842ms. During normal
> > > > opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10, 5% at 20)
> > > > with occasional spikes around 100ms.
> > > >
> > > > I am going to up the JMeter load test to allow for 100 simultaneous users just to
> > > > try and break it.
> > >
> > > I ran it with 100 simultaneous users--and the longest processing times were still
> > > less than 1.6 seconds (my magic "it takes too long on the server" time).
> > >
> > > I wasn't satisfied, so I went with 200 simultaneous users. My longest processing
> > > time was 3.135 seconds with one Resin Server through Apache, on a 750 MHz Athlon
> > > and 256 MB RAM.
> > >
> >
> > I assume this results are for static resource (/welcome?), how about dynamic resources?
> > (simple sql or esql)?
>
> I'll let you know in a bit. in the mean time, run some tests of your own and give some
> feedback.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon
Load Tests)
Posted by Berin Loritsch <bl...@apache.org>.
Vadim Gritsenko wrote:
>
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Thursday, August 09, 2001 11:23 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
> >
> >
> > Berin Loritsch wrote:
> > >
> > > My initial JMeter load tests show no error messages and plenty of reason to smile.
> > > I simulated 20 users each hitting the server every 300ms. When the JVM was in
> > > a garbage collection cycle, the longest response time was 842ms. During normal
> > > opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10, 5% at 20)
> > > with occasional spikes around 100ms.
> > >
> > > I am going to up the JMeter load test to allow for 100 simultaneous users just to
> > > try and break it.
> >
> > I ran it with 100 simultaneous users--and the longest processing times were still
> > less than 1.6 seconds (my magic "it takes too long on the server" time).
> >
> > I wasn't satisfied, so I went with 200 simultaneous users. My longest processing
> > time was 3.135 seconds with one Resin Server through Apache, on a 750 MHz Athlon
> > and 256 MB RAM.
> >
>
> I assume this results are for static resource (/welcome?), how about dynamic resources?
> (simple sql or esql)?
I'll let you know in a bit. in the mean time, run some tests of your own and give some
feedback.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
Posted by Vadim Gritsenko <vg...@hns.com>.
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Thursday, August 09, 2001 11:23 AM
> To: cocoon-dev@xml.apache.org
> Subject: IT WON'T BREAK!!! (was Re: New Excalibur--Time to redo your Cocoon Load Tests)
>
>
> Berin Loritsch wrote:
> >
> > My initial JMeter load tests show no error messages and plenty of reason to smile.
> > I simulated 20 users each hitting the server every 300ms. When the JVM was in
> > a garbage collection cycle, the longest response time was 842ms. During normal
> > opperation, responses were between 0ms and 20ms (55% at 0, 40% at 10, 5% at 20)
> > with occasional spikes around 100ms.
> >
> > I am going to up the JMeter load test to allow for 100 simultaneous users just to
> > try and break it.
>
> I ran it with 100 simultaneous users--and the longest processing times were still
> less than 1.6 seconds (my magic "it takes too long on the server" time).
>
> I wasn't satisfied, so I went with 200 simultaneous users. My longest processing
> time was 3.135 seconds with one Resin Server through Apache, on a 750 MHz Athlon
> and 256 MB RAM.
>
I assume this results are for static resource (/welcome?), how about dynamic resources?
(simple sql or esql)?
Vadim
> I can't break it with my hardware--can someone with an SMP machine (Symetric Multi-
> Processing) try to break it?
>
> Avalon + Cocoon ROCKS!
>
> (sorry, I got a little enthusiastic there).
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org