问题
I'm trying to understand conceptually why in Play Framework 2.0, it is considered a best practice to call WS.url().get() for web service calls, but if you wrap any other blocking call such as a JDBC call in a promise, you are advised to do it in an execution context other than the default execution context?
I understand that, by default, Play Framework's thread pools are configured so that you have one thread per core, and every controller expects to run completely non-blocking code. For this reason, if you make a blocking call in a controller -- say, to a web service --, then you want to make sure this call does not hold up the threads that are available for your controllers.
Otherwise, there will be no threads left to execute controllers because they're all waiting around in a blocking state.
But what confuses me are the following collection of points:
- First, what thread pool does the controller code itself execute in? Is this the default execution context?
- Second, on the one hand I understand that
WS.url().get()also executes in the default execution context, yet on the other hand, the Play Framework Documentation on Thread Pool Configuration states that "Note that you may be tempted to ... wrap your blocking code in Futures. This does not make it non blocking, it just means the blocking will happen in a different thread."
Doesn't the above mean that WS.url().get() is "just happening in different thread" in the same default execution context? What is different about having a JDBC call execute in a different execution context?
回答1:
1) Play controller functions are executed within Play's default thread pool, as explained in the linked docs:
Play default thread pool - This is the default thread pool in which all application code in Play Framework is executed. It is an Akka dispatcher, and can be configured by configuring Akka, described below. By default, it has one thread per processor.
Hence, you want to be very careful about blocking within controller functions, as that will block a thread in the default thread pool.
2) Play web services is a non-blocking API, so it does not block it's ExecutionContext. Therefore, you can make several WS calls within controller functions, without blocking the default thread pool. The main difference between a WS call and JDBC call is that a WS call will not block a thread while waiting for the response from the remote server, the calls are made asynchronously. A JDBC call (like most java IO) will block on it's thread while waiting for a response.
Executing a JDBC call within a different ExecutionContext will free up the default ExecutionContext to do other work, therefore allowing your server to process more requests. You can let Akka handle the hard work of context switching for you. While the JDBC calls are still blocking a thread, they're at least not blocking the threads that handle requests.
来源：https://stackoverflow.com/questions/25579630/understanding-the-difference-between-non-blocking-web-service-calls-vs-non-block