[concurrency-interest] ForkJoinPool for async http calls?

Gregg Wonderly gregg at cytetech.com
Thu May 10 09:08:40 EDT 2012

On 5/10/2012 7:48 AM, Mark Thornton wrote:
> On 10/05/12 13:31, Gregg Wonderly wrote:
>> On 5/10/2012 7:12 AM, Christian Essl wrote:
>>> Hi Viktor,
>>> Thanks for your answer, and thanks for your patient discussion outside
>>> of the mailing-list.
>>> As said I like the akka-framework, still it would be very nice if
>>> anybody could answer my original question whether ForkJoinTasks can
>>> give a sort of non-blocking future also suitable for async IO, because
>>> I am stil not sure.
>> I believe that ForkJoin was designed specifically for managing non-blocking,
>> compute bound tasks. Primarily, this issue of "partial failure" in the form of
>> I/O failures really complicates things. Practically, you'd like for your I/O
>> to be linearly consistent, so a ForkJoin task, would need to do all the I/O
>> for a particular "operation" itself.
>> Inside of a Servlet container, you really shouldn't be mucking about with
>> threading, related to the request completion. If you have other services to
>> interact with, they should be done within a linear progression of code inside
>> of the doGet, doPut, doPost etc methods.
>> The thread which calls doGet/doPost is, already, from a pool which the
>> container is managing in some way. Adding another thread to the mix, to
>> perform some work, would require the calling thread to block and wait for it
>> to complete anyway, so why not just have the calling thread do that work?
> Not if you use the async support in the latest Servlet specification.

In his example code, I see the use of just doGet().  I have not used the 
async-http support from JSR-315, but I thought that doGet() was not the path for 
using that.  If he's really using the async support from the servlet container, 
then he still, does have the issue with the server thread pooling, and 
synchronization with that call/report structure, but could inject a ForkJoin 
pool I suppose, but might find limited "returns" on that depending on how the 
CPU cores area already loaded from the servlet handling inbound requests.

 From a general perspective, I expect the use of the Fork/Join pool to load the 
CPUs and create quite a bit of latency issues for non-compute requests on a 
loaded server.

Gregg Wonderly

More information about the Concurrency-interest mailing list