CODEWITHSUNDEEP
scalaasynchronousplayframeworkfuture
Tomer
Tomer

Reputation: 2448

play - how to wrap a blocking code with futures

I am trying to understand the difference between the 2 methods, in terms of functionality. 

class MyService (blockService: BlockService){
   def doSomething1(): Future[Boolean] = {
       //do
       //some non blocking
       //stuff
       val result = blockService.block()
       Future.successful(result)
   }

   def doSomething2(): Future[Boolean] = {
       Future{
          //do
          //some non blocking
          //stuff
          blockService.block()
       }
   }
}

To my understanding the difference between the 2 is which thread is the actual thread that will be blocked.

So if there is a thread: thread_1 that execute something1, thread_1 will be the one that is blocked, while if a thread_1 executed something2a new thread will run it - thread_2, and thread_2 is the one to be blocked.

Is this true?

If so, than there is no really a preferred way to write this code? if I don't care which thread will eventually be blocked, then the end result will be the same. dosomething1 seems like a weird way to write this code, I would choose dosomething2.

Make sense?

Upvotes: 3

Views: 1423

Answers (4)

LoranceChen
LoranceChen

Reputation: 2574

Does BlockService handle blocking operation?
Normally, use blocking ,as @Andreas remind,to make blocking operation into another thread is meanful.

Upvotes: 0

marcospereira
marcospereira

Reputation: 12214

Yes, doSomething1 and doSomething2 blocks different threads, but depending on your scenario, this is an important decision.

As @AndreasNeumann said, you can have different execution contexts in doSomething2. Imagine that the main execution context is the one receiving HTTP requests from your users. Block threads in this context is bad because you can easily exhaust the execution context and impact requests that have nothing to do with doSomething.

Play docs have a better explanation about the possible problems with having blocking code:

If you plan to write blocking IO code, or code that could potentially do a lot of CPU intensive work, you need to know exactly which thread pool is bearing that workload, and you need to tune it accordingly. Doing blocking IO without taking this into account is likely to result in very poor performance from Play framework, for example, you may see only a few requests per second being handled, while CPU usage sits at 5%. In comparison, benchmarks on typical development hardware (eg, a MacBook Pro) have shown Play to be able to handle workloads in the hundreds or even thousands of requests per second without a sweat when tuned correctly.

In your case, both methods are being executed using Play default thread pool. I suggest you to take a look at the recommended best practices and see if you need a different execution context or not. I also suggest you to read Akka docs about Dispatchers and Futures to gain a better understanding about what executing Futures and have blocking/non-blocking code.

Upvotes: 3

Andreas Neumann
Andreas Neumann

Reputation: 10884

This approach makes sense if you make use of different execution contexts in the second method.

So having for example one for answering requests and another for blocking requests. So you would use the normal playExecutionContext to keep you application running and answering and separate blocking operation in a different one.

def doSomething2(): Future[Boolean] = Future{ 
    blocking { blockService.block() }
}( mySpecialExecutionContextForBlockingOperations )

For a little more information: http://docs.scala-lang.org/overviews/core/futures.html#blocking

Upvotes: 2

easel
easel

Reputation: 4048

You are correct. I don't see a point in doSomething1. It simply complicates the interface for the caller while not providing the benefits of an asynchronous API.

Upvotes: 1

Related Questions