Should you always use Action.async?

[Eric Nelson]

I recognize that this may seem like a simpleton question, but I'm a little confused about how Play! works in its controller layer. Some documentation states that Play! is always asynchronous and non-blocking. So I'm confused by Action vs Action.async. Is Action blocking? If so, and docs say that you should always stay asynchronous and non-blocking, then should you always use Action.async in all your controllers? Why would you choose not too? I'm sure there's something that I'm not understanding here, and any of your expertise would be greatly appreciated in understanding this.

[Fernando Correia]

I'm not an expert in Play, but the way I understand it, the framework itself is asynchronous; your controllers can be blocking or non-blocking. Notice that a non-blocking controller only produces an advantage if there is something to not block on. If it's straightforward code that just renders a view without external dependencies such as a database request, there will be nothing to wait on, so make it asynchronous would introduce unnecessary overhead.

[Jaap Taal]

You NEVER want to block in a play contoller, it WILL lead to thread starvation. Instead, wrap blocking code in a `Future {blockingFuncHere()`} and use an async controller. Furthermore wrap the actual blocking operation in `blocking {}`, if you don't the thread starvation will still occur. You can also choose to run blocking operations on a different thread pool. You can create threadpools with akka config.

The Future{blockingFunc()} takes an implicit ExecutionContext. Have an implicit var in your controller point to the specific akka threadpool. You can always pass it explicitly if needed (sometimes it's nice to know what's going on).

Jaao

[Saurabh Rawat]

Hi,

I seem to have misunderstood async in play as well. For all controller funcs talking to db I do :

Action.async { future { db fetch and render} }

Is that not enough? (this is pretty much what I understood from the docs)
 
What is this blocking construct? How does it compare to futures? What should I know?

Regards,

Saurabh Rawat

--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[kev83]

It seems by using Action, you already return a Future internally. Correct me if I'm mistaken, you use Action.async when you're working with and returning one or more futures. Otherwise, using Action is concise and correct.

  final def apply[A](bodyParser: BodyParser[A])(block: R[A] => Result): Action[A] = async(bodyParser) { req: R[A] =>
    block(req) match {
      case simple: SimpleResult => Future.successful(simple)
      case async: AsyncResult => async.unflatten
    }
  }

[Jan Niehusmann]

Please note that I have no experience with highly loaded play
applications. So my comments are mainly based on what I understood from
the documentation - which, of course, may be wrong for several reasons :-)

On Sat, Dec 14, 2013 at 12:55:11AM +0530, Saurabh Rawat wrote:
> Action.async { future { db fetch and render} }
>
> Is that not enough? (this is pretty much what I understood from the docs)

It depends on your thread pool configuration. If your thread pool is
large enough, and you don't have an large number of blocking
threads, this is fine.

If instead you have a thread pool with a rather small number of allowed
threads, and have a lot of blocking calls, then it may be necessary to
use a blocking { } statement.

> What is this blocking construct? How does it compare to futures? What
> should I know?

