The server side is done with php, but it should be very easy to port into java. Take a look on it, maybe it gives you some nice ideas :)

All feedback is greatly appreciated.

2. the nice thing about invokeAll is that you can limit the duration of invokeAll (for all calls), this is much harder with submit (I had submit before and could only getting by creating a thread pool each time and then force the pool to shutdown).

i know this is just test-code, but
i have one central question about it.

can one really use the outputstream of the response in a parallel manner?

on the other hand i found the use of
taskList.add(callable) in a loop and a subsequent executor.invokeAll(taskList) not looking too good, because the actual computation is deferred until the last piece is prepared.

we went for another solution where we did executor.submit(callable) and wait for the completition with the help of a Map with Future entries.

anyways. very interesting thoughts about splitting up the computation of page-content.

~fw

But Facebook hasn’t been very clear on this, also not in their examples.

Async: Yes, totally.

This was a proof of concept of the loading or parts.

In real life one should use a network of actors that either run on threads or “wait” async for data, then push data to the next actors and so on until the request is finished. This is what I would like to have going.

On a separate note, I think it would be specifically useful to combine this with completely non blocking web serving capabilities as in Tornado The two approaches could perhaps be structured to well complement each other.