cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From footh <fo...@yahoo.com>
Subject Re: java.lang.OutOfMemoryError after moving to production
Date Thu, 13 Oct 2005 17:03:28 GMT
Thanks for the pointers Bruce.

I actually haven't done any of that.  I've been
meaning to go through the cocoon performance tweaks
documentation but haven't found the time.

So far the site has stayed up with the memory change
but I will make it a priority to add these other
tweaks.

--- Bruce Perryman <bperryman_us@yahoo.com> wrote:

> I've had a similar problem recently.
> 
> In addition to setting -Xmx, I believe that you
> should
> edit the <store-janitor> block in cocoon.xconf,
> setting the heapsize parameter the value that you
> set
> in -Xmx.
> 
> Also (I'm sure that you already done this, but)in
> production you can help yourself a lot by making
> sure
> that XSP and sitemap reloading are turned off and
> that
> your logging levels are at the lowest necessary
> level.
> 
> 
> --- footh <footh@yahoo.com> wrote:
> 
> > I've done that, just before I posted my original
> > message...or at least the Xms and Xmx values (and
> I
> > set them to 512).  You actually can do it through
> a
> > GUI in Tomcat 5.0+ if you used the Windows
> > installer.
> > 
> > I'm not sure what the -Djava.awt.headless=true
> > parameter is, but I'll look for that in the Tomcat
> > configure tool.  I won't find out for a day  if
> this
> > works.
> > 
> > Regards,
> > 
> > JF  
> > 
> > --- Johnson <johnson@soho.club.tw> wrote:
> > 
> > > set this CATALINA_OPTS = -Xms256m -Xmx256m
> > > -Djava.awt.headless=true
> > > 
> > > 
> > > ----- Original Message ----- 
> > > From: "footh" <footh@yahoo.com>
> > > To: <users@cocoon.apache.org>
> > > Sent: Thursday, October 13, 2005 12:13 AM
> > > Subject: java.lang.OutOfMemoryError after moving
> > to
> > > production
> > > 
> > > 
> > > > After moving our cocoon site to the production
> > > > environment, we are getting an out-of-memory
> > error
> > > > after about 12-24 hours, after which, no pages
> > can
> > > be
> > > > served.  Restarting Tomcat obviously fixes the
> > > issue
> > > > temporarily.
> > > >
> > > > I've searched the mailing list and found
> people
> > > with
> > > > similar problems.  I tried running a memory
> > > profiler
> > > > locally but that did not turn up anything.  I
> am
> > > using
> > > > cocoon 2.1.7.
> > > >
> > > > Here is a list of the relevant components and
> > > > strategies I'm using in cocoon that may be the
> > > source
> > > > of the problem.  I'm hoping an expert might be
> > > able to
> > > > shed some light on where I should look (I also
> > > list
> > > > the stack trace below):
> > > >
> > > > - Using several JavaFlows and CForms for
> forms. 
> > > All
> > > > pages call a "main" flow which sends the page
> > > either
> > > > to another flow (for example, forms have a
> > > different
> > > > flow) or to an internal pipeline.
> > > >
> > > > - The internal pipeline simply aggregates
> > several
> > > more
> > > > very simple internal pipelines that start with
> a
> > > JX
> > > > generator, then runs a custom transformer,
> runs
> > an
> > > XSL
> > > > transformation, then serializes to HTML.
> > > >
> > > > - I have several configuration xml docs that
> are
> > > read
> > > > in the constructor of the relevant flow.  One,
> > for
> > > > example, causes the creation of a table of
> > objects
> > > > that represent page "actions" (code to run
> that
> > is
> > > > specific to a given page).  I used to store
> this
> > > > Hashtable as a member variable of the flow,
> but
> > > then
> > > > after the memory problem, I decided to stick
> > this
> > > and
> > > > other similar objects in the HttpContext.  I
> now
> > > make
> > > > sure the HttpContext attribute is null before
> I
> > > create
> > > > it, in case the JavaFlow constructor is called
> > > > multiple times.
> > > >
> > > > - The page "actions" are called within a
> > JavaFlow.
> > > > Depending on the page requested, the flow
> finds
> > > the
> > > > correct object and calls its "perform" method.
> 
> > > The
> > > > actions can open DB connections, work with
> other
> > > > objects, etc.
> > > >
> > > > - These page "actions" many times stick
> objects
> > > into
> > > > the flow parameter hashmap.  Sometimes it's a
> > > simple
> > > > bean, sometimes it is a DOM document.  The JX
> > page
> > > > simply performs simple logic or prints this
> > stuff
> > > out.
> > > >
> > > > - I have a Cron job set to run once an hour,
> > every
> > > > hour of the day.  The Cron job connects to
> some
> > > > external URLs, collects some data, and stores
> > the
> > > data
> > > > in a database for use by the site.
> > > >
> > > > This describes 99% of what the site does.  I
> > guess
> > > my
> > > > main concern is the garbage collection of the
> > > objects
> > > > I stick in the flow parameter map and perhaps
> > the
> > > Cron
> > > > job which I've read may have memory issues. 
> > Below
> > > is
> > > > the exact error stack trace.  Any help would
> be
> > > > greatly appreciated!  Perhaps it is as simple
> as
> > > > increasing the Tomcat memory allowance?  I
> just
> > > tried
> > > > that out and am awaiting results...
> > > >
> > > > Caused by: java.lang.OutOfMemoryError
> > > > java.lang.OutOfMemoryError
> > > > ERROR   (2005-10-11) 17:06.47:068
> > > > [sitemap.handled-errors]
> > > (/resources/methodology.html)
> > > >
> > >
> >
>
http-207.142.131.2-80-Processor20/ErrorHandlerHelper:
> > > > An internal error occured
> > > > org.apache.cocoon.ProcessingException: An
> > internal
> > > > error occured: java.lang.OutOfMemoryError
> > > > at
> > > >
> > >
> >
>
org.apache.cocoon.components.flow.java.JavaInterpreter.callFunction(JavaInterpreter.java:175)
> > > > at
> 
=== message truncated ===



	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

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


Mime
View raw message