The blocking statement is described as "Used to designate a piece of
code which potentially blocks, allowing the current BlockContext to
adjust the runtime's behavior. Properly marking blocking code may
improve performance or avoid deadlocks."
(http://www.scala-lang.org/api/current/#scala.concurrent.package)

That's probably not very helpful, but the details depend on the
current ExecutionContext.

It's probably safe to just assume that using that statement allows the
execution context to allocate one additional thread.

As the default execution context has a single thread per CPU core, you
want to use additional threads if some are blocking. You can do that
either by configuring your thread pool, or by using the blocking
statement.

More details can be found here:
http://www.playframework.com/documentation/2.2.1/ThreadPools

For database connections, that page gives the following advice:
"Given the fact that JDBC is blocking thread pools can be sized to the #
of connections available to a db pool assuming that the thread pool is
used exclusively for database access."

As I understand it, this advice is only valid if you have a dedicated
thread pool for your database work. Otherwise, your application will
stall once all database connections are in use. Which may be acceptable in
case your application can't do any work without database access, anyhow.

Regards,
Jan

[Fernando Correia]

I recommend watching the Optimizing Play for Production webcast, specially at 15m22s where there is an explanation about async:

http://www.youtube.com/watch?v=cnPPLpIk9mo&feature=youtu.be&t=15m22s

[Christopher Hunt]

As has been pointed out, actions are always executed in their own executor. As a convenience we assume that you are not dealing with futures within your action block, and we wrap the result with a completed future. If you are dealing with futures (such as calling wS), then to return a future result you use .async.

HTH
Christopher

[Saurabh Rawat]

Hi,

Thanks Jan for the explanation, thanks Fernando for the webinar link.

In the webinar James Ward says that we should use Actors for things like talking to the database. In the example he is using a WS call which is nonblocking. If I were to do a db fetch while processing a message inside an actor, would I wrap it inside a future? Because from what I understand I should not have a blocking call inside an actor.

Now what I am confused about is, if I am making a future inside the actor anyway, why not make a future right there in the controller def-
           Action.async {
              future {
                blocking call

              } map {
                send response
              }

           }

Why create another level of indirection, what do I gain from that?

Regards,

Saurabh Rawat

Christopher

[James Ward]

Putting the blocking DB call inside an Actor provides a nice clean model
for handling timeouts & failures, setting up blocking execution
contexts, and managing any state that may be associated with the
service. Also Actors provide some nice patterns like the
ScatterGatherFirstCompletedRouter to address simultaneous cache & db
requests. But an Actor may be overkill depending on what you need.

-James

On 12/15/2013 04:51 AM, Saurabh Rawat wrote:
> Hi,
>
> Thanks Jan for the explanation, thanks Fernando for the webinar link.
>
> In the webinar James Ward says that we should use Actors for things like
> talking to the database. In the example he is using a WS call which is
> nonblocking. If I were to do a db fetch while processing a message
> inside an actor, would I wrap it inside a future? Because from what I
> understand I should not have a blocking call inside an actor.
>
> Now what I am confused about is, if I am making a future inside the
> actor anyway, why not make a future right there in the controller def-
> Action.async {
> future {
> blocking call
> } map {
> send response
> }
> }
>
> Why create another level of indirection, what do I gain from that?
>
> Regards,
>
> Saurabh Rawat
>
>
> On Sun, Dec 15, 2013 at 3:43 AM, Christopher Hunt

> <christop...@typesafe.com <mailto:christop...@typesafe.com>>

> wrote:
>
> As has been pointed out, actions are always executed in their own
> executor. As a convenience we assume that you are not dealing with
> futures within your action block, and we wrap the result with a
> completed future. If you are dealing with futures (such as calling
> wS), then to return a future result you use .async.
>
> HTH
> Christopher
>
> --
> You received this message because you are subscribed to the Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to play-framewor...@googlegroups.com

> <mailto:play-framework%2Bunsu...@googlegroups.com>.

[Jaap Taal]

Roland Kuhn is teaching never to block in an actor, you probably want to take his advice!

Jaap Taal
 
[ Q42 | tel 070 44523 42 | direct 070 44523 65 | http://q42.nl | Waldorpstraat 17F, Den Haag | Oostelijke Handelskade 749, Amsterdam | KvK 30164662 ]

On Sun, Dec 15, 2013 at 7:21 PM, James Ward <james...@typesafe.com> wrote:

Putting the blocking DB call inside an Actor provides a nice clean model for handling timeouts & failures, setting up blocking execution contexts, and managing any state that may be associated with the service.  Also Actors provide some nice patterns like the ScatterGatherFirstCompletedRouter to address simultaneous cache & db requests.  But an Actor may be overkill depending on what you need.

-James

On 12/15/2013 04:51 AM, Saurabh Rawat wrote:

Hi,

Thanks Jan for the explanation, thanks Fernando for the webinar link.

In the webinar James Ward says that we should use Actors for things like
talking to the database. In the example he is using a WS call which is
nonblocking. If I were to do a db fetch while processing a message
inside an actor, would I wrap it inside a future? Because from what I
understand I should not have a blocking call inside an actor.

Now what I am confused about is, if I am making a future inside the
actor anyway, why not make a future right there in the controller def-
            Action.async {
               future {
                 blocking call
               } map {
                 send response
               }
            }

Why create another level of indirection, what do I gain from that?

Regards,

Saurabh Rawat


On Sun, Dec 15, 2013 at 3:43 AM, Christopher Hunt

<christop...@typesafe.com <mailto:christopher.hunt@typesafe.com>>

wrote:

    As has been pointed out, actions are always executed in their own
    executor. As a convenience we assume that you are not dealing with
    futures within your action block, and we wrap the result with a
    completed future. If you are dealing with futures (such as calling
    wS), then to return a future result you use .async.

    HTH
    Christopher

    --
    You received this message because you are subscribed to the Google
    Groups "play-framework" group.
    To unsubscribe from this group and stop receiving emails from it,

    send an email to play-framework+unsubscribe@googlegroups.com

    <mailto:play-framework%2Bunsu...@googlegroups.com>.

    For more options, visit https://groups.google.com/groups/opt_out.


--
You received this message because you are subscribed to the Google
Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to play-framework+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/WWQ0HeLDOjg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framework+unsubscribe@googlegroups.com.

[James Ward]

That is ideal but there are times when it can't be avoided, like JDBC
calls, CPU intensive operations, etc.

On 12/15/2013 01:32 PM, Jaap Taal wrote:
> Roland Kuhn is teaching never to block in an actor, you probably want to
> take his advice!
>
> Jaap Taal
>
> [ Q42 | tel 070 44523 42 | direct 070 44523 65 | http://q42.nl |
> Waldorpstraat 17F, Den Haag | Oostelijke Handelskade 749, Amsterdam |
> KvK 30164662 ]
>
>
> On Sun, Dec 15, 2013 at 7:21 PM, James Ward <james...@typesafe.com
> <mailto:james...@typesafe.com>> wrote:
>
> Putting the blocking DB call inside an Actor provides a nice clean
> model for handling timeouts & failures, setting up blocking
> execution contexts, and managing any state that may be associated
> with the service. Also Actors provide some nice patterns like the

> ScatterGatherFirstCompletedRou__ter to address simultaneous cache &

> <mailto:christop...@typesafe.com>
> <mailto:christopher.hunt@__typesafe.com
> <mailto:christop...@typesafe.com>>>

>
> wrote:
>
> As has been pointed out, actions are always executed in
> their own
> executor. As a convenience we assume that you are not
> dealing with
> futures within your action block, and we wrap the result with a
> completed future. If you are dealing with futures (such as
> calling
> wS), then to return a future result you use .async.
>
> HTH
> Christopher
>
> --
> You received this message because you are subscribed to the
> Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails
> from it,
> send an email to

> play-framework+unsubscribe@__googlegroups.com
> <mailto:play-framework%2Bunsu...@googlegroups.com>
> <mailto:play-framework%__2Buns...@googlegroups.com
> <mailto:play-framework%252Buns...@googlegroups.com>__>.
>
> For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails from
> it, send

> an email to play-framework+unsubscribe@__googlegroups.com

> <mailto:play-framework%2Bunsu...@googlegroups.com>.
> For more options, visit

> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
> --
> You received this message because you are subscribed to a topic in
> the Google Groups "play-framework" group.
> To unsubscribe from this topic, visit

> https://groups.google.com/d/__topic/play-framework/__WWQ0HeLDOjg/unsubscribe
> <https://groups.google.com/d/topic/play-framework/WWQ0HeLDOjg/unsubscribe>.

> To unsubscribe from this group and all its topics, send an email to

> play-framework+unsubscribe@__googlegroups.com
> <mailto:play-framework%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
> --
> You received this message because you are subscribed to the Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to play-framewor...@googlegroups.com.

[Christopher Hunt]

…and Java's stream library. Here's an example where actors are used in conjunction with blocking operations. The idea is that you configure the associated dispatchers to handle larger amounts of concurrently blocked threads:

https://github.com/typesafehub/js-engine/blob/master/src/main/scala/akka/contrib/process/BlockingProcess.scala

Kind regards,

Christopher

On 16/12/2013, at 2:51 PM, James Ward <james...@typesafe.com> wrote:

That is ideal but there are times when it can't be avoided, like JDBC calls, CPU intensive operations, etc.

On 12/15/2013 01:32 PM, Jaap Taal wrote:

Roland Kuhn is teaching never to block in an actor, you probably want to
take his advice!

-- 
Christopher Hunt
Senior Engineer
Typesafe – Build Reactive Apps on the JVM!

Twitter: @huntchr

[Saurabh Rawat]

Hi,

Thnaks James for the explanation. At this point the take away seems to be that if you are dealing with a blocking api, you will just have to allocate a separate thread-pool for it. There is just no going around it and somebody needs to block somewhere.

I have decided my use case is just too simple for actors to make sense.

Am I correct in understanding that for a db heavy app, my per second throughput on a given machine will be limited by my db thread-pool?

Regards,

Saurabh Rawat

[Christopher Hunt]

Have you seen this resource:

http://www.playframework.com/documentation/2.1.0/ThreadPools

You received this message because you are subscribed to a topic in the Google Groups "play-framework" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/play-framework/WWQ0HeLDOjg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to play-framewor...@googlegroups.com.

[Saurabh Rawat]

Hi,

Christopher, the doc seems to agree with what I said above (please correct me if that is not the case), thanks :)

So I guess it is going to be db bound (db thread-pool bound)?

Regards,

Saurabh Rawat

[Eric Nelson]

James, your replies are greatly appreciated. I think I'm finally wrapping my head around the Action.async stuff, and why it's there. It's not that Action is a blocking call, as the result of any action is wrapped into a Future under the covers. But if within the action I'm making a call to a service that returns a future itself, then Action.async simply allows you to compose that future into the Result, instead of blocking on that future to extract the value before creating the Result. (I hope that made sense).

--Eric

[James Ward]

Yeah, it sounds like you are doing it right. If a controller method can
be non-blocking (using a Future) then you should definitely use
Action.async instead of just an Action (i.e. Action.apply).

-James

> > <christop...@typesafe.com <javascript:>
> <mailto:christop...@typesafe.com <javascript:>>>

> > wrote:
> >
> > As has been pointed out, actions are always executed in their
> own
> > executor. As a convenience we assume that you are not dealing
> with
> > futures within your action block, and we wrap the result with a
> > completed future. If you are dealing with futures (such as
> calling
> > wS), then to return a future result you use .async.
> >
> > HTH
> > Christopher
> >
> > --
> > You received this message because you are subscribed to the
> Google
> > Groups "play-framework" group.
> > To unsubscribe from this group and stop receiving emails from
> it,

> > send an email to play-framewor...@googlegroups.com <javascript:>
> > <mailto:play-framework%2Bunsu...@googlegroups.com
> <javascript:>>.

> > For more options, visit
> https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

> >
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "play-framework" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send

> > an email to play-framewor...@googlegroups.com <javascript:>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.

[James Roper]

This message that I wrote to the dev mailing list a year ago on Play's architecture should answer some of the questions and clear up some of the misunderstandings here:

https://groups.google.com/d/msg/play-framework-dev/30MqnKDp0Fs/25PU-Y0RhGoJ

On whether you should block in actors - one of the reasons for having configurable dispatchers for actors is to allow blocking - specifically, to manage the resources consumed while blocking.  Never blocking in an actor - or in a Play action - is an ideal that only works if all the APIs that you talk to don't block.  For example, if you have a business requirement to use Oracle, then unless you want to reverse engineer Oracles proprietary protocol (probably violating patents/copyright in the process) and write your own asynchronous driver (which if you did do that, you should probably be fired for wasting your time), you have to use JDBC, which is blocking.  Because you have to block, and because Akka provides you the facilities to manage this blocking, you would be crazy *not* to do the blocking in an actor.  And I'm sure Roland would agree with me on that.  The trick is to understand exactly where you are blocking, understand how your dispatchers are configured, and the consequences of different configurations.  Limit the actor or actor pool (typically you might do this with a set of actors behind a router) that does blocking to only do blocking, and move any logic that doesn't require blocking to other actors.

Here's a more concrete example, I am currently writing a blog engine that uses git for storing blog entries.  The library I'm using to talk to git - jgit - is blocking.  I'm not going to write my own async git library implementation, so I'm forced to use jgit and block.  So, I put all the blocking calls that talk to git in one actor, here:

https://github.com/jroper/erqx/blob/master/app/au/id/jazzy/erqx/engine/actors/FileLoader.scala

Then in the main actor that manages the blog, I have a router that delegates to 10 instances of this actor, and uses a particular dispatcher (thread pool):

https://github.com/jroper/erqx/blob/master/app/au/id/jazzy/erqx/engine/actors/BlogActor.scala#L44

So that means I can be concurrently reading up to 10 files from git at a time.  Then, I have the dispatcher configured to have 10 threads:

https://github.com/jroper/erqx/blob/master/samples/minimal/conf/application.conf#L9

Since I'm using a specific dispatcher just for the git loading, once all its threads are tied up, the rest of my actor system is still responsive and able to handle messages, it's only the git file loading that's blocked.  The blog actor can still return cached indexes of blog posts for example, even if the file loaders are all overloaded, because it is using the default dispatcher, not the one used by the loaders, and I've been very careful to ensure that on the default dispatcher no blocking is done, ever.

an email to play-framework+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--

James Roper
Software Engineer

Typesafe – Build reactive apps!
Twitter: @jroper

[Saurabh Rawat]

Thanks James,

I think I finally understand, I thought I would use a different dispatcher for db access futures and give them a separate thread-pool. I thought in a db bound app I would just stop serving when the db pool was completely blocked, but using actors to still accept requests might improve throughput (I hope).

Thanks for your explanation, all of my doubts are cleared.

Regards,

Saurabh Rawat

p.s. Sorry Eric Nelson for hijacking your thread :P

To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

[James Ward]

In this case you probably won't get any better throughput for the
requests that talk to the db. If you can only make 100 db calls per
second then it doesn't matter how many incoming requests you can handle;
the max number of requests per second will never be more than 100
(assuming one db request per web request). Unless you have spikes that
build a backlog of pending requests which can eventually be depleted.

As James Roper says, by putting the blocking db stuff into actors you
can easily create a dedicated thread pool that will help keep the rest
of the system responsive.

I hope that helps.

-James

> ScatterGatherFirstCompletedRou__ter to address

> <mailto:christop...@typesafe.com> <javascript:>
> <mailto:christop...@typesafe.__com

> play-framewor...@googlegroups.__com
> <mailto:play-framewor...@googlegroups.com> <javascript:>
> >
> <mailto:play-framework%__2Buns...@googlegroups.com
> <mailto:play-framework%252Buns...@googlegroups.com>

> <javascript:>>.
>
> > For more options, visit

> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>
> <https://groups.google.com/__groups/opt_out

> <https://groups.google.com/groups/opt_out>>.
>
> >
> >
> > --
> > You received this message because you are subscribed
> to the Google
> > Groups "play-framework" group.
> > To unsubscribe from this group and stop receiving
> emails from it,
> send

> > an email to play-framewor...@googlegroups.__com
> <mailto:play-framewor...@googlegroups.com> <javascript:>.
>
> > For more options, visit
> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>
> <https://groups.google.com/__groups/opt_out

> <https://groups.google.com/groups/opt_out>>.
>
>
> --
> You received this message because you are subscribed to the
> Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails
> from it, send

> an email to play-framework+unsubscribe@__googlegroups.com
> <mailto:play-framework%2Bunsu...@googlegroups.com>.
> For more options, visit
> https://groups.google.com/__groups/opt_out

> <https://groups.google.com/groups/opt_out>.
>
>
> --
> You received this message because you are subscribed to the
> Google Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to

> play-framework+unsubscribe@__googlegroups.com
> <mailto:play-framework%2Bunsu...@googlegroups.com>.
> For more options, visit

> https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.
>
>
>
>
> --

> *James Roper*
> /Software Engineer/
> /
> /
> Typesafe <http://typesafe.com/> � Build reactive apps!
> Twitter: @jroper <https://twitter.com/jroper>

>
> --
> You received this message because you are subscribed to the Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to play-framewor...@googlegroups.com

> <mailto:play-framework%2Bunsu...@googlegroups.com>.

> For more options, visit https://groups.google.com/groups/opt_out.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "play-framework" group.
> To unsubscribe from this group and stop receiving emails from it, send

[Christopher Hunt]

An example for you:

https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/play-scala/app/controllers/Application.scala

On 18/12/2013, at 5:16 PM, James Ward <james...@typesafe.com> wrote:

In this case you probably won't get any better throughput for the requests that talk to the db.  If you can only make 100 db calls per second then it doesn't matter how many incoming requests you can handle; the max number of requests per second will never be more than 100 (assuming one db request per web request).  Unless you have spikes that build a backlog of pending requests which can eventually be depleted.

As James Roper says, by putting the blocking db stuff into actors you can easily create a dedicated thread pool that will help keep the rest of the system responsive.

I hope that helps.

[Saurabh Rawat]

Hi James,

I was talking about the "eventually serves" scenario only. Thanks to you, James Roper and Christopher I understand now that the performance per second will be db pool bound (like I mentioned in a reply above) which should be a separate pool than the play default pool or I could just configure more threads in play pool. But I think separate pools would be better, yes? (if there is no front-end http server and play is serving static resources as well, less context switching)

Thanks.

Regards,

Saurabh Rawat

[Fernando Correia]

I've learned a lot from this thread. Thanks to all who contributed to it.

I think some of these concepts are not easily discoverable in the documentation. Specially, it seems to me that it takes some time to understand that Actions are async by default.

I've created an issue requesting that someone who is knowledgeable about this improve the documentation to clarify that:

https://github.com/playframework/playframework/issues/2187

[Michael Azerhad]

Hi James, 

Despite the advantage of Akka actors like timeouts & failures, setting up blocking execution contexts, and managing any state that may be associated with the service, etc..

Why not use futures instead of actors in case of blocking DB calls?

Indeed, I read this article and this is pretty convincing that when dealing with concurrency (not states), futures is far more better than actors:

http://www.chrisstucchio.com/blog/2013/actors_vs_futures.html

Is there really the need for Akka actors?

Thanks a lot,

Michael

     >     <mailto:play-framework%2Bunsubscr...@googlegroups.com

    <javascript:>>.

     >     For more options, visit
    https://groups.google.com/groups/opt_out

    <https://groups.google.com/groups/opt_out>.

     >
     >
     > --
     > You received this message because you are subscribed to the Google
     > Groups "play-framework" group.
     > To unsubscribe from this group and stop receiving emails from it,
    send

     > an email to play-framewor...@googlegroups.com <javascript:>.

     > For more options, visit https://groups.google.com/groups/opt_out

    <https://groups.google.com/groups/opt_out>.

--
You received this message because you are subscribed to the Google
Groups "play-framework" group.
To unsubscribe from this group and stop receiving emails from it, send

an email to play-framewor...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "play-framework" group.

To unsubscribe from this group and stop receiving emails from it, send an email to play-framewor...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Rahul Gulabani]

