You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by footh <fo...@yahoo.com> on 2005/10/12 18:13:13 UTC
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
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:135)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
at
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
at org.apache.cocoon.Cocoon.process(Cocoon.java:608)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:188)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
at
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
at java.lang.Thread.run(Thread.java:534)
__________________________________
Start your day with Yahoo! - Make it your home page!
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: java.lang.OutOfMemoryError after moving to production
Posted by ia...@jpmchase.com.
The property java.awt.headless is used on UNIX servers, which do not
normally have a windowing system (e.g., X11) installed, to tell the AWT not
to try to initialize the display.
HTH,
Ian
It's better to be hated for who you are
than loved for who you are not
Ian D. Stewart
Appl Dev Analyst-Advisory, DCS Automation
JPMorganChase Global Technology Infrastructure
Phone: (614) 244-2564
Pager: (888) 260-0078
footh
<fo...@yahoo.com> To: users@cocoon.apache.org
cc:
10/12/2005 05:43 Subject: Re: java.lang.OutOfMemoryError after moving to production
PM
Please respond to
users
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 <jo...@soho.club.tw> wrote:
> set this CATALINA_OPTS = -Xms256m -Xmx256m
> -Djava.awt.headless=true
>
>
> ----- Original Message -----
> From: "footh" <fo...@yahoo.com>
> To: <us...@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
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:135)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
> > at
> org.apache.cocoon.Cocoon.process(Cocoon.java:608)
> > at
> >
>
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
> > at
> >
>
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> > at
> >
>
org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:188)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> > at
> >
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
> > at
> >
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> > at
> >
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> > at
> >
>
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
> > at
> >
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
> > at
> >
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> > at
> >
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> > at
> >
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
> > at
> >
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> > at
> >
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
>
=== message truncated ===
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: java.lang.OutOfMemoryError after moving to production
Posted by footh <fo...@yahoo.com>.
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 <bp...@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 <fo...@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 <jo...@soho.club.tw> wrote:
> >
> > > set this CATALINA_OPTS = -Xms256m -Xmx256m
> > > -Djava.awt.headless=true
> > >
> > >
> > > ----- Original Message -----
> > > From: "footh" <fo...@yahoo.com>
> > > To: <us...@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
Re: java.lang.OutOfMemoryError after moving to production
Posted by Bruce Perryman <bp...@yahoo.com>.
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 <fo...@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 <jo...@soho.club.tw> wrote:
>
> > set this CATALINA_OPTS = -Xms256m -Xmx256m
> > -Djava.awt.headless=true
> >
> >
> > ----- Original Message -----
> > From: "footh" <fo...@yahoo.com>
> > To: <us...@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
> > >
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:135)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
> > > at
> > >
> >
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
> > > at
> > org.apache.cocoon.Cocoon.process(Cocoon.java:608)
> > > at
> > >
> >
>
=== message truncated ===
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: java.lang.OutOfMemoryError after moving to production
Posted by footh <fo...@yahoo.com>.
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 <jo...@soho.club.tw> wrote:
> set this CATALINA_OPTS = -Xms256m -Xmx256m
> -Djava.awt.headless=true
>
>
> ----- Original Message -----
> From: "footh" <fo...@yahoo.com>
> To: <us...@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
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:135)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
> > at
> >
>
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
> > at
> org.apache.cocoon.Cocoon.process(Cocoon.java:608)
> > at
> >
>
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
> > at
> >
>
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> > at
> >
>
org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:188)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
> > at
> >
>
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> > at
> >
>
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
> > at
> >
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> > at
> >
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> > at
> >
>
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
> > at
> >
>
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
> > at
> >
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> > at
> >
>
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> > at
> >
>
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
> > at
> >
>
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> > at
> >
>
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
>
=== message truncated ===
__________________________________
Yahoo! Music Unlimited
Access over 1 million songs. Try it free.
http://music.yahoo.com/unlimited/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: java.lang.OutOfMemoryError after moving to production
Posted by Johnson <jo...@soho.club.tw>.
set this CATALINA_OPTS = -Xms256m -Xmx256m -Djava.awt.headless=true
----- Original Message -----
From: "footh" <fo...@yahoo.com>
To: <us...@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
> org.apache.cocoon.components.treeprocessor.sitemap.CallFunctionNode.invoke(CallFunctionNode.java:135)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:46)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:130)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:138)
> at
> org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:68)
> at
> org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:92)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:234)
> at
> org.apache.cocoon.components.treeprocessor.ConcreteTreeProcessor.process(ConcreteTreeProcessor.java:176)
> at
> org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:243)
> at org.apache.cocoon.Cocoon.process(Cocoon.java:608)
> at
> org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1123)
> at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at
> org.securityfilter.filter.SecurityFilter.doFilter(SecurityFilter.java:188)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at
> org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:535)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104)
> at
> org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
> at
> org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
> at
> org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
> at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705)
> at
> org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
> at
> org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683)
> at java.lang.Thread.run(Thread.java:534)
>
>
>
>
>
>
> __________________________________
> Start your day with Yahoo! - Make it your home page!
> http://www.yahoo.com/r/hs
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org