You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dave Greggory <da...@yahoo.com> on 2009/09/11 17:47:23 UTC
[T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
Configured as:
tapestry.page-pool.active-window = 5 m
tapestry.page-pool.hard-limit = 10
Ran a JMeter Load Test with
10 concurrent users
Ramp-up time of 60 seconds
1 second between requests for a particular user
Repeated 20 times
The user will visit a signup page, submit a form, then get redirected to a billing page, submit that with CC info and be shown a thank you receipt page and will log out. During the test, memory usage went from around 400MB to 1.5GB. Did a forced GC from JConsole and it did not release more than 100MB at most. Re-ran the above test with 20 users instead with the same config (no re-starting of Tomcat) and the memory usage climbed to about 2GB (max Xmx) and eventually Tomcat stopped responding. After 30 minutes or so, it finally threw an OOM with a memory dump.
JConsole Memory Usage
http://img41.imageshack.us/img41/5303/tapestryloadtestmemoryu.jpg
HPROF Memory Dump in YourKit:
http://img38.imageshack.us/img38/431/memorydumpclasslist.png
What's going on here?
Just some info on our app. Our pages are similar to a CMS system, except that instead of static content, we serve up different components (forms, etc) for users. We use a Dispatcher and overriden LinkFactory to map seo-optimized URLs to a given Page. Many different URLs may map to the same page and the same URL may map to more than 1 page based on user's status. A given page will have multiple layouts injected into it, and each layout will have multiple components injected into it (it goes a little bit deeper than that). At runtime, a page configuration is read from the database based on the URL and user's status, and the relevant layouts and components to show are selected. Since Tapestry is limited in the way that it can only use a component that has already been injected to the page (ie. IoC can't dynamically load a component without having being referenced in the page before), each page can load a multiple different components.
I can understand if this complex scenario needed a couple of hundred megs, but 2 GB? And even more worrisome, why does it not collect during garbage collection? During the whole test of 20 minutes or so, more than 6 minutes were spent in GC.
Any ideas? Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
Thanks Thiago and Howard. Appreciate your insight, couldn't have it done it without your earlier recommendations.
I know you're working improving the documentation, so I'd recommend that you note the uber-component anti-pattern in the components section, and for people needing that kind of functionality, to use something similar to what I had to do.
----- Original Message ----
From: Howard Lewis Ship <hl...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Thursday, September 17, 2009 2:54:19 PM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
If the interface is NOT in an internal package, than its public API. Despite
my best efforts, there's a lot of that! :-)
On Thu, Sep 17, 2009 at 11:48 AM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Thu, 17 Sep 2009 15:28:36 -0300, Dave Greggory <da...@yahoo.com>
> escreveu:
>
> So nobody has still answered my question whether ComponentSource is an
>> acceptable way to retrieve a component instance you need? The interface is
>> not internal, so I'd assume so, but the implementation is, and is it
>> reasonable to expect that future implementations would continue to provide
>> cached, non-new components when called?
>>
>
> ComponentSource is exactly what BeanEditForm* uses, so it's ok. :)
>
> * BeanEditForm uses BeanBlockSource that uses BeanBlockOverrideSource that
> uses CompontentSource that uses RequestPageCache.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Howard Lewis Ship <hl...@gmail.com>.
If the interface is NOT in an internal package, than its public API. Despite
my best efforts, there's a lot of that! :-)
On Thu, Sep 17, 2009 at 11:48 AM, Thiago H. de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> Em Thu, 17 Sep 2009 15:28:36 -0300, Dave Greggory <da...@yahoo.com>
> escreveu:
>
> So nobody has still answered my question whether ComponentSource is an
>> acceptable way to retrieve a component instance you need? The interface is
>> not internal, so I'd assume so, but the implementation is, and is it
>> reasonable to expect that future implementations would continue to provide
>> cached, non-new components when called?
>>
>
> ComponentSource is exactly what BeanEditForm* uses, so it's ok. :)
>
> * BeanEditForm uses BeanBlockSource that uses BeanBlockOverrideSource that
> uses CompontentSource that uses RequestPageCache.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Thu, 17 Sep 2009 15:28:36 -0300, Dave Greggory <da...@yahoo.com>
escreveu:
> So nobody has still answered my question whether ComponentSource is an
> acceptable way to retrieve a component instance you need? The interface
> is not internal, so I'd assume so, but the implementation is, and is it
> reasonable to expect that future implementations would continue to
> provide cached, non-new components when called?
ComponentSource is exactly what BeanEditForm* uses, so it's ok. :)
* BeanEditForm uses BeanBlockSource that uses BeanBlockOverrideSource that
uses CompontentSource that uses RequestPageCache.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
Thanks for the response, Stefan. A simple BeanEditForm unfortunately won't suffice for me as indicated in my previous posts, I'm doing something a little more tricky. But thanks anyhow.
Using a ComponentSource to retrieve the components I need seems to be solving the problem. I re-ran the same load test mentioned in my first post after making the code changes (same config) and I got some good results.
JConsole Memory usage:
http://img5.imageshack.us/img5/5303/tapestryloadtestmemoryu.jpg
Memory Dump in YourKit:
http://img16.imageshack.us/img16/1663/memorydumpclasslistfixe.png
54K ComponentPageElement instances using 200MB seem to be so much better than 392K ComponentPageElement instances using 1.5GB. With a hard limit of 10 and 8 pages, that's still 675 component page elements / page though. Does that seem reasonable? (Helluva lot better than before, for sure). I only fixed this for the 2 pages that were used in the load test, if Tapestry loads all page and component combinations on first access then this may further improve when I fix the rest.
So nobody has still answered my question whether ComponentSource is an acceptable way to retrieve a component instance you need? The interface is not internal, so I'd assume so, but the implementation is, and is it reasonable to expect that future implementations would continue to provide cached, non-new components when called?
Thanks.
----- Original Message ----
From: Stefan <st...@wammel.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Thursday, September 17, 2009 2:58:09 AM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
I've tried it with a ComponentWrapper (or loader) too, but don't got it to work this way.
Now i use a simple BeanEditForm with an own simple BeanModel.
I pass a property with my custom datatype into the beanmodel and it does the rest.
Define and register your custom components with their corresponding datatypes as described here:
http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlock
and try it with the propertyEditor or a beanEditor.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Stefan <st...@wammel.com>.
I've tried it with a ComponentWrapper (or loader) too, but don't got
it to work this way.
Now i use a simple BeanEditForm with an own simple BeanModel.
I pass a property with my custom datatype into the beanmodel and it
does the rest.
Define and register your custom components with their corresponding
datatypes as described here:
http://wiki.apache.org/tapestry/Tapestry5HowToCreateAPropertyEditBlock
and try it with the propertyEditor or a beanEditor.
Am 16.09.2009 um 21:46 schrieb Dave Greggory:
> Instead of using BeanBlockSource (as used by PropertyEditor), would
> I be able to use ComponentSource instead (passing in complete id to
> it)? I need the actual Component instead of the Block containing it.
> Since ComponentSource uses the RequestPageCache, I assume I will not
> end up creating a large number of ComponentPageElements with it. Is
> that an accurate?
>
>
>
> ----- Original Message ----
> From: Dave Greggory <da...@yahoo.com>
> To: Tapestry users <us...@tapestry.apache.org>
> Sent: Monday, September 14, 2009 6:44:27 PM
> Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't
> reduce after forced GC)
>
> I created a ComponentLoader component (below) based off of
> PropertyEditor component and I got it working for the top most of
> layer of my ubercomponent-stack. It uses PropertyEditBlock page and
> the existing BeanBlockSource to provide the right Block containing
> my layouts / components. Does it look right to you?
>
> Also, if I understand this correctly, the page that uses this
> ComponentLoader will not load all the other components mentioned in
> the PropertyEditBlocks page, just the ones refered to using the
> calling page, right?
>
> public class ComponentLoader
> {
> @Parameter(required = true)
> private String componentType;
>
> @Inject
> private BeanBlockSource beanBlockSource;
>
> @BeginRender
> Block selectComponent()
> {
> return beanBlockSource.getEditBlock(componentType);
> }
>
> @BeforeRenderBody
> boolean noBodyForComponentLoader()
> {
> return false;
> }
> }
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
Instead of using BeanBlockSource (as used by PropertyEditor), would I be able to use ComponentSource instead (passing in complete id to it)? I need the actual Component instead of the Block containing it. Since ComponentSource uses the RequestPageCache, I assume I will not end up creating a large number of ComponentPageElements with it. Is that an accurate?
----- Original Message ----
From: Dave Greggory <da...@yahoo.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Monday, September 14, 2009 6:44:27 PM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
I created a ComponentLoader component (below) based off of PropertyEditor component and I got it working for the top most of layer of my ubercomponent-stack. It uses PropertyEditBlock page and the existing BeanBlockSource to provide the right Block containing my layouts / components. Does it look right to you?
Also, if I understand this correctly, the page that uses this ComponentLoader will not load all the other components mentioned in the PropertyEditBlocks page, just the ones refered to using the calling page, right?
public class ComponentLoader
{
@Parameter(required = true)
private String componentType;
@Inject
private BeanBlockSource beanBlockSource;
@BeginRender
Block selectComponent()
{
return beanBlockSource.getEditBlock(componentType);
}
@BeforeRenderBody
boolean noBodyForComponentLoader()
{
return false;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
I created a ComponentLoader component (below) based off of PropertyEditor component and I got it working for the top most of layer of my ubercomponent-stack. It uses PropertyEditBlock page and the existing BeanBlockSource to provide the right Block containing my layouts / components. Does it look right to you?
Also, if I understand this correctly, the page that uses this ComponentLoader will not load all the other components mentioned in the PropertyEditBlocks page, just the ones refered to using the calling page, right?
public class ComponentLoader
{
@Parameter(required = true)
private String componentType;
@Inject
private BeanBlockSource beanBlockSource;
@BeginRender
Block selectComponent()
{
return beanBlockSource.getEditBlock(componentType);
}
@BeforeRenderBody
boolean noBodyForComponentLoader()
{
return false;
}
}
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
Yes, we're using a the Uber-component pattern as you put it. As that is the only way, we can build a dynamically defined Page.
Right now, we have about 8 pages, containing possibly 12 Layout components, and 29 functional components, some of which a Form Components. And those contain 4 possible Form Layouts and 13 possible Form Sub Components. A database based configuration defines what components and layouts are active or shown on each page. We have separate CMS like management system to update / edit this page configuration.
Is there a different way we can accomplish the same thing? We need to maintain the flexibility to dynamically determine where in the page a component is added to or shown at all.
I don't quite understand what you mean by how the BeanEditForm component works. Perhaps someone can kindly explain it to me. Thanks so much.
----- Original Message ----
From: Howard Lewis Ship <hl...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Friday, September 11, 2009 2:36:00 PM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Tapestry 5.1.0.5 is more efficient, but that's mostly in terms of reducing
the number of temporary objects created during a single request.
392,000 instances of ComponentPageElementImpl?
How many pages in your application? Say there's 15 distinct pages.
392,000 / (15 district * 10 hard limit) = 2600 components per page
In fact, looking at the memory, there's 25 PageImpls, so now we're talking
15,680 components / page! That seems like a lot!
I'm concerned you've fallen prey to the Uber-component anti-pattern.
If you have a component that contains, in its template, 10 other components
then every time you use such a component, that's 10 instances of
ComponentPageElementImpl.
I've seen systems that, for every field to be edited, an Uber-component is
used, and the Uber-component is set up to edit any type of data, so it has a
TextField, a Select, a Checkbox ... and a Grid containing a bunch of other
stuff ... and so on. Thus editing the userId field of the User object
claims several hundred components (instances of ComponentPageElementImpl).
If you notice how BeanEditForm / BeanEditor / PropertyEditor works, the
actual editing components live on a secondary page. An instance of
PropertyEditor is just the one ComponentPageElementImpl instance, plus
shared "off screen" components from the PropertyEditBlocks page (part of
Tapestry's core library).
If you have ten PropertyEditor components on a page, that's 10
ComponentPageElementImpl instances, not hundreds or thousands, even though
there are dozens of components on the PropertyEditBlocksPage.
Anyway, perhaps this is what you've done, or perhaps there's some other
issue ... some cache or pool (outside of Tapestry) that is holding onto page
instances even after Tapestry has discarded them. Or perhaps the memory
issue is not related to Tapestry after all (though that 392,000 instances
seems troublesome).
On Fri, Sep 11, 2009 at 8:47 AM, Dave Greggory <da...@yahoo.com>wrote:
> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m
> -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
>
> Configured as:
> tapestry.page-pool.active-window = 5 m
> tapestry.page-pool.hard-limit = 10
>
> Ran a JMeter Load Test with
> 10 concurrent users
> Ramp-up time of 60 seconds
> 1 second between requests for a particular user
> Repeated 20 times
>
> The user will visit a signup page, submit a form, then get redirected to a
> billing page, submit that with CC info and be shown a thank you receipt page
> and will log out. During the test, memory usage went from around 400MB to
> 1.5GB. Did a forced GC from JConsole and it did not release more than 100MB
> at most. Re-ran the above test with 20 users instead with the same config
> (no re-starting of Tomcat) and the memory usage climbed to about 2GB (max
> Xmx) and eventually Tomcat stopped responding. After 30 minutes or so, it
> finally threw an OOM with a memory dump.
>
> JConsole Memory Usage
> http://img41.imageshack.us/img41/5303/tapestryloadtestmemoryu.jpg
>
> HPROF Memory Dump in YourKit:
> http://img38.imageshack.us/img38/431/memorydumpclasslist.png
>
> What's going on here?
>
> Just some info on our app. Our pages are similar to a CMS system, except
> that instead of static content, we serve up different components (forms,
> etc) for users. We use a Dispatcher and overriden LinkFactory to map
> seo-optimized URLs to a given Page. Many different URLs may map to the same
> page and the same URL may map to more than 1 page based on user's status. A
> given page will have multiple layouts injected into it, and each layout will
> have multiple components injected into it (it goes a little bit deeper than
> that). At runtime, a page configuration is read from the database based on
> the URL and user's status, and the relevant layouts and components to show
> are selected. Since Tapestry is limited in the way that it can only use a
> component that has already been injected to the page (ie. IoC can't
> dynamically load a component without having being referenced in the page
> before), each page can load a multiple different components.
>
> I can understand if this complex scenario needed a couple of hundred megs,
> but 2 GB? And even more worrisome, why does it not collect during garbage
> collection? During the whole test of 20 minutes or so, more than 6 minutes
> were spent in GC.
>
> Any ideas? Thoughts?
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Howard Lewis Ship <hl...@gmail.com>.
Tapestry 5.1.0.5 is more efficient, but that's mostly in terms of reducing
the number of temporary objects created during a single request.
392,000 instances of ComponentPageElementImpl?
How many pages in your application? Say there's 15 distinct pages.
392,000 / (15 district * 10 hard limit) = 2600 components per page
In fact, looking at the memory, there's 25 PageImpls, so now we're talking
15,680 components / page! That seems like a lot!
I'm concerned you've fallen prey to the Uber-component anti-pattern.
If you have a component that contains, in its template, 10 other components
then every time you use such a component, that's 10 instances of
ComponentPageElementImpl.
I've seen systems that, for every field to be edited, an Uber-component is
used, and the Uber-component is set up to edit any type of data, so it has a
TextField, a Select, a Checkbox ... and a Grid containing a bunch of other
stuff ... and so on. Thus editing the userId field of the User object
claims several hundred components (instances of ComponentPageElementImpl).
If you notice how BeanEditForm / BeanEditor / PropertyEditor works, the
actual editing components live on a secondary page. An instance of
PropertyEditor is just the one ComponentPageElementImpl instance, plus
shared "off screen" components from the PropertyEditBlocks page (part of
Tapestry's core library).
If you have ten PropertyEditor components on a page, that's 10
ComponentPageElementImpl instances, not hundreds or thousands, even though
there are dozens of components on the PropertyEditBlocksPage.
Anyway, perhaps this is what you've done, or perhaps there's some other
issue ... some cache or pool (outside of Tapestry) that is holding onto page
instances even after Tapestry has discarded them. Or perhaps the memory
issue is not related to Tapestry after all (though that 392,000 instances
seems troublesome).
On Fri, Sep 11, 2009 at 8:47 AM, Dave Greggory <da...@yahoo.com>wrote:
> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m
> -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
>
> Configured as:
> tapestry.page-pool.active-window = 5 m
> tapestry.page-pool.hard-limit = 10
>
> Ran a JMeter Load Test with
> 10 concurrent users
> Ramp-up time of 60 seconds
> 1 second between requests for a particular user
> Repeated 20 times
>
> The user will visit a signup page, submit a form, then get redirected to a
> billing page, submit that with CC info and be shown a thank you receipt page
> and will log out. During the test, memory usage went from around 400MB to
> 1.5GB. Did a forced GC from JConsole and it did not release more than 100MB
> at most. Re-ran the above test with 20 users instead with the same config
> (no re-starting of Tomcat) and the memory usage climbed to about 2GB (max
> Xmx) and eventually Tomcat stopped responding. After 30 minutes or so, it
> finally threw an OOM with a memory dump.
>
> JConsole Memory Usage
> http://img41.imageshack.us/img41/5303/tapestryloadtestmemoryu.jpg
>
> HPROF Memory Dump in YourKit:
> http://img38.imageshack.us/img38/431/memorydumpclasslist.png
>
> What's going on here?
>
> Just some info on our app. Our pages are similar to a CMS system, except
> that instead of static content, we serve up different components (forms,
> etc) for users. We use a Dispatcher and overriden LinkFactory to map
> seo-optimized URLs to a given Page. Many different URLs may map to the same
> page and the same URL may map to more than 1 page based on user's status. A
> given page will have multiple layouts injected into it, and each layout will
> have multiple components injected into it (it goes a little bit deeper than
> that). At runtime, a page configuration is read from the database based on
> the URL and user's status, and the relevant layouts and components to show
> are selected. Since Tapestry is limited in the way that it can only use a
> component that has already been injected to the page (ie. IoC can't
> dynamically load a component without having being referenced in the page
> before), each page can load a multiple different components.
>
> I can understand if this complex scenario needed a couple of hundred megs,
> but 2 GB? And even more worrisome, why does it not collect during garbage
> collection? During the whole test of 20 minutes or so, more than 6 minutes
> were spent in GC.
>
> Any ideas? Thoughts?
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Kalle Korhonen <ka...@gmail.com>.
I applaud the efforts, but I think you really really have to upgrade
to 5.1.0.5 before you can get this on anybody's radar. There's a good
possibility the same wouldn't happen in it. If you are running with
-server (think it may be automatically chosen if you haven't specified
with that heap max) and the application is sufficiently busy, the gc
wouldn't kick in until heap space is exhausted. Have you checked that
you are closing db connections/returning them to to the pool properly?
In any case obviously this is not right, you shouldn't need to accept
memory usage of 2GB with that load. I've been able to run small
db-backed Tapestry apps with a memory budget of less than 200MB.
Kalle
On Fri, Sep 11, 2009 at 8:47 AM, Dave Greggory <da...@yahoo.com> wrote:
> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
>
> Configured as:
> tapestry.page-pool.active-window = 5 m
> tapestry.page-pool.hard-limit = 10
>
> Ran a JMeter Load Test with
> 10 concurrent users
> Ramp-up time of 60 seconds
> 1 second between requests for a particular user
> Repeated 20 times
>
> The user will visit a signup page, submit a form, then get redirected to a billing page, submit that with CC info and be shown a thank you receipt page and will log out. During the test, memory usage went from around 400MB to 1.5GB. Did a forced GC from JConsole and it did not release more than 100MB at most. Re-ran the above test with 20 users instead with the same config (no re-starting of Tomcat) and the memory usage climbed to about 2GB (max Xmx) and eventually Tomcat stopped responding. After 30 minutes or so, it finally threw an OOM with a memory dump.
>
> JConsole Memory Usage
> http://img41.imageshack.us/img41/5303/tapestryloadtestmemoryu.jpg
>
> HPROF Memory Dump in YourKit:
> http://img38.imageshack.us/img38/431/memorydumpclasslist.png
>
> What's going on here?
>
> Just some info on our app. Our pages are similar to a CMS system, except that instead of static content, we serve up different components (forms, etc) for users. We use a Dispatcher and overriden LinkFactory to map seo-optimized URLs to a given Page. Many different URLs may map to the same page and the same URL may map to more than 1 page based on user's status. A given page will have multiple layouts injected into it, and each layout will have multiple components injected into it (it goes a little bit deeper than that). At runtime, a page configuration is read from the database based on the URL and user's status, and the relevant layouts and components to show are selected. Since Tapestry is limited in the way that it can only use a component that has already been injected to the page (ie. IoC can't dynamically load a component without having being referenced in the page before), each page can load a multiple different components.
>
> I can understand if this complex scenario needed a couple of hundred megs, but 2 GB? And even more worrisome, why does it not collect during garbage collection? During the whole test of 20 minutes or so, more than 6 minutes were spent in GC.
>
> Any ideas? Thoughts?
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 14 Sep 2009 10:49:15 -0300, Stefan <st...@wammel.com> escreveu:
> I think the best, or most common and stable solution would be to extend
> the always existing infrastructure to be able to register own
> datatypes and their view/edit components.
> But is that possible? And how?
Yes. Take a look at DataTypeAnalyzer and
http://tapestry.apache.org/tapestry5.1/guide/beaneditform.html, section
Adding New Property Editors.
> All involved sources (PropertyEditor, BeanBlockSource etc) are internal
They aren't internal.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Stefan <st...@wammel.com>.
I'm working on the same problem. (as i mentioned in some posts before)
I think the best, or most common and stable solution would be to extend
the always existing infrastructure to be able to register own
datatypes and their view/edit components.
But is that possible? And how? All involved sources (PropertyEditor,
BeanBlockSource etc) are internal
and i don't know where to "hook" in.
Am 14.09.2009 um 14:25 schrieb Jack Nuzbit:
> I mean too much component nesting like what's been described in this
> thread.
>
>
> On Mon, Sep 14, 2009 at 12:56 PM, Ivano Luberti
> <lu...@archicoop.it>wrote:
>
>> Jack, what "Uber component pattern" stands for ?
>>
>> Jack Nuzbit ha scritto:
>>> I'm concerned I may be falling foul of the Uber-component pattern as
>> well.
>>> I'm regularly building container components that dynamically render
>>> different sub-components.
>>> Is there any chance somebody could document the recommended approach
>> here.
>>>
>>> Many thanks,
>>>
>>> Jack
>>>
>>>
>>> On Fri, Sep 11, 2009 at 8:23 PM, Dave Greggory <davegreggory@yahoo.com
>>> wrote:
>>>
>>>
>>>> NYC.
>>>>
>>>>
>>>>
>>>> ----- Original Message ----
>>>> From: Howard Lewis Ship <hl...@gmail.com>
>>>> To: Tapestry users <us...@tapestry.apache.org>
>>>> Sent: Friday, September 11, 2009 3:11:57 PM
>>>> Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak
>>>> (doesn't
>> reduce
>>>> after forced GC)
>>>>
>>>> Although upgrading is a good idea for many reasons, I don't think
>>>> it
>> will
>>>> solve your problem. You need a little re-architecting of your
>>>> approach
>> to
>>>> get the component instance count back under control. Where are you
>> located?
>>>> On Fri, Sep 11, 2009 at 12:03 PM, Dave Greggory <davegreggory@yahoo.com
>>>>
>>>>> wrote:
>>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> ==================================================
>> dott. Ivano Mario Luberti
>> Archimede Informatica societa' cooperativa a r. l.
>> Sede Operativa
>> Via Gereschi 36 - 56126- Pisa
>> tel.: +39-050- 580959
>> tel/fax: +39-050-9711344
>> web: www.archicoop.it
>> ==================================================
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Jack Nuzbit <fn...@googlemail.com>.
I mean too much component nesting like what's been described in this thread.
On Mon, Sep 14, 2009 at 12:56 PM, Ivano Luberti <lu...@archicoop.it>wrote:
> Jack, what "Uber component pattern" stands for ?
>
> Jack Nuzbit ha scritto:
> > I'm concerned I may be falling foul of the Uber-component pattern as
> well.
> > I'm regularly building container components that dynamically render
> > different sub-components.
> > Is there any chance somebody could document the recommended approach
> here.
> >
> > Many thanks,
> >
> > Jack
> >
> >
> > On Fri, Sep 11, 2009 at 8:23 PM, Dave Greggory <davegreggory@yahoo.com
> >wrote:
> >
> >
> >> NYC.
> >>
> >>
> >>
> >> ----- Original Message ----
> >> From: Howard Lewis Ship <hl...@gmail.com>
> >> To: Tapestry users <us...@tapestry.apache.org>
> >> Sent: Friday, September 11, 2009 3:11:57 PM
> >> Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't
> reduce
> >> after forced GC)
> >>
> >> Although upgrading is a good idea for many reasons, I don't think it
> will
> >> solve your problem. You need a little re-architecting of your approach
> to
> >> get the component instance count back under control. Where are you
> located?
> >> On Fri, Sep 11, 2009 at 12:03 PM, Dave Greggory <davegreggory@yahoo.com
> >>
> >>> wrote:
> >>>
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: users-help@tapestry.apache.org
> >>
> >>
> >>
> >
> >
>
> --
> ==================================================
> dott. Ivano Mario Luberti
> Archimede Informatica societa' cooperativa a r. l.
> Sede Operativa
> Via Gereschi 36 - 56126- Pisa
> tel.: +39-050- 580959
> tel/fax: +39-050-9711344
> web: www.archicoop.it
> ==================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Ivano Luberti <lu...@archicoop.it>.
Jack, what "Uber component pattern" stands for ?
Jack Nuzbit ha scritto:
> I'm concerned I may be falling foul of the Uber-component pattern as well.
> I'm regularly building container components that dynamically render
> different sub-components.
> Is there any chance somebody could document the recommended approach here.
>
> Many thanks,
>
> Jack
>
>
> On Fri, Sep 11, 2009 at 8:23 PM, Dave Greggory <da...@yahoo.com>wrote:
>
>
>> NYC.
>>
>>
>>
>> ----- Original Message ----
>> From: Howard Lewis Ship <hl...@gmail.com>
>> To: Tapestry users <us...@tapestry.apache.org>
>> Sent: Friday, September 11, 2009 3:11:57 PM
>> Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
>> after forced GC)
>>
>> Although upgrading is a good idea for many reasons, I don't think it will
>> solve your problem. You need a little re-architecting of your approach to
>> get the component instance count back under control. Where are you located?
>> On Fri, Sep 11, 2009 at 12:03 PM, Dave Greggory <davegreggory@yahoo.com
>>
>>> wrote:
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>
>
--
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Jack Nuzbit <fn...@googlemail.com>.
I'm concerned I may be falling foul of the Uber-component pattern as well.
I'm regularly building container components that dynamically render
different sub-components.
Is there any chance somebody could document the recommended approach here.
Many thanks,
Jack
On Fri, Sep 11, 2009 at 8:23 PM, Dave Greggory <da...@yahoo.com>wrote:
> NYC.
>
>
>
> ----- Original Message ----
> From: Howard Lewis Ship <hl...@gmail.com>
> To: Tapestry users <us...@tapestry.apache.org>
> Sent: Friday, September 11, 2009 3:11:57 PM
> Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
> after forced GC)
>
> Although upgrading is a good idea for many reasons, I don't think it will
> solve your problem. You need a little re-architecting of your approach to
> get the component instance count back under control. Where are you located?
> On Fri, Sep 11, 2009 at 12:03 PM, Dave Greggory <davegreggory@yahoo.com
> >wrote:
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
NYC.
----- Original Message ----
From: Howard Lewis Ship <hl...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Friday, September 11, 2009 3:11:57 PM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Although upgrading is a good idea for many reasons, I don't think it will
solve your problem. You need a little re-architecting of your approach to
get the component instance count back under control. Where are you located?
On Fri, Sep 11, 2009 at 12:03 PM, Dave Greggory <da...@yahoo.com>wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by Howard Lewis Ship <hl...@gmail.com>.
Although upgrading is a good idea for many reasons, I don't think it will
solve your problem. You need a little re-architecting of your approach to
get the component instance count back under control. Where are you located?
On Fri, Sep 11, 2009 at 12:03 PM, Dave Greggory <da...@yahoo.com>wrote:
> Upgrading to 5.1 is going to require a lot of effort since we have hacked
> LinkFactory, RequestSecurityManager, etc to get functionality that did not
> exist. But we'll certainly do it if it will solve the problem. It's just
> that we don't know whether we can allocate the resources to do it unless we
> know whether that's a potential solution to the problem.
>
>
>
> ----- Original Message ----
> From: Thiago H. de Paula Figueiredo <th...@gmail.com>
> To: Tapestry users <us...@tapestry.apache.org>
> Sent: Friday, September 11, 2009 12:17:38 PM
> Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
> after forced GC)
>
> Em Fri, 11 Sep 2009 12:47:23 -0300, Dave Greggory <da...@yahoo.com>
> escreveu:
>
> > I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m
> -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
>
> Have you tried 5.1.0.5?
>
> --Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to learn
how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Posted by Dave Greggory <da...@yahoo.com>.
Upgrading to 5.1 is going to require a lot of effort since we have hacked LinkFactory, RequestSecurityManager, etc to get functionality that did not exist. But we'll certainly do it if it will solve the problem. It's just that we don't know whether we can allocate the resources to do it unless we know whether that's a potential solution to the problem.
----- Original Message ----
From: Thiago H. de Paula Figueiredo <th...@gmail.com>
To: Tapestry users <us...@tapestry.apache.org>
Sent: Friday, September 11, 2009 12:17:38 PM
Subject: Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Em Fri, 11 Sep 2009 12:47:23 -0300, Dave Greggory <da...@yahoo.com> escreveu:
> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
Have you tried 5.1.0.5?
--Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce
after forced GC)
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Fri, 11 Sep 2009 12:47:23 -0300, Dave Greggory <da...@yahoo.com>
escreveu:
> I have T5.0.18 running in Tomcat 5.5 with Java 1.5 32-bit -Xms2048m
> -Xmx2048m -XX:PermSize=128m -XX:MaxPermSize=128m.
Have you tried 5.1.0.5?
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org