Interesting article. I have been using Gauva's ListenableFuture for a while but had not considered this:
An important attribute of this flow is that when blocking calls return, their processing is returned to the originating computation thread, thus not requiring an additional context switch to resume processing
It would be interesting to setup a comparison of timings between the two alternatives.
This article seems to indicate maybe there is some common ground in the way Ratpack works: http://blog.anacoders.com/blocking-code-in-ratpack/
Ratpack Video from Nov 2015
Looking at the slides and I am not sure if the single thread per cpu model is exactly the path that should be taken for the places i have been using ListenableFuture.
I have been using Listenable Future for situations where we have a large blocking request (jdbc call) that can be broken down into many calls, or in the case where many calls can be submitted at once instead of one after the other.
For blocking IO, Subramanium defines the formula as
http://baddotrobot.com/blog/2013/06/01/optimum-number-of-threads/
Not sure how the single thread per CPU design is going to take advantage of this in Ratpack. If all it's doing is delegating to ListenableFuture than i will probably go on using ListenableFuture itself.
From the anacoders article:
The blocking executor is a ListeningExecutorService and when your blocking code is submitted to it by Ratpack for execution it will execute it on one of its threads from its pool and return a ListenableFuture. ListenableFuture allow you to register call-backs with them and specify what executor service to use to run the call-back when the ListenableFuture (the blocking code) completes. Ratpack adds an "onSuccess" call-back that will execute back on the main executor and allow the original request to complete. More info on ListenableFuture can be found here.
No comments:
Post a Comment