Updating this thread for future googlability. See this example for
executing work in parallel whilst rendering
http://t5stitch-lazan.rhcloud.com/paralleldemo
On Thu, 06 Nov 2014 14:17:04 -0200, Howard Lewis Ship
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 (& controlle
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
On Thu, 06 Nov 2014 00:58:51 -0200, Alex Kotchnev
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 be
This will get you started
https://gist.github.com/uklance/88c9a5400872273d9b14
On 6 Nov 2014 03:01, "Alex Kotchnev" 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
>
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 spec
FYI I've worked out a very simple / no frills way to do this.
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
Hello, Alex!
On Tue, 04 Nov 2014 21:23:10 -0200, Alex Kotchnev
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 (m
On Tue, 04 Nov 2014 20:30:30 -0200, Lance Java
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 t
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 th
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
fr
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" wrote:
> I'd argue that t
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 t
On Tue, Nov 4, 2014 at 1:51 PM, Alex Kotchnev 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
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 ha
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
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
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
18 matches
Mail list logo
