[concurrency-interest] ForkJoinPool for async http calls?

Gregg Wonderly gregg at cytetech.com
Thu May 10 09:16:43 EDT 2012


On 5/10/2012 8:08 AM, Gregg Wonderly wrote:
> 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.

Looking over some of the spec and examples, I can see that doGet() is the path, 
if you tell the context/container that you do want to be async.  Sorry for the 
confusion for misspeaking out of ignorance here.  Thanks for the followup Mark 
to point me at actually reading the details.

Gregg


More information about the Concurrency-interest mailing list