Hello,

I have read the post and conclude that Action.apply is as async as Action.asnc. but following link is confusing .

http://stackoverflow.com/questions/23647080/difference-between-action-and-action-async

As per this link it shows Action.apply was blocked but async was return to play thread pool.So it makes Action.Async non blocking whether or not blocking call is present.Also if Action.apply is async then why we need to open another thread on blocking JDBC call.Whole thing is very confusing cause of link mentioned above.


Br/
Rahul

[Greg Methvin]

Hi Rahul,

The main difference is that Action.async is designed to be used with async APIs (using Future). With Action.apply, the computation will happen in Play's default thread pool, which is meant to be used for CPU-bound operations. With Action.async, you have control over where that code is executing.

There are basically two cases where you'd use Action.async. Either you're using some other API that returns a Future (like the WS API), or you want to explicitly execute something in another ExecutionContext, for example a blocking database operation. You can read more about using alternate ExecutionContexts in the thread pools documentation: https://www.playframework.com/documentation/2.5.x/ThreadPools

Rahul

--
You received this message because you are subscribed to the Google Groups "Play Framework" group.
To unsubscribe from this group and stop receiving emails from it, send an email to play-framework+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/play-framework/b56b7064-bb07-46c9-9efa-92160e629036%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Greg Methvin

Tech Lead - Play Framework

Lightbend, Inc.