You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2007/04/24 16:00:18 UTC
Eager loading Tapestry pages
Maybe that's a FAQ that I overlooked somehow, but a google search
wasn't helpful in solving the problem below...
I have a busy application running on Tapestry 4.0.2 / Jetty 6 / JDK
1.5. On startup the JVM would sometimes crash overwhelmed with
requests. If it survives for the first 1-2 minutes, it warms up and
runs just fine thereafter. I was able to take thread dump right
before it crashed (see below). Most request threads (there's about a
hundred per JVM) are being stuck waiting for shared resources,
somewhere down PageLoader stack.
So it would be nice to eagerly warm up Tapestry stack. I tried eager-
loading PageLoader service, but I guess this doesn't load needed
dependencies, as I got a bunch of startup errors for the following
configuration:
<contribution configuration-id="hivemind.EagerLoad">
<load service-id="tapestry.page.PageLoader" />
</contribution>
So my question is: how can I init Tapestry services eagerly from
within the ApplicationServlet.init(), before the gate is opened and
requests start to come in? I can probably hack some kind of startup
filter that throttles the first N requests, but I hope there's a
"standard" way of handling that.
Any insights are appreciated.
Thanks
Andrus
at org.mortbay.jetty.webapp.WebAppClassLoader.getResource
(WebAppClassLoader.java:221)
- waiting to lock <0x794637d0> (a
org.mortbay.jetty.webapp.WebAppClassLoader)
at org.apache.hivemind.impl.DefaultClassResolver.getResource
(DefaultClassResolver.java:50)
at org.apache.hivemind.util.LocalizedResourceFinder.resolve
(LocalizedResourceFinder.java:71)
at org.apache.hivemind.util.ClasspathResource.getLocalization
(ClasspathResource.java:57)
at
org.apache.tapestry.l10n.DefaultResourceLocalizer.findLocalization
(DefaultResourceLocalizer.java:36)
at $ResourceLocalizer_11223035a49.findLocalization
($ResourceLocalizer_11223035a49.java)
at $ResourceLocalizer_112230359be.findLocalization
($ResourceLocalizer_112230359be.java)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.findStandardTemplat
e(TemplateSourceImpl.java:333)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.findTemplate
(TemplateSourceImpl.java:245)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.getTemplate
(TemplateSourceImpl.java:188)
at $TemplateSource_112230359ce.getTemplate
($TemplateSource_112230359ce.java)
at
org.apache.tapestry.services.impl.ComponentTemplateLoaderImpl.loadTempla
te(ComponentTemplateLoaderImpl.java:55)
at $ComponentTemplateLoader_11223035a4e.loadTemplate
($ComponentTemplateLoader_11223035a4e.java)
at
org.apache.tapestry.pageload.PageLoader.loadTemplateForComponent
(PageLoader.java:648)
at org.apache.tapestry.BaseComponent.readTemplate
(BaseComponent.java:77)
at org.apache.tapestry.BaseComponent.finishLoad
(BaseComponent.java:107)
at $ContentModuleComponent_17.finishLoad
($ContentModuleComponent_17.java)
at org.apache.tapestry.pageload.PageLoader.constructComponent
(PageLoader.java:439)
at
org.apache.tapestry.pageload.PageLoader.createImplicitComponent
(PageLoader.java:494)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.constructTemplateIn
stance(TemplateSourceImpl.java:395)
- waiting to lock <0x7b3f66e8> (a
org.apache.tapestry.services.impl.TemplateSourceImpl)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.parseTemplate
(TemplateSourceImpl.java:383)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.getOrParseTemplate(
TemplateSourceImpl.java:360)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.findStandardTemplat
e(TemplateSourceImpl.java:340)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.findTemplate
(TemplateSourceImpl.java:245)
at
org.apache.tapestry.services.impl.TemplateSourceImpl.getTemplate
(TemplateSourceImpl.java:188)
at $TemplateSource_112230359ce.getTemplate
($TemplateSource_112230359ce.java)
at
org.apache.tapestry.services.impl.ComponentTemplateLoaderImpl.loadTempla
te(ComponentTemplateLoaderImpl.java:55)
at $ComponentTemplateLoader_11223035a4e.loadTemplate
($ComponentTemplateLoader_11223035a4e.java)
at
org.apache.tapestry.pageload.PageLoader.loadTemplateForComponent
(PageLoader.java:648)
at org.apache.tapestry.BaseComponent.readTemplate
(BaseComponent.java:77)
at org.apache.tapestry.BaseComponent.finishLoad
(BaseComponent.java:107)
at $ContentModuleComponent_17.finishLoad
($ContentModuleComponent_17.java)
at org.apache.tapestry.pageload.PageLoader.constructComponent
(PageLoader.java:439)
at
org.apache.tapestry.pageload.PageLoader.createImplicitComponent
(PageLoader.java:494)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Eager loading Tapestry pages
Posted by Andrus Adamchik <an...@objectstyle.org>.
Analyzing more thread dumps, I found that PageLoader is not the only
contention point, but still Tapestry service stack warmup is the
bottleneck. Any ideas?
Andrus
On Apr 24, 2007, at 5:00 PM, Andrus Adamchik wrote:
> Maybe that's a FAQ that I overlooked somehow, but a google search
> wasn't helpful in solving the problem below...
>
> I have a busy application running on Tapestry 4.0.2 / Jetty 6 / JDK
> 1.5. On startup the JVM would sometimes crash overwhelmed with
> requests. If it survives for the first 1-2 minutes, it warms up and
> runs just fine thereafter. I was able to take thread dump right
> before it crashed (see below). Most request threads (there's about
> a hundred per JVM) are being stuck waiting for shared resources,
> somewhere down PageLoader stack.
>
> So it would be nice to eagerly warm up Tapestry stack. I tried
> eager-loading PageLoader service, but I guess this doesn't load
> needed dependencies, as I got a bunch of startup errors for the
> following configuration:
>
> <contribution configuration-id="hivemind.EagerLoad">
> <load service-id="tapestry.page.PageLoader" />
> </contribution>
>
> So my question is: how can I init Tapestry services eagerly from
> within the ApplicationServlet.init(), before the gate is opened and
> requests start to come in? I can probably hack some kind of startup
> filter that throttles the first N requests, but I hope there's a
> "standard" way of handling that.
>
> Any insights are appreciated.
>
> Thanks
> Andrus
>
>
>
> at org.mortbay.jetty.webapp.WebAppClassLoader.getResource
> (WebAppClassLoader.java:221)
> - waiting to lock <0x794637d0> (a
> org.mortbay.jetty.webapp.WebAppClassLoader)
> at org.apache.hivemind.impl.DefaultClassResolver.getResource
> (DefaultClassResolver.java:50)
> at org.apache.hivemind.util.LocalizedResourceFinder.resolve
> (LocalizedResourceFinder.java:71)
> at
> org.apache.hivemind.util.ClasspathResource.getLocalization
> (ClasspathResource.java:57)
> at
> org.apache.tapestry.l10n.DefaultResourceLocalizer.findLocalization
> (DefaultResourceLocalizer.java:36)
> at $ResourceLocalizer_11223035a49.findLocalization
> ($ResourceLocalizer_11223035a49.java)
> at $ResourceLocalizer_112230359be.findLocalization
> ($ResourceLocalizer_112230359be.java)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.findStandardTempl
> ate(TemplateSourceImpl.java:333)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.findTemplate
> (TemplateSourceImpl.java:245)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.getTemplate
> (TemplateSourceImpl.java:188)
> at $TemplateSource_112230359ce.getTemplate
> ($TemplateSource_112230359ce.java)
> at
> org.apache.tapestry.services.impl.ComponentTemplateLoaderImpl.loadTemp
> late(ComponentTemplateLoaderImpl.java:55)
> at $ComponentTemplateLoader_11223035a4e.loadTemplate
> ($ComponentTemplateLoader_11223035a4e.java)
> at
> org.apache.tapestry.pageload.PageLoader.loadTemplateForComponent
> (PageLoader.java:648)
> at org.apache.tapestry.BaseComponent.readTemplate
> (BaseComponent.java:77)
> at org.apache.tapestry.BaseComponent.finishLoad
> (BaseComponent.java:107)
> at $ContentModuleComponent_17.finishLoad
> ($ContentModuleComponent_17.java)
> at
> org.apache.tapestry.pageload.PageLoader.constructComponent
> (PageLoader.java:439)
> at
> org.apache.tapestry.pageload.PageLoader.createImplicitComponent
> (PageLoader.java:494)
>
>
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.constructTemplate
> Instance(TemplateSourceImpl.java:395)
> - waiting to lock <0x7b3f66e8> (a
> org.apache.tapestry.services.impl.TemplateSourceImpl)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.parseTemplate
> (TemplateSourceImpl.java:383)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.getOrParseTemplat
> e(TemplateSourceImpl.java:360)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.findStandardTempl
> ate(TemplateSourceImpl.java:340)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.findTemplate
> (TemplateSourceImpl.java:245)
> at
> org.apache.tapestry.services.impl.TemplateSourceImpl.getTemplate
> (TemplateSourceImpl.java:188)
> at $TemplateSource_112230359ce.getTemplate
> ($TemplateSource_112230359ce.java)
> at
> org.apache.tapestry.services.impl.ComponentTemplateLoaderImpl.loadTemp
> late(ComponentTemplateLoaderImpl.java:55)
> at $ComponentTemplateLoader_11223035a4e.loadTemplate
> ($ComponentTemplateLoader_11223035a4e.java)
> at
> org.apache.tapestry.pageload.PageLoader.loadTemplateForComponent
> (PageLoader.java:648)
> at org.apache.tapestry.BaseComponent.readTemplate
> (BaseComponent.java:77)
> at org.apache.tapestry.BaseComponent.finishLoad
> (BaseComponent.java:107)
> at $ContentModuleComponent_17.finishLoad
> ($ContentModuleComponent_17.java)
> at
> org.apache.tapestry.pageload.PageLoader.constructComponent
> (PageLoader.java:439)
> at
> org.apache.tapestry.pageload.PageLoader.createImplicitComponent
> (PageLoader.java:494)
>
>
>
>
> ---------------------------------------------------------------------
> 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
Table-Tree component
Posted by Marcos Chicote <mc...@newtechnologies.com.ar>.
Hi!
I need a component with the following funtionality: it's like a table, but
it is not a table; and it's like a tree, but it's not a tree.
Actually I kwow for sure that it's not a table, but I can't say that it's
definitely not a tree.
Imagine a table (sortable and pagable) very much like the Table component,
except that I need that when a click on a table row a async request is made
to the server and information regarding that row is opened under it indented
a litle bit to the right (this is the tree-like behaviour). This information
is again a table with the same behaviour (each element is clickable and new
"nodes" are opened).
What I need is something like this:
http://sstree.tigris.org/nonav/example4.html
After all this talk here is my question: do I need to start programming a
new component or can I re-use contrib:Table component or tacos:Tree
component in some way to acomplish what I want??
Oh! I'm using Tapestry 4.1!
I hope I have made myself clear. If not, just ask ;)
Thanks!!
Marcos
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Eager loading Tapestry pages
Posted by Howard Lewis Ship <hl...@gmail.com>.
One of the issues is that until we have a request, we don't know a number of
things that Tapestry needs when constructing pages and supporting services.
This really gets in the way of doing a "warm up". In the past, I've seen
scripts that do a warm up against the server before the Apache reverse
firewall is allowed to flood the server with requests.
On 4/24/07, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Yeah....It's probably ultimately something in javassist. It creates a very
> large cache of objects when compiling things. Not that it's javassists
> fault, there are ways to help fix some of that but it's not very
> straightforward / easy to do.
>
> ...Which more or less means intelligently finding ways to make it so that
> this cache can be cleared out. I've done this for the ognl compilations
> already but the method required to do it on tapestry proper will have to
> be
> much different so it's probably going to be a 4.2 kind of thing. (or maybe
> sooner if someone wants to take a crack at it, I'll happily outline my
> ideas
> somewhere ;) )
>
> On 4/24/07, Andrus Adamchik <an...@objectstyle.org> wrote:
> >
> > Hi Jesse,
> >
> > Thanks for your reply. I'll try bumping up MaxPermSize value - this
> > is one parameter that can possibly cause the crashes I am observing
> > (Xms/Xmx are sufficiently high already).
> >
> > Although I was still hoping there is a way to warm up the stack to
> > fill in the page cache before the app starts serving requests. But
> > looks like there's none? (if I can solve the JVM crashing, this
> > becomes a secondary concern, still would've been a nice performance
> > enhancement).
> >
> > Thanks
> > Andrus
> >
> >
> > On Apr 24, 2007, at 7:01 PM, Jesse Kuhnert wrote:
> >
> > > It's hard to say for sure what the problem is without more
> > > information but
> > > you can try adding things like the below methods to help your
> > > startup times:
> > >
> > > -) Increase or add the initial heap memory size via command line -
> > > Xms224m
> > > (or whatever seems appropriate) .
> > >
> > > -) Increase your perm gen space size - this will be critical for
> > > all of the
> > > javassist compilations that happen when initially loading up pages /
> > > components. -XX:MaxPermSize=99m
> > >
> > > -) Make sure you don't have caching disabled of course. ;)
> > >
> > > Not sure what else there is. I know there are a few unnecessary
> > > synchronized() lock calls in a few places that were added to fix
> > > some issues
> > > related to dev mode problems (ie caching being disabled) - but I've
> > > been
> > > slowly removing them here and there when I notice them. Maybe I
> > > should just
> > > do one big sweep of all usages to be sure.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>
--
Howard M. Lewis Ship
TWD Consulting, Inc.
Independent J2EE / Open-Source Java Consultant
Creator and PMC Chair, Apache Tapestry
Creator, Apache HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Re: Eager loading Tapestry pages
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah....It's probably ultimately something in javassist. It creates a very
large cache of objects when compiling things. Not that it's javassists
fault, there are ways to help fix some of that but it's not very
straightforward / easy to do.
...Which more or less means intelligently finding ways to make it so that
this cache can be cleared out. I've done this for the ognl compilations
already but the method required to do it on tapestry proper will have to be
much different so it's probably going to be a 4.2 kind of thing. (or maybe
sooner if someone wants to take a crack at it, I'll happily outline my ideas
somewhere ;) )
On 4/24/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Hi Jesse,
>
> Thanks for your reply. I'll try bumping up MaxPermSize value - this
> is one parameter that can possibly cause the crashes I am observing
> (Xms/Xmx are sufficiently high already).
>
> Although I was still hoping there is a way to warm up the stack to
> fill in the page cache before the app starts serving requests. But
> looks like there's none? (if I can solve the JVM crashing, this
> becomes a secondary concern, still would've been a nice performance
> enhancement).
>
> Thanks
> Andrus
>
>
> On Apr 24, 2007, at 7:01 PM, Jesse Kuhnert wrote:
>
> > It's hard to say for sure what the problem is without more
> > information but
> > you can try adding things like the below methods to help your
> > startup times:
> >
> > -) Increase or add the initial heap memory size via command line -
> > Xms224m
> > (or whatever seems appropriate) .
> >
> > -) Increase your perm gen space size - this will be critical for
> > all of the
> > javassist compilations that happen when initially loading up pages /
> > components. -XX:MaxPermSize=99m
> >
> > -) Make sure you don't have caching disabled of course. ;)
> >
> > Not sure what else there is. I know there are a few unnecessary
> > synchronized() lock calls in a few places that were added to fix
> > some issues
> > related to dev mode problems (ie caching being disabled) - but I've
> > been
> > slowly removing them here and there when I notice them. Maybe I
> > should just
> > do one big sweep of all usages to be sure.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: Eager loading Tapestry pages
Posted by Andrus Adamchik <an...@objectstyle.org>.
Hi Jesse,
Thanks for your reply. I'll try bumping up MaxPermSize value - this
is one parameter that can possibly cause the crashes I am observing
(Xms/Xmx are sufficiently high already).
Although I was still hoping there is a way to warm up the stack to
fill in the page cache before the app starts serving requests. But
looks like there's none? (if I can solve the JVM crashing, this
becomes a secondary concern, still would've been a nice performance
enhancement).
Thanks
Andrus
On Apr 24, 2007, at 7:01 PM, Jesse Kuhnert wrote:
> It's hard to say for sure what the problem is without more
> information but
> you can try adding things like the below methods to help your
> startup times:
>
> -) Increase or add the initial heap memory size via command line -
> Xms224m
> (or whatever seems appropriate) .
>
> -) Increase your perm gen space size - this will be critical for
> all of the
> javassist compilations that happen when initially loading up pages /
> components. -XX:MaxPermSize=99m
>
> -) Make sure you don't have caching disabled of course. ;)
>
> Not sure what else there is. I know there are a few unnecessary
> synchronized() lock calls in a few places that were added to fix
> some issues
> related to dev mode problems (ie caching being disabled) - but I've
> been
> slowly removing them here and there when I notice them. Maybe I
> should just
> do one big sweep of all usages to be sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Eager loading Tapestry pages
Posted by Jesse Kuhnert <jk...@gmail.com>.
It's hard to say for sure what the problem is without more information but
you can try adding things like the below methods to help your startup times:
-) Increase or add the initial heap memory size via command line -Xms224m
(or whatever seems appropriate) .
-) Increase your perm gen space size - this will be critical for all of the
javassist compilations that happen when initially loading up pages /
components. -XX:MaxPermSize=99m
-) Make sure you don't have caching disabled of course. ;)
Not sure what else there is. I know there are a few unnecessary
synchronized() lock calls in a few places that were added to fix some issues
related to dev mode problems (ie caching being disabled) - but I've been
slowly removing them here and there when I notice them. Maybe I should just
do one big sweep of all usages to be sure.
On 4/24/07, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> Maybe that's a FAQ that I overlooked somehow, but a google search
> wasn't helpful in solving the problem below...
>
> I have a busy application running on Tapestry 4.0.2 / Jetty 6 / JDK
> 1.5. On startup the JVM would sometimes crash overwhelmed with
> requests. If it survives for the first 1-2 minutes, it warms up and
> runs just fine thereafter. I was able to take thread dump right
> before it crashed (see below). Most request threads (there's about a
> hundred per JVM) are being stuck waiting for shared resources,
> somewhere down PageLoader stack.
>
> So it would be nice to eagerly warm up Tapestry stack. I tried eager-
> loading PageLoader service, but I guess this doesn't load needed
> dependencies, as I got a bunch of startup errors for the following
> configuration:
>
> <contribution configuration-id="hivemind.EagerLoad">
> <load service-id="tapestry.page.PageLoader" />
> </contribution>
>
> So my question is: how can I init Tapestry services eagerly from
> within the ApplicationServlet.init(), before the gate is opened and
> requests start to come in? I can probably hack some kind of startup
> filter that throttles the first N requests, but I hope there's a
> "standard" way of handling that.
>
> Any insights are appreciated.
>
> Thanks
> Andrus
>
>
>
> at org.mortbay.jetty.webapp.WebAppClassLoader.getResource
> (WebAppClassLoader.java:221)
> <sniupped>
>
--
Jesse Kuhnert
Tapestry/Dojo team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com