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 <lance.j...@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" <lance.j...@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" <akoch...@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 <lance.j...@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" <akoch...@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 > >> > > > >> > > >> > > >
