cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: couple of problems exposed under heavy load
Date Thu, 05 Jul 2001 12:57:54 GMT
Donald Ball wrote:
> 
> On Mon, 2 Jul 2001, Berin Loritsch wrote:
> 
> > > heya. i recently got my tomcat-catalina and my apache talking to each
> > > other, hurrah. i took the opportunity to load test my cocoon webapp.
> > > overall, it held up pretty nicely, but when i cranked up the concurrency,
> > > i started getting some exceptions here and there. one was:
> > >
> > > DEBUG   28325   [cocoon  ] (Ajp13Processor[8009][10]): UnnamedSelector:
> > > ComponentSelector could not access the Component for hint: html
> > > java.lang.Exception: Could not create enough Components to service your
> > > request.
> >
> > This was probably due to limits of your JVM.  When we are getting Components
> > from a pool, Excalibur (used by Cocoon) will create new instances of the
> > Components when needed.  If the JVM cannot create a new Component, then it
> > will throw an exception, and you will see the error message above.
> 
> how can i determine the underlying exception? if it's OutOfMemory, i'd
> like to know that. i didn't see any OutOfMemoryExceptions in the log files
> anywhere - or anything else which indicated a jvm problem creating a new
> object.


It is not necessarily an OutOfMemoryException.  The creation of a Component is
pretty extensive, and the Class very well may have been instantiated, but one
of the initialization stages may have failed--either because your JVM could not
resolve a reference fast enough, or because of some other complex system
interaction.  Nine times out of ten, it is due to some complex system interaction
that with free/inexpensive tools cannot be measured or trapped.  If I had the
money for some of these expensive automatic testing packages ($4,000 US and up),
I might be able to find the hot spots and the reasons for failure.  At this point
I can't trace it to a specific sequence of events, so under a stressed JVM, you
are going to see something happen wrong.  This is also true of commercial software,
which is why IT managers insist on purchasing more hardware when CPU usage is 80%
or more.
Mime
View raw message