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.
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 davegregg...@yahoo.com
To: Tapestry users users@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
smime.p7s
Description: S/MIME cryptographic signature
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 ste...@wammel.com To: Tapestry users users@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Em Thu, 17 Sep 2009 15:28:36 -0300, Dave Greggory davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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 thiag...@gmail.com wrote: Em Thu, 17 Sep 2009 15:28:36 -0300, Dave Greggory davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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)
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 hls...@gmail.com To: Tapestry users users@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 thiag...@gmail.com wrote: Em Thu, 17 Sep 2009 15:28:36 -0300, Dave Greggory davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 davegregg...@yahoo.com
To: Tapestry users users@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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 davegregg...@yahoo.comwrote: NYC. - Original Message From: Howard Lewis Ship hls...@gmail.com To: Tapestry users users@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 davegregg...@yahoo.com wrote: - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 davegregg...@yahoo.comwrote: NYC. - Original Message From: Howard Lewis Ship hls...@gmail.com To: Tapestry users users@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 davegregg...@yahoo.com wrote: - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 lube...@archicoop.itwrote: 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 davegregg...@yahoo.com wrote: NYC. - Original Message From: Howard Lewis Ship hls...@gmail.com To: Tapestry users users@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 davegregg...@yahoo.com wrote: - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 lube...@archicoop.itwrote: 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 davegregg...@yahoo.com wrote: NYC. - Original Message From: Howard Lewis Ship hls...@gmail.com To: Tapestry users users@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 davegregg...@yahoo.com wrote: - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org smime.p7s Description: S/MIME cryptographic signature
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
Em Mon, 14 Sep 2009 10:49:15 -0300, Stefan ste...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
[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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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 davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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 davegregg...@yahoo.comwrote: 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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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)
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 hls...@gmail.com To: Tapestry users users@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 davegregg...@yahoo.comwrote: 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
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
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 thiag...@gmail.com To: Tapestry users users@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 davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: [T5.0.18] Out of Memory Error / Potential Leak (doesn't reduce after forced GC)
NYC. - Original Message From: Howard Lewis Ship hls...@gmail.com To: Tapestry users users@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 davegregg...@yahoo.comwrote: - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
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 davegregg...@yahoo.comwrote: 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 thiag...@gmail.com To: Tapestry users users@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 davegregg...@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-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@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
