You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Alex Kotchnev <ak...@gmail.com> on 2014/11/04 20:55:54 UTC
"Parallel" component rendering
I've been poking around Lift for the last few months and one of the
interesting approaches it has is that it can mark "snippets" (roughly the
equivalent of tapestry compoents) as "parallel" - what Lift does w/
snippets that are marked in parallel is that it fires up new threads for
rendering those snippets and waits for all of them to complete before
rendering the page / final output.
Seems like a cool idea - knowing that Tapestry stores its state in
ThreadLocal variables it seems that doing something similar wouldn't be
trivial. Would something similar be possible - e.g. maybe the "child"
threads can inherit the ThreadLocals of the thread that started them ?
Anyway, it's just a curiosity question :-) After spending a considerable
time learning and reading about Lift ( I liked some of the non-traditional
approaches that it takes to building web apps ) , my final conclusion was
that Tapestry's component focused approach was superior ( I was quite
surprised that despite being "view centric" Lift didn't have a way of
coupling the snippet template and the snippet code into a cohesive
component).
Cheers - Alex K
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
Updating this thread for future googlability. See this example for
executing work in parallel whilst rendering
http://t5stitch-lazan.rhcloud.com/paralleldemo
Re: "Parallel" component rendering
Posted by Kalle Korhonen <ka...@gmail.com>.
On Tue, Nov 4, 2014 at 1:51 PM, Alex Kotchnev <ak...@gmail.com> wrote:
> Lance - I'm not saying that doing this would work out of the box or that it
> would be trivial , I understand that Tapestry as a framework has made
> choices that might make this difficult or impossible. Yet, it's a cool
> idea, in a way that a framework should be able to support its users (e.g.
> "ah, you want these rendered in parallel, fine, let me do this for you"
> kind of way). It seems like something that can be doable in Tapestry as
> well, I'm just not entirely sure how . It certainly seems possible to
> launch the "child threads" and have them have access to the parent thread's
> ThreadLocals.
>
I want to encourage and be supportive of new ideas but I don't see the
objective in this case. It certainly cannot be for performance. Even if you
could realize some performance benefits by rendering "snippets" in
parallel, you'd lose it all while waiting for them to complete. Spawning
multiple threads just for rendering a response for a single request is
expensive and the thread resources are limited on the server. Perhaps you
should try identifying and articulating the problem as you see it and then
ask what would be the Tapestry-way of solving it?
Kalle
>
> Cheers -
>
> On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <la...@googlemail.com>
> wrote:
>
> > I'd say this is not a great idea. Tapestry assumes that rendering is all
> on
> > the same thread. The request and response (and other thread scoped
> > services) will be null on a non-request thread for instance. Also each
> > thread will have a separate hibernate session if using tapestry-hibernate
> > which will need to be cleaned up and won't share a level1 cache.
> > On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
> >
> > > I've been poking around Lift for the last few months and one of the
> > > interesting approaches it has is that it can mark "snippets" (roughly
> the
> > > equivalent of tapestry compoents) as "parallel" - what Lift does w/
> > > snippets that are marked in parallel is that it fires up new threads
> for
> > > rendering those snippets and waits for all of them to complete before
> > > rendering the page / final output.
> > >
> > > Seems like a cool idea - knowing that Tapestry stores its state in
> > > ThreadLocal variables it seems that doing something similar wouldn't be
> > > trivial. Would something similar be possible - e.g. maybe the "child"
> > > threads can inherit the ThreadLocals of the thread that started them ?
> > >
> > > Anyway, it's just a curiosity question :-) After spending a
> considerable
> > > time learning and reading about Lift ( I liked some of the
> > non-traditional
> > > approaches that it takes to building web apps ) , my final conclusion
> was
> > > that Tapestry's component focused approach was superior ( I was quite
> > > surprised that despite being "view centric" Lift didn't have a way of
> > > coupling the snippet template and the snippet code into a cohesive
> > > component).
> > >
> > > Cheers - Alex K
> > >
> >
>
Re: "Parallel" component rendering
Posted by Charlouze <me...@charlouze.com>.
Hello Alex,
I can't see what would be better with parallel component rendering. As far
as I know, parallelizing things improve performance. In the context of a
web application performance is really needed when there are multiple
clients sending requests at the same time. As each request has its own
thread, parallelizing can be considered as already in motion.
IMHO, if you need to speed up things for a single request rendering, you
may have more problems when thousands of people will hit your website at
the same time.
Cheers,
Charles
2014-11-04 22:51 GMT+01:00 Alex Kotchnev <ak...@gmail.com>:
> Lance - I'm not saying that doing this would work out of the box or that it
> would be trivial , I understand that Tapestry as a framework has made
> choices that might make this difficult or impossible. Yet, it's a cool
> idea, in a way that a framework should be able to support its users (e.g.
> "ah, you want these rendered in parallel, fine, let me do this for you"
> kind of way). It seems like something that can be doable in Tapestry as
> well, I'm just not entirely sure how . It certainly seems possible to
> launch the "child threads" and have them have access to the parent thread's
> ThreadLocals.
>
> Cheers -
>
> On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <la...@googlemail.com>
> wrote:
>
> > I'd say this is not a great idea. Tapestry assumes that rendering is all
> on
> > the same thread. The request and response (and other thread scoped
> > services) will be null on a non-request thread for instance. Also each
> > thread will have a separate hibernate session if using tapestry-hibernate
> > which will need to be cleaned up and won't share a level1 cache.
> > On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
> >
> > > I've been poking around Lift for the last few months and one of the
> > > interesting approaches it has is that it can mark "snippets" (roughly
> the
> > > equivalent of tapestry compoents) as "parallel" - what Lift does w/
> > > snippets that are marked in parallel is that it fires up new threads
> for
> > > rendering those snippets and waits for all of them to complete before
> > > rendering the page / final output.
> > >
> > > Seems like a cool idea - knowing that Tapestry stores its state in
> > > ThreadLocal variables it seems that doing something similar wouldn't be
> > > trivial. Would something similar be possible - e.g. maybe the "child"
> > > threads can inherit the ThreadLocals of the thread that started them ?
> > >
> > > Anyway, it's just a curiosity question :-) After spending a
> considerable
> > > time learning and reading about Lift ( I liked some of the
> > non-traditional
> > > approaches that it takes to building web apps ) , my final conclusion
> was
> > > that Tapestry's component focused approach was superior ( I was quite
> > > surprised that despite being "view centric" Lift didn't have a way of
> > > coupling the snippet template and the snippet code into a cohesive
> > > component).
> > >
> > > Cheers - Alex K
> > >
> >
>
Re: "Parallel" component rendering
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Tue, 04 Nov 2014 20:30:30 -0200, Lance Java <la...@googlemail.com>
wrote:
> I'd actually wager a bet that the overhead of managing the threads
> actually increases the rendering time.
Me too.
> If it's the data retrieval that's taking the time, a cache or
> multi-threaded data retrieval is probably a better place to focus your
> efforts.
Exactly. I believe rendering, by itself, consumes way less time than
fetching or writing data to data stores (such as databases), so, even if
there was no overhead in parallelization, but it does, the render speed
improvement would be insignificant.
Alex, also everyone, all ideas, even the far-fetched, are always welcome.
Thanks for that!
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "Parallel" component rendering
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 06 Nov 2014 14:17:04 -0200, Howard Lewis Ship <hl...@gmail.com>
wrote:
> I've been thinking of a blog post about everything I would do differently
> in Tapestry if I had perfect foreknowledge. Trust me, it would be
> different, and simpler in many ways ... and based more heavily on
> immutability (& controlled mutability) ala Clojure.
Please do it! It'll probably be very interesting. We could learn a lot
from it. :)
> Parallel rendering would be nice though not as practical as you'd think
> ...
Even not thinking it's worth to be included in Tapestry, why wouldn't it
as practical as we (mostly Alex) think? I do think it would have a
negligible gain.
> but it would open the door for things like Hysterix (or other forms of
> circuit breakers).
Thanks for the Hystrix mention (https://github.com/Netflix/Hystrix). I'd
never heard of that and it seems very insteresting.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "Parallel" component rendering
Posted by Howard Lewis Ship <hl...@gmail.com>.
I've been thinking of a blog post about everything I would do differently
in Tapestry if I had perfect foreknowledge. Trust me, it would be
different, and simpler in many ways ... and based more heavily on
immutability (& controlled mutability) ala Clojure.
Parallel rendering would be nice though not as practical as you'd think ...
but it would open the door for things like Hysterix (or other forms of
circuit breakers).
On Thu, Nov 6, 2014 at 4:37 AM, Thiago H de Paula Figueiredo <
thiagohp@gmail.com> wrote:
> On Thu, 06 Nov 2014 00:58:51 -0200, Alex Kotchnev <ak...@gmail.com>
> wrote:
>
> Thago & Lance - thanks a lot for your detailed comments and ideas.
>>
>
> ;)
>
> http://apache-tapestry-mailing-list-archives.1045711.
>> n5.nabble.com/Page-instance-variables-and-threads-td5728565.html
>>
>
> In your case, this may be a Scala-Java behavior expectation mismatch. If
> you wrote the exact same logic in Java, your closure would be a anonymous
> inner class, non-static. This means instances of the closure have an have
> an implicit reference to the surrounding object, which is the Tapestry
> page, which right now cannot be shared among threads, resulting on what
> you're experiencing. So you're not passing just the field value to the
> closure: you're passing the whole page object.
>
> As Lance said, if you created a final variable copying the value of the
> field, it would work. Here's an example, but be warned I've never
> programmed in Scala:
>
> class ShowServer {
> @PageActivationContext @Property
> var sn:String = _
>
> def setupRender():Unit = {
> val string = sn
> val servDetFut = for {
> jg <- future { mgr.jarGroupName(string)}
> props = mgr.props(string)
> pl <- future { mgr.players(string) }
> worlds <- future { mgr.listWorlds(string)}
> ops <- future { mgr.ops(string) }
> wl <- future { mgr.whitelist(string)}
> bl <- future { mgr.blacklist(string) }
> } yield McServerDetails(
> server = mcServer,
> jarGroup = jg,
> worlds = worlds.toArray,
> players = pl.toArray,
> ops = ops.toArray,
> whiteList = wl.toArray,
> blackListed = bl,
> props = props
> )
> }
>
> serverDetails = Await.result(servDetFut, 60.seconds)
> }
>
> In terms of being able to pass the state to the child threads, I was
>> thinking - is there a way to put this state into InheritableThreadLocals
>> (instead of ThreadLocals) so that child threads have access to the thread
>> local state. Granted, it seems that with InheritableThreadLocals, if any
>> state changes in the child thread it will not propagated to its parent,
>> but
>> that might be OK.
>>
>
> This seems to be a very good idea. I'm not familiar with
> InheritableThreadLocal. What could be the downsides of using it instead of
> ThreadLocal? Performance? If yes, what would be the overhead? Anyway, we
> could create an annotation to force a page instance to use
> InheritableThreadLocal instead of ThreadLocal, which would remain the
> default.
>
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> 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
@hlship
Re: "Parallel" component rendering
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
On Thu, 06 Nov 2014 00:58:51 -0200, Alex Kotchnev <ak...@gmail.com>
wrote:
> Thago & Lance - thanks a lot for your detailed comments and ideas.
;)
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Page-instance-variables-and-threads-td5728565.html
In your case, this may be a Scala-Java behavior expectation mismatch. If
you wrote the exact same logic in Java, your closure would be a anonymous
inner class, non-static. This means instances of the closure have an have
an implicit reference to the surrounding object, which is the Tapestry
page, which right now cannot be shared among threads, resulting on what
you're experiencing. So you're not passing just the field value to the
closure: you're passing the whole page object.
As Lance said, if you created a final variable copying the value of the
field, it would work. Here's an example, but be warned I've never
programmed in Scala:
class ShowServer {
@PageActivationContext @Property
var sn:String = _
def setupRender():Unit = {
val string = sn
val servDetFut = for {
jg <- future { mgr.jarGroupName(string)}
props = mgr.props(string)
pl <- future { mgr.players(string) }
worlds <- future { mgr.listWorlds(string)}
ops <- future { mgr.ops(string) }
wl <- future { mgr.whitelist(string)}
bl <- future { mgr.blacklist(string) }
} yield McServerDetails(
server = mcServer,
jarGroup = jg,
worlds = worlds.toArray,
players = pl.toArray,
ops = ops.toArray,
whiteList = wl.toArray,
blackListed = bl,
props = props
)
}
serverDetails = Await.result(servDetFut, 60.seconds)
}
> In terms of being able to pass the state to the child threads, I was
> thinking - is there a way to put this state into InheritableThreadLocals
> (instead of ThreadLocals) so that child threads have access to the thread
> local state. Granted, it seems that with InheritableThreadLocals, if any
> state changes in the child thread it will not propagated to its parent,
> but
> that might be OK.
This seems to be a very good idea. I'm not familiar with
InheritableThreadLocal. What could be the downsides of using it instead of
ThreadLocal? Performance? If yes, what would be the overhead? Anyway, we
could create an annotation to force a page instance to use
InheritableThreadLocal instead of ThreadLocal, which would remain the
default.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
This will get you started
https://gist.github.com/uklance/88c9a5400872273d9b14
On 6 Nov 2014 03:01, "Alex Kotchnev" <ak...@gmail.com> wrote:
> Thago & Lance - thanks a lot for your detailed comments and ideas. On to
> the details :
>
> The issue that I ran into with passing page instance variables into threads
> is at
>
> http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Page-instance-variables-and-threads-td5728565.html
> . The specific issue is that the page instance variable is just a "facade"
> to the state that is stored in the thread local - while I'm accessing it
> inside a page method (same thread), I can access the value. When I access
> the same variable inside the new thread, it's value is null, as the new
> thread doesn't inherit the thread locals of its parent thread.
>
> Lance - any chance you could throw you example component into a GitHub gist
> for me to see ?
>
> In terms of being able to pass the state to the child threads, I was
> thinking - is there a way to put this state into InheritableThreadLocals
> (instead of ThreadLocals) so that child threads have access to the thread
> local state. Granted, it seems that with InheritableThreadLocals, if any
> state changes in the child thread it will not propagated to its parent, but
> that might be OK.
>
> Cheers - Alex K
>
>
>
> On Wed, Nov 5, 2014 at 6:34 PM, Lance Java <la...@googlemail.com>
> wrote:
>
> > FYI I've worked out a very simple / no frills way to do this.
> >
> > <t:parallel>
> > <t:someComponent />
> > </t:parallel>
> >
> > The parallel component would then render it's
> ComponentResources.getBody()
> > in a separate thread (note that the body Block can be TypeCoerced to
> > RenderCommand).
> >
> > As Thiago discussed, his shell element concept could be achieved by
> passing
> > an empty RenderQueue and MarkupWriter to the body RenderCommand (which is
> > rendering asynchronously to the main request). Once the async render
> > finishes, the resultant markup String could be introduced into the main
> DOM
> > on the request thread.
> >
> > Note that request / response will be null on the async thread. Any
> request
> > scoped property bindings and Environmentals will also be null.
> > PerthreadManager.cleanupThread() should be called after the async render.
> > On 5 Nov 2014 16:51, "Thiago H de Paula Figueiredo" <thiagohp@gmail.com
> >
> > wrote:
> >
> > > Hello, Alex!
> > >
> > > On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev <ak...@gmail.com>
> > > wrote:
> > >
> > > I'm a bit puzzled by the negative vibe that I'm getting. Just to be
> > clear
> > >> -
> > >>
> > >
> > > I'm not perceiving any negative vibe, just one idea being proposed and
> > > some people thinking that it wouldn't actually reach its objective
> > (making
> > > page rendering faster).
> > >
> > > I'm not asking anyone to do any work on my behalf, or to drop
> everything
> > >> and work on this as if it's the most important thing in the world
> (which
> > >> it is not). I'm also not here to troll and say "tapestry sucks, this
> > other
> > >> framework is better"
> > >>
> > >
> > > I don't think anyone here is thinking that. I definitely am not. :)
> > >
> > > - nothing of the sort (in my first email I did
> > >
> > >> explicitly mention that after evaluating the two for a while I did
> find
> > >> Tapestry to be superior and I'm still sticking with it). I saw this
> > >> approach in a different framework, I found it interesting and I'm
> > curious
> > >> for input from the more knowledgeable people on this list on how one
> > >> might tackle this.
> > >>
> > >
> > > I actually think it's doable without a thread-safe DOM, but with some
> > > limitations, even if I think it's not worth the effort:
> > > 1) The component would need to generate a DOM element immediately,
> let's
> > > call it shell element, before spawning a new thread. This way, the new
> > > thread would only work inside this shell element, avoiding the need of
> > > synchronizing the whole DOM tree (Document instance). This could be
> > > implemented with a new render phase event.
> > > 2) The component should avoid changing DOM elements it didn't create
> > > (a.k.a DOM rewriting), just creating new elements inside this shell
> > element.
> > > 3) The component couldn't be in a loop (Loop or Grid), as the same
> > > component instance is rendered many times.
> > > 4) The developer must know that things may go wrong in unexpected ways.
> > >
> > > likely be much faster than actually getting the data. The trouble is
> > that
> > >> I did try the approach of "firing up new threads to do the work", but
> > then
> > >> I ran into issues w/ Tapestry's thread local data not being available
> in
> > >> those other threads when I pass in the variables from my tapestry
> > >> page/component ( I posted in a different thread a few weeks ago about
> > >> that).
> > >>
> > >
> > > This is weird. If you don't pass the component, page or mixin objects
> > > themselves to this other threads, there shouldn't be any problem. Could
> > you
> > > link to the thread please?
> > >
> > > @Lance - thanks for pointing out the fact about the mutability of the
> > DOM
> > >> - AFAIK, Lift snippets are indeed "transformations" of the DOM that
> they
> > >> manipulate, and from the POV of how Scala deals w/ XML the DOM is
> > treated
> > >> as an immutable structure that goes through a bunch of
> transformations.
> > >> So, this might be a critical distinction that I missed in my initial
> > thought
> > >> process.
> > >>
> > >
> > > Lift is a Scala framework. Scala favors immutable structures, so this
> > > difference between Lift and Tapestry isn't unexpected to me.
> > >
> > > Anyway, the argument here seems to me like the argument for parallel
> > >> collections (when I first saw them in Groovy for example). My initial
> > >> reaction when I saw them for the first time was "why the heck would I
> > >> want to do this, of course I'd want to go over my collection items one
> > by
> > >> one".
> > >>
> > >
> > > Actually, in some cases, the parallelized version is slower than the
> > > sequential one due to threading overhead.
> > >
> > > --
> > > Thiago H. de Paula Figueiredo
> > > Tapestry, Java and Hibernate consultant and developer
> > > http://machina.com.br
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
> > >
> > >
> >
>
Re: "Parallel" component rendering
Posted by Alex Kotchnev <ak...@gmail.com>.
Thago & Lance - thanks a lot for your detailed comments and ideas. On to
the details :
The issue that I ran into with passing page instance variables into threads
is at
http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Page-instance-variables-and-threads-td5728565.html
. The specific issue is that the page instance variable is just a "facade"
to the state that is stored in the thread local - while I'm accessing it
inside a page method (same thread), I can access the value. When I access
the same variable inside the new thread, it's value is null, as the new
thread doesn't inherit the thread locals of its parent thread.
Lance - any chance you could throw you example component into a GitHub gist
for me to see ?
In terms of being able to pass the state to the child threads, I was
thinking - is there a way to put this state into InheritableThreadLocals
(instead of ThreadLocals) so that child threads have access to the thread
local state. Granted, it seems that with InheritableThreadLocals, if any
state changes in the child thread it will not propagated to its parent, but
that might be OK.
Cheers - Alex K
On Wed, Nov 5, 2014 at 6:34 PM, Lance Java <la...@googlemail.com>
wrote:
> FYI I've worked out a very simple / no frills way to do this.
>
> <t:parallel>
> <t:someComponent />
> </t:parallel>
>
> The parallel component would then render it's ComponentResources.getBody()
> in a separate thread (note that the body Block can be TypeCoerced to
> RenderCommand).
>
> As Thiago discussed, his shell element concept could be achieved by passing
> an empty RenderQueue and MarkupWriter to the body RenderCommand (which is
> rendering asynchronously to the main request). Once the async render
> finishes, the resultant markup String could be introduced into the main DOM
> on the request thread.
>
> Note that request / response will be null on the async thread. Any request
> scoped property bindings and Environmentals will also be null.
> PerthreadManager.cleanupThread() should be called after the async render.
> On 5 Nov 2014 16:51, "Thiago H de Paula Figueiredo" <th...@gmail.com>
> wrote:
>
> > Hello, Alex!
> >
> > On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev <ak...@gmail.com>
> > wrote:
> >
> > I'm a bit puzzled by the negative vibe that I'm getting. Just to be
> clear
> >> -
> >>
> >
> > I'm not perceiving any negative vibe, just one idea being proposed and
> > some people thinking that it wouldn't actually reach its objective
> (making
> > page rendering faster).
> >
> > I'm not asking anyone to do any work on my behalf, or to drop everything
> >> and work on this as if it's the most important thing in the world (which
> >> it is not). I'm also not here to troll and say "tapestry sucks, this
> other
> >> framework is better"
> >>
> >
> > I don't think anyone here is thinking that. I definitely am not. :)
> >
> > - nothing of the sort (in my first email I did
> >
> >> explicitly mention that after evaluating the two for a while I did find
> >> Tapestry to be superior and I'm still sticking with it). I saw this
> >> approach in a different framework, I found it interesting and I'm
> curious
> >> for input from the more knowledgeable people on this list on how one
> >> might tackle this.
> >>
> >
> > I actually think it's doable without a thread-safe DOM, but with some
> > limitations, even if I think it's not worth the effort:
> > 1) The component would need to generate a DOM element immediately, let's
> > call it shell element, before spawning a new thread. This way, the new
> > thread would only work inside this shell element, avoiding the need of
> > synchronizing the whole DOM tree (Document instance). This could be
> > implemented with a new render phase event.
> > 2) The component should avoid changing DOM elements it didn't create
> > (a.k.a DOM rewriting), just creating new elements inside this shell
> element.
> > 3) The component couldn't be in a loop (Loop or Grid), as the same
> > component instance is rendered many times.
> > 4) The developer must know that things may go wrong in unexpected ways.
> >
> > likely be much faster than actually getting the data. The trouble is
> that
> >> I did try the approach of "firing up new threads to do the work", but
> then
> >> I ran into issues w/ Tapestry's thread local data not being available in
> >> those other threads when I pass in the variables from my tapestry
> >> page/component ( I posted in a different thread a few weeks ago about
> >> that).
> >>
> >
> > This is weird. If you don't pass the component, page or mixin objects
> > themselves to this other threads, there shouldn't be any problem. Could
> you
> > link to the thread please?
> >
> > @Lance - thanks for pointing out the fact about the mutability of the
> DOM
> >> - AFAIK, Lift snippets are indeed "transformations" of the DOM that they
> >> manipulate, and from the POV of how Scala deals w/ XML the DOM is
> treated
> >> as an immutable structure that goes through a bunch of transformations.
> >> So, this might be a critical distinction that I missed in my initial
> thought
> >> process.
> >>
> >
> > Lift is a Scala framework. Scala favors immutable structures, so this
> > difference between Lift and Tapestry isn't unexpected to me.
> >
> > Anyway, the argument here seems to me like the argument for parallel
> >> collections (when I first saw them in Groovy for example). My initial
> >> reaction when I saw them for the first time was "why the heck would I
> >> want to do this, of course I'd want to go over my collection items one
> by
> >> one".
> >>
> >
> > Actually, in some cases, the parallelized version is slower than the
> > sequential one due to threading overhead.
> >
> > --
> > Thiago H. de Paula Figueiredo
> > Tapestry, Java and Hibernate consultant and developer
> > http://machina.com.br
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
FYI I've worked out a very simple / no frills way to do this.
<t:parallel>
<t:someComponent />
</t:parallel>
The parallel component would then render it's ComponentResources.getBody()
in a separate thread (note that the body Block can be TypeCoerced to
RenderCommand).
As Thiago discussed, his shell element concept could be achieved by passing
an empty RenderQueue and MarkupWriter to the body RenderCommand (which is
rendering asynchronously to the main request). Once the async render
finishes, the resultant markup String could be introduced into the main DOM
on the request thread.
Note that request / response will be null on the async thread. Any request
scoped property bindings and Environmentals will also be null.
PerthreadManager.cleanupThread() should be called after the async render.
On 5 Nov 2014 16:51, "Thiago H de Paula Figueiredo" <th...@gmail.com>
wrote:
> Hello, Alex!
>
> On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev <ak...@gmail.com>
> wrote:
>
> I'm a bit puzzled by the negative vibe that I'm getting. Just to be clear
>> -
>>
>
> I'm not perceiving any negative vibe, just one idea being proposed and
> some people thinking that it wouldn't actually reach its objective (making
> page rendering faster).
>
> I'm not asking anyone to do any work on my behalf, or to drop everything
>> and work on this as if it's the most important thing in the world (which
>> it is not). I'm also not here to troll and say "tapestry sucks, this other
>> framework is better"
>>
>
> I don't think anyone here is thinking that. I definitely am not. :)
>
> - nothing of the sort (in my first email I did
>
>> explicitly mention that after evaluating the two for a while I did find
>> Tapestry to be superior and I'm still sticking with it). I saw this
>> approach in a different framework, I found it interesting and I'm curious
>> for input from the more knowledgeable people on this list on how one
>> might tackle this.
>>
>
> I actually think it's doable without a thread-safe DOM, but with some
> limitations, even if I think it's not worth the effort:
> 1) The component would need to generate a DOM element immediately, let's
> call it shell element, before spawning a new thread. This way, the new
> thread would only work inside this shell element, avoiding the need of
> synchronizing the whole DOM tree (Document instance). This could be
> implemented with a new render phase event.
> 2) The component should avoid changing DOM elements it didn't create
> (a.k.a DOM rewriting), just creating new elements inside this shell element.
> 3) The component couldn't be in a loop (Loop or Grid), as the same
> component instance is rendered many times.
> 4) The developer must know that things may go wrong in unexpected ways.
>
> likely be much faster than actually getting the data. The trouble is that
>> I did try the approach of "firing up new threads to do the work", but then
>> I ran into issues w/ Tapestry's thread local data not being available in
>> those other threads when I pass in the variables from my tapestry
>> page/component ( I posted in a different thread a few weeks ago about
>> that).
>>
>
> This is weird. If you don't pass the component, page or mixin objects
> themselves to this other threads, there shouldn't be any problem. Could you
> link to the thread please?
>
> @Lance - thanks for pointing out the fact about the mutability of the DOM
>> - AFAIK, Lift snippets are indeed "transformations" of the DOM that they
>> manipulate, and from the POV of how Scala deals w/ XML the DOM is treated
>> as an immutable structure that goes through a bunch of transformations.
>> So, this might be a critical distinction that I missed in my initial thought
>> process.
>>
>
> Lift is a Scala framework. Scala favors immutable structures, so this
> difference between Lift and Tapestry isn't unexpected to me.
>
> Anyway, the argument here seems to me like the argument for parallel
>> collections (when I first saw them in Groovy for example). My initial
>> reaction when I saw them for the first time was "why the heck would I
>> want to do this, of course I'd want to go over my collection items one by
>> one".
>>
>
> Actually, in some cases, the parallelized version is slower than the
> sequential one due to threading overhead.
>
> --
> Thiago H. de Paula Figueiredo
> Tapestry, Java and Hibernate consultant and developer
> http://machina.com.br
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
Re: "Parallel" component rendering
Posted by Thiago H de Paula Figueiredo <th...@gmail.com>.
Hello, Alex!
On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev <ak...@gmail.com>
wrote:
> I'm a bit puzzled by the negative vibe that I'm getting. Just to be
> clear -
I'm not perceiving any negative vibe, just one idea being proposed and
some people thinking that it wouldn't actually reach its objective (making
page rendering faster).
> I'm not asking anyone to do any work on my behalf, or to drop everything
> and work on this as if it's the most important thing in the world (which
> it is not). I'm also not here to troll and say "tapestry sucks, this
> other
> framework is better"
I don't think anyone here is thinking that. I definitely am not. :)
- nothing of the sort (in my first email I did
> explicitly mention that after evaluating the two for a while I did find
> Tapestry to be superior and I'm still sticking with it). I saw this
> approach in a different framework, I found it interesting and I'm curious
> for input from the more knowledgeable people on this list on how one
> might tackle this.
I actually think it's doable without a thread-safe DOM, but with some
limitations, even if I think it's not worth the effort:
1) The component would need to generate a DOM element immediately, let's
call it shell element, before spawning a new thread. This way, the new
thread would only work inside this shell element, avoiding the need of
synchronizing the whole DOM tree (Document instance). This could be
implemented with a new render phase event.
2) The component should avoid changing DOM elements it didn't create
(a.k.a DOM rewriting), just creating new elements inside this shell
element.
3) The component couldn't be in a loop (Loop or Grid), as the same
component instance is rendered many times.
4) The developer must know that things may go wrong in unexpected ways.
> likely be much faster than actually getting the data. The trouble is
> that I did try the approach of "firing up new threads to do the work",
> but then I ran into issues w/ Tapestry's thread local data not being
> available in
> those other threads when I pass in the variables from my tapestry
> page/component ( I posted in a different thread a few weeks ago about
> that).
This is weird. If you don't pass the component, page or mixin objects
themselves to this other threads, there shouldn't be any problem. Could
you link to the thread please?
> @Lance - thanks for pointing out the fact about the mutability of the
> DOM - AFAIK, Lift snippets are indeed "transformations" of the DOM that
> they
> manipulate, and from the POV of how Scala deals w/ XML the DOM is treated
> as an immutable structure that goes through a bunch of transformations.
> So, this might be a critical distinction that I missed in my initial
> thought
> process.
Lift is a Scala framework. Scala favors immutable structures, so this
difference between Lift and Tapestry isn't unexpected to me.
> Anyway, the argument here seems to me like the argument for parallel
> collections (when I first saw them in Groovy for example). My initial
> reaction when I saw them for the first time was "why the heck would I
> want to do this, of course I'd want to go over my collection items one
> by one".
Actually, in some cases, the parallelized version is slower than the
sequential one due to threading overhead.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
Sorry for the negative vibe, I guess with an annotation you could keep
single threaded as the norm and add @Parallel to components which are slow.
Under the hood, all rendering is done via the RenderCommand interface which
could, in theory, be parallelized.
You'd probably have a pool of render threads for the parallel work. These
threads would need to be initialized and cleaned up and be able to access
per-thread values (including Environmentals and services etc). You could
probably record() any thread local actions on the request thread and
replay() them on the worker thread.
You'd need to consider ordering in cases when one component needs to render
after another (think @Environmental dependencies or DOM dependencies).
Since a thread-safe DOM will be slower, you'll want to check for @Parallel
and default to the faster DOM if no @Parallel is present.
Re: "Parallel" component rendering
Posted by Alex Kotchnev <ak...@gmail.com>.
I'm a bit puzzled by the negative vibe that I'm getting. Just to be clear -
I'm not asking anyone to do any work on my behalf, or to drop everything
and work on this as if it's the most important thing in the world (which it
is not). I'm also not here to troll and say "tapestry sucks, this other
framework is better" - nothing of the sort (in my first email I did
explicitly mention that after evaluating the two for a while I did find
Tapestry to be superior and I'm still sticking with it). I saw this
approach in a different framework, I found it interesting and I'm curious
for input from the more knowledgeable people on this list on how one might
tackle this.
First off, a clarification on the notion of parallelized rendering - I most
wholeheartedly agree that if there was any place to parallelize , that
would be data access (e.g. in the case of tapestry, usually that kind of
"preparation" work would occur in "setup" and "prepare" kind of events -
e.g. setupRender, prepareForSubmit, etc). Obviously once the data is there,
the process of generating the markup based on the available data would
likely be much faster than actually getting the data. The trouble is that I
did try the approach of "firing up new threads to do the work", but then I
ran into issues w/ Tapestry's thread local data not being available in
those other threads when I pass in the variables from my tapestry
page/component ( I posted in a different thread a few weeks ago about
that). This surely is doable, but certainly goes against the grain of the
framework. Hence, I became curious of how this might work (or why it might
not) in the case of Tapestry.
On "why" I'd be interested in doing this - while there is always a chance
of multiple interacting components on the same page, from a practical point
of view and from prior experience, different components on a page often are
independent of each other (I'd also argue that it's a good "component
oriented" approach to have the components not have dependencies on each
other unless they really need to), and thus could be rendered independently
of each other. So, if I have a few independent components, I would ideally
want to add an annotation or an attribute somewhere that would fire up a
couple of threads (yes, if such threads are available based on the
threading of the server - Kalle, valid point, thanks for bringing it up)
which would handle the lifecycle events of the components (e.g. the parts
where data is fetched , e.g. in setupRender) and the actual rendering of
the components, until in the end the DOM contains the output of these
components. I don't want to belabor the trivial points, but if each of the
three components takes 1,2,and 3 seconds to render, obviously if rendered
serially it would take a total of 6 seconds, rendered in parallel it would
only take 3 seconds (the longest time of the three) + any time for the
overhead.
@Lance - thanks for pointing out the fact about the mutability of the DOM -
AFAIK, Lift snippets are indeed "transformations" of the DOM that they
manipulate, and from the POV of how Scala deals w/ XML the DOM is treated
as an immutable structure that goes through a bunch of transformations. So,
this might be a critical distinction that I missed in my initial thought
process.
Anyway, the argument here seems to me like the argument for parallel
collections (when I first saw them in Groovy for example). My initial
reaction when I saw them for the first time was "why the heck would I want
to do this, of course I'd want to go over my collection items one by one".
But obviously, there are good cases where it makes sense to use
parallelized collections.
Cheers - Alex K
On Tue, Nov 4, 2014 at 5:43 PM, Lance Java <la...@googlemail.com>
wrote:
> One thing to note is that pages, components and mixins are all mutating a
> document object. I can only assume that parallel rendering would require
> the DOM to be thread safe. My gut feel is that this would actually make
> rendering slower.
> On 4 Nov 2014 22:30, "Lance Java" <la...@googlemail.com> wrote:
>
> > I'd argue that there's "bigger fish to fry" than parallel rendering.
> >
> > What's all the "work" that will benefit from parallelisation? Because the
> > actual rendering itself is unlikely to see any significant time reduction
> > by multi threading.
> >
> > I'd actually wager a bet that the overhead of managing the threads
> > actually increases the rendering time.
> >
> > If it's the data retrieval that's taking the time, a cache or
> > multi-threaded data retrieval is probably a better place to focus your
> > efforts.
> > On 4 Nov 2014 21:52, "Alex Kotchnev" <ak...@gmail.com> wrote:
> >
> >> Lance - I'm not saying that doing this would work out of the box or that
> >> it
> >> would be trivial , I understand that Tapestry as a framework has made
> >> choices that might make this difficult or impossible. Yet, it's a cool
> >> idea, in a way that a framework should be able to support its users
> (e.g.
> >> "ah, you want these rendered in parallel, fine, let me do this for you"
> >> kind of way). It seems like something that can be doable in Tapestry as
> >> well, I'm just not entirely sure how . It certainly seems possible to
> >> launch the "child threads" and have them have access to the parent
> >> thread's
> >> ThreadLocals.
> >>
> >> Cheers -
> >>
> >> On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <la...@googlemail.com>
> >> wrote:
> >>
> >> > I'd say this is not a great idea. Tapestry assumes that rendering is
> >> all on
> >> > the same thread. The request and response (and other thread scoped
> >> > services) will be null on a non-request thread for instance. Also each
> >> > thread will have a separate hibernate session if using
> >> tapestry-hibernate
> >> > which will need to be cleaned up and won't share a level1 cache.
> >> > On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
> >> >
> >> > > I've been poking around Lift for the last few months and one of the
> >> > > interesting approaches it has is that it can mark "snippets"
> (roughly
> >> the
> >> > > equivalent of tapestry compoents) as "parallel" - what Lift does w/
> >> > > snippets that are marked in parallel is that it fires up new threads
> >> for
> >> > > rendering those snippets and waits for all of them to complete
> before
> >> > > rendering the page / final output.
> >> > >
> >> > > Seems like a cool idea - knowing that Tapestry stores its state in
> >> > > ThreadLocal variables it seems that doing something similar wouldn't
> >> be
> >> > > trivial. Would something similar be possible - e.g. maybe the
> "child"
> >> > > threads can inherit the ThreadLocals of the thread that started
> them ?
> >> > >
> >> > > Anyway, it's just a curiosity question :-) After spending a
> >> considerable
> >> > > time learning and reading about Lift ( I liked some of the
> >> > non-traditional
> >> > > approaches that it takes to building web apps ) , my final
> conclusion
> >> was
> >> > > that Tapestry's component focused approach was superior ( I was
> quite
> >> > > surprised that despite being "view centric" Lift didn't have a way
> of
> >> > > coupling the snippet template and the snippet code into a cohesive
> >> > > component).
> >> > >
> >> > > Cheers - Alex K
> >> > >
> >> >
> >>
> >
>
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
One thing to note is that pages, components and mixins are all mutating a
document object. I can only assume that parallel rendering would require
the DOM to be thread safe. My gut feel is that this would actually make
rendering slower.
On 4 Nov 2014 22:30, "Lance Java" <la...@googlemail.com> wrote:
> I'd argue that there's "bigger fish to fry" than parallel rendering.
>
> What's all the "work" that will benefit from parallelisation? Because the
> actual rendering itself is unlikely to see any significant time reduction
> by multi threading.
>
> I'd actually wager a bet that the overhead of managing the threads
> actually increases the rendering time.
>
> If it's the data retrieval that's taking the time, a cache or
> multi-threaded data retrieval is probably a better place to focus your
> efforts.
> On 4 Nov 2014 21:52, "Alex Kotchnev" <ak...@gmail.com> wrote:
>
>> Lance - I'm not saying that doing this would work out of the box or that
>> it
>> would be trivial , I understand that Tapestry as a framework has made
>> choices that might make this difficult or impossible. Yet, it's a cool
>> idea, in a way that a framework should be able to support its users (e.g.
>> "ah, you want these rendered in parallel, fine, let me do this for you"
>> kind of way). It seems like something that can be doable in Tapestry as
>> well, I'm just not entirely sure how . It certainly seems possible to
>> launch the "child threads" and have them have access to the parent
>> thread's
>> ThreadLocals.
>>
>> Cheers -
>>
>> On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <la...@googlemail.com>
>> wrote:
>>
>> > I'd say this is not a great idea. Tapestry assumes that rendering is
>> all on
>> > the same thread. The request and response (and other thread scoped
>> > services) will be null on a non-request thread for instance. Also each
>> > thread will have a separate hibernate session if using
>> tapestry-hibernate
>> > which will need to be cleaned up and won't share a level1 cache.
>> > On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
>> >
>> > > I've been poking around Lift for the last few months and one of the
>> > > interesting approaches it has is that it can mark "snippets" (roughly
>> the
>> > > equivalent of tapestry compoents) as "parallel" - what Lift does w/
>> > > snippets that are marked in parallel is that it fires up new threads
>> for
>> > > rendering those snippets and waits for all of them to complete before
>> > > rendering the page / final output.
>> > >
>> > > Seems like a cool idea - knowing that Tapestry stores its state in
>> > > ThreadLocal variables it seems that doing something similar wouldn't
>> be
>> > > trivial. Would something similar be possible - e.g. maybe the "child"
>> > > threads can inherit the ThreadLocals of the thread that started them ?
>> > >
>> > > Anyway, it's just a curiosity question :-) After spending a
>> considerable
>> > > time learning and reading about Lift ( I liked some of the
>> > non-traditional
>> > > approaches that it takes to building web apps ) , my final conclusion
>> was
>> > > that Tapestry's component focused approach was superior ( I was quite
>> > > surprised that despite being "view centric" Lift didn't have a way of
>> > > coupling the snippet template and the snippet code into a cohesive
>> > > component).
>> > >
>> > > Cheers - Alex K
>> > >
>> >
>>
>
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
I'd argue that there's "bigger fish to fry" than parallel rendering.
What's all the "work" that will benefit from parallelisation? Because the
actual rendering itself is unlikely to see any significant time reduction
by multi threading.
I'd actually wager a bet that the overhead of managing the threads actually
increases the rendering time.
If it's the data retrieval that's taking the time, a cache or
multi-threaded data retrieval is probably a better place to focus your
efforts.
On 4 Nov 2014 21:52, "Alex Kotchnev" <ak...@gmail.com> wrote:
> Lance - I'm not saying that doing this would work out of the box or that it
> would be trivial , I understand that Tapestry as a framework has made
> choices that might make this difficult or impossible. Yet, it's a cool
> idea, in a way that a framework should be able to support its users (e.g.
> "ah, you want these rendered in parallel, fine, let me do this for you"
> kind of way). It seems like something that can be doable in Tapestry as
> well, I'm just not entirely sure how . It certainly seems possible to
> launch the "child threads" and have them have access to the parent thread's
> ThreadLocals.
>
> Cheers -
>
> On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <la...@googlemail.com>
> wrote:
>
> > I'd say this is not a great idea. Tapestry assumes that rendering is all
> on
> > the same thread. The request and response (and other thread scoped
> > services) will be null on a non-request thread for instance. Also each
> > thread will have a separate hibernate session if using tapestry-hibernate
> > which will need to be cleaned up and won't share a level1 cache.
> > On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
> >
> > > I've been poking around Lift for the last few months and one of the
> > > interesting approaches it has is that it can mark "snippets" (roughly
> the
> > > equivalent of tapestry compoents) as "parallel" - what Lift does w/
> > > snippets that are marked in parallel is that it fires up new threads
> for
> > > rendering those snippets and waits for all of them to complete before
> > > rendering the page / final output.
> > >
> > > Seems like a cool idea - knowing that Tapestry stores its state in
> > > ThreadLocal variables it seems that doing something similar wouldn't be
> > > trivial. Would something similar be possible - e.g. maybe the "child"
> > > threads can inherit the ThreadLocals of the thread that started them ?
> > >
> > > Anyway, it's just a curiosity question :-) After spending a
> considerable
> > > time learning and reading about Lift ( I liked some of the
> > non-traditional
> > > approaches that it takes to building web apps ) , my final conclusion
> was
> > > that Tapestry's component focused approach was superior ( I was quite
> > > surprised that despite being "view centric" Lift didn't have a way of
> > > coupling the snippet template and the snippet code into a cohesive
> > > component).
> > >
> > > Cheers - Alex K
> > >
> >
>
Re: "Parallel" component rendering
Posted by Alex Kotchnev <ak...@gmail.com>.
Lance - I'm not saying that doing this would work out of the box or that it
would be trivial , I understand that Tapestry as a framework has made
choices that might make this difficult or impossible. Yet, it's a cool
idea, in a way that a framework should be able to support its users (e.g.
"ah, you want these rendered in parallel, fine, let me do this for you"
kind of way). It seems like something that can be doable in Tapestry as
well, I'm just not entirely sure how . It certainly seems possible to
launch the "child threads" and have them have access to the parent thread's
ThreadLocals.
Cheers -
On Tue, Nov 4, 2014 at 3:34 PM, Lance Java <la...@googlemail.com>
wrote:
> I'd say this is not a great idea. Tapestry assumes that rendering is all on
> the same thread. The request and response (and other thread scoped
> services) will be null on a non-request thread for instance. Also each
> thread will have a separate hibernate session if using tapestry-hibernate
> which will need to be cleaned up and won't share a level1 cache.
> On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
>
> > I've been poking around Lift for the last few months and one of the
> > interesting approaches it has is that it can mark "snippets" (roughly the
> > equivalent of tapestry compoents) as "parallel" - what Lift does w/
> > snippets that are marked in parallel is that it fires up new threads for
> > rendering those snippets and waits for all of them to complete before
> > rendering the page / final output.
> >
> > Seems like a cool idea - knowing that Tapestry stores its state in
> > ThreadLocal variables it seems that doing something similar wouldn't be
> > trivial. Would something similar be possible - e.g. maybe the "child"
> > threads can inherit the ThreadLocals of the thread that started them ?
> >
> > Anyway, it's just a curiosity question :-) After spending a considerable
> > time learning and reading about Lift ( I liked some of the
> non-traditional
> > approaches that it takes to building web apps ) , my final conclusion was
> > that Tapestry's component focused approach was superior ( I was quite
> > surprised that despite being "view centric" Lift didn't have a way of
> > coupling the snippet template and the snippet code into a cohesive
> > component).
> >
> > Cheers - Alex K
> >
>
Re: "Parallel" component rendering
Posted by Lance Java <la...@googlemail.com>.
I'd say this is not a great idea. Tapestry assumes that rendering is all on
the same thread. The request and response (and other thread scoped
services) will be null on a non-request thread for instance. Also each
thread will have a separate hibernate session if using tapestry-hibernate
which will need to be cleaned up and won't share a level1 cache.
On 4 Nov 2014 19:57, "Alex Kotchnev" <ak...@gmail.com> wrote:
> I've been poking around Lift for the last few months and one of the
> interesting approaches it has is that it can mark "snippets" (roughly the
> equivalent of tapestry compoents) as "parallel" - what Lift does w/
> snippets that are marked in parallel is that it fires up new threads for
> rendering those snippets and waits for all of them to complete before
> rendering the page / final output.
>
> Seems like a cool idea - knowing that Tapestry stores its state in
> ThreadLocal variables it seems that doing something similar wouldn't be
> trivial. Would something similar be possible - e.g. maybe the "child"
> threads can inherit the ThreadLocals of the thread that started them ?
>
> Anyway, it's just a curiosity question :-) After spending a considerable
> time learning and reading about Lift ( I liked some of the non-traditional
> approaches that it takes to building web apps ) , my final conclusion was
> that Tapestry's component focused approach was superior ( I was quite
> surprised that despite being "view centric" Lift didn't have a way of
> coupling the snippet template and the snippet code into a cohesive
> component).
>
> Cheers - Alex K
>