> Just for info, with scala2.10 and the new futures will come the ability to
> separate execution contexts based on threadpools, thus allowing in theory
> separating HTTP threads from akka threads from jdbc threads etc...

> Pascal

> Le 8 oct. 2012 03:11, "James Roper" <jrop...@gmail.com> a écrit :

>> No you're right on this.  What we probably should do is have a few
>> different configuration profiles documented that a user can use.  Out of the
>> box, Play is tuned for async.  We should make it very easy for the user to
>> switch to a more traditional model, such as what most servlet containers
>> use, where there is one large (150 threads) thread pool that handles all
>> requests.

>> On Saturday, 6 October 2012 05:40:58 UTC+10, Ryan Means wrote:

>>> Due to the very reason of what James Roper mentioned in the amount of
>>> boiler plate code for Java we're staying completely non-async for now. Ended
>>> up following James Ward's blog on how to tune a Play 2 app for non-async
>>> (James works for Heroku)
>>> http://www.jamesward.com/2012/06/25/optimizing-play-2-for-database-dr....
>>> All of our data comes off an in-house rest service from our CRM that is
>>> sitting directly on a DB. As much as we would have liked to go async, the
>>> Java code was going to be extremely thick as even our webapp text (which we
>>> cache in memcached) comes out of our CRM. Over time, we will start migrating
>>> our slower methods (methods that don't return within 1 sec) to async.

>>> I would like to point out one very glaring issue that James Ward did not
>>> mention though - even though you've "tuned" the environment, as James Roper
>>> points out ALL requests are handed off to the Akka handler - from our
>>> testing - this appears to include static content! So say you have 20
>>> threads, and all 20 are blocked at the moment, then 1 thread finishes and
>>> sends the result to the browser - the browser loads the HTML and sends
>>> requests back to the play server to get the static content referenced in the
>>> dynamic html output from play.. well, now your simple static content
>>> requests may be blocked waiting on those blocking akka calls to finish
>>> before it can return your simple static content! We experienced this in our
>>> testing using firebug and gatling. We were noticing that while running a
>>> gatling instance against our blocking app, we could load pages (with a wait
>>> time) but then noticed that the static resources in firebug were also
>>> blocking instead of being immediately returned! To fix this, we ended up
>>> going to a front-end apache server so play only deals with dynamic content
>>> now. If you went' all async, you wouldn't have to worry about this as Play
>>> encourages you to do. Ultimately, it would be nice if Play had a separate
>>> akka thread pool for static content so you never would be at risk for this
>>> happening.

>>> If I'm wrong on any of this - please correct me! :-)

>>> On Thursday, October 4, 2012 5:42:47 PM UTC-5, James Roper wrote:

>>>> Hi Ben,

>>>> Sorry, I completely missed this message a month ago.

>>>> There's no strict rules here, multiple solutions will work well, and
>>>> it's very dependent on the profile of your app.

>>>> I don't have a video from the talk, there are keynote slides in the
>>>> github repository but there's not much in them.  I will probably be giving
>>>> this talk again in the not too distant future at a conference that does
>>>> record video, and it will go into more detail and I'll produce more
>>>> comprehensive notes for it, so you'll be able to see it then.

>>>> I think a good start is that anything that relies on third party
>>>> services should be asynchronous.  There's nothing worse than your app going
>>>> down because some other system completely outside of your control is not
>>>> responding and tying up all your applications threads while you try to make
>>>> calls on it.  Calls to internal systems in your company are also good to
>>>> make asynchronous, and I would always do that, means my services can't bring
>>>> each other down so easily.

>>>> When it comes to talking to databases, for simple lookups that are
>>>> entirely from indexes, then I'd say unless you have an asynchronous driver
>>>> for that database, then it's probably not necessary to do things
>>>> asynchronously.  The exception to this is if you need to make many database
>>>> calls per request, then doing them in parallel is a good idea.  If you've
>>>> got big queries, map reduces etc, then this may be good to do asynchronously
>>>> too.  And if you're doing lots of all of the above, then take a look at
>>>> Akka, because with Akka you will have a lot more control over how many
>>>> threads are devoted to doing what.  Klout did a great blog post about this:
>>>> http://corp.klout.com/blog/2012/10/scaling-the-klout-api-with-scala-a...

>>>> The final thing to be said, if you're doing Java, using promises or any
>>>> sort of async stuff has a huge boiler plate overhead, and this needs to be
>>>> considered, if your simplest code paths are just one anonymous class after
>>>> another, then you are making large maintainability/code readability trade
>>>> offs, and it might not be worth it.  If doing Scala on the other hand,
>>>> working with Promises is no harder than working with Options, and so from a
>>>> code perspective, as long as you're comfortable with the concepts of map and
>>>> flatmap, there's no disadvantage to using promises.

>>>> Cheers,

>>>> James

>>>> On Monday, 3 September 2012 07:43:00 UTC+10, Ben McCann wrote:

>>>>> Hi James,

>>>>> Do you happen to have a video or slides from that talk you gave?  I
>>>>> have a very poor understanding of what should be wrapped in a promise and
>>>>> the docs are quite anemic on the topic.  E.g. should all of my calls via the
>>>>> Mongo Jackson Mapper be wrapped in promises?  Or just external HTTP
>>>>> requests?  How long should an action take before it is recommended to wrap
>>>>> it in a promise?  Why not just wrap every single request in a promise?  I'm
>>>>> having a really hard time understanding what tradeoffs are in play here.

>>>>> Thanks,
>>>>> Ben

>>>>> On Thursday, August 30, 2012 11:10:33 PM UTC-7, James Roper wrote:

>>>>>> I think you've fundamentally misunderstood how promises work.  A
>>>>>> promise says "at some point in future, I promise I will make one of these
>>>>>> available."  In the case of the WS API, that is a WS.Response, ie
>>>>>> Promise<WS.Response>.  When returning an async response to Play, you want to
>>>>>> return a promise for a result, ie Promise<Result>.  You can convert a
>>>>>> Promise<WS.Response> to a Promise<Result> by calling the map function, which
>>>>>> accepts a function that takes a WS.Response and returns a Result.  This
>>>>>> isn't invoked immediately, it's invoked when the first promise makes the
>>>>>> WS.Response available.  You could map it to something else first if you
>>>>>> really wanted, and then map that thing to a promise, eg:

>>>>>> Promise<WS.Response> responsePromise = WS.url(...).get();
>>>>>> Promise<Foo> fooPromise = responsePromise.map(new Function<...> {
>>>>>> public apply(WS.Response response) { return Json.fromJson(response.asJson(),
>>>>>> Foo.class); }};
>>>>>> Promise<Result> resultPromise = responsePromise.map(new Function<...>
>>>>>> { public apply(Foo foo) { return Result(foo); }};
>>>>>> return async(resultPromise);

>>>>>> But that's a bit unnecessary, because you don't need the intermediate
>>>>>> fooPromise, you could put your code that converts to/from json in the first
>>>>>> map function.  This is also, if you were to call other libraries, where you
>>>>>> would put all that code.  If you want to do another async operation (eg two
>>>>>> WS calls), then you can use flatmap:

>>>>>> Promise<WS.Response> responsePromise = WS.url().get()...
>>>>>> Promise<WS.Response> secondResponsePromise =
>>>>>> responsePromise.flatMap(new Function<...> { public apply(WS.Response
>>>>>> response) { return WS.url(..).get(); }};
>>>>>> Promise<Result> resultPromise = secondResponsePromise.map(new
>>>>>> Function<...> { public apply(WS.Response response) { return Ok(...); }};

>>>>>> The thing to be aware, is once you start working with Promises, you
>>>>>> can never directly work with the result, everything gets done in map() and
>>>>>> flatMap().

>>>>>> There's a keynote presentation and example code here that I did for a
>>>>>> Play user group:

>>>>>> https://github.com/jroper/play-promise-presentation

>>>>>> On Friday, August 31, 2012 7:49:55 AM UTC+2, Steven Wong wrote:

>>>>>>> Ok I think I may have found the solution, posted at SOF

>>>>>>> http://stackoverflow.com/questions/12201047/play-2-async-webservice-c...

>>>>>>> On Friday, August 31, 2012 1:54:42 AM UTC+10, Steven Wong wrote:

>>>>>>>> I also have the same question. Especially when you have to perform
>>>>>>>> more actions on the result from the WS call before returning a result to the
>>>>>>>> user?

>>>>>>>> AsyncResult won't allow you to do that so you're left with blocking
>>>>>>>> the server.

>>>>>>>> On Tuesday, July 10, 2012 6:39:31 AM UTC+10, Aldrion wrote:

>>>>>>>>> Hi, my questions pertains to this exact problem Jonathan has
>>>>>>>>> introduced, but from a different angle and I haven't been able to find a
>>>>>>>>> solution (at least not of the kind that would enlighten me) online. Namely,
>>>>>>>>> while it is self-evident, how you get to a JsonNode (or any other data) in
>>>>>>>>> the second Jonathan's example, I can't seem to get my head around
>>>>>>>>> comprehending, how do you get a JsonNode or any other data out of the
>>>>>>>>> async() method through Java libraries? All the examples I have come across
>>>>>>>>> only deal with returning a Result with an ok() method.

>>>>>>>>> Using F.Promise's get() blocks the thread (or at least so I
>>>>>>>>> understand) and as such obviously negates one of the Play!'s fortes, while
>>>>>>>>> async() as per my understanding only takes Promise<Result> as an argument
>>>>>>>>> and returns AsyncResult exclusively, and neither Result nor AsyncResult seem
>>>>>>>>> to offer any usable method. Is there any way to collect/fetch data from
>>>>>>>>> Result or AsyncResult that I am not aware of? Or is there an altogether
>>>>>>>>> different way of tackling this?

>>>>>>>>> Any advise would be greatly appreciated...

>> --
>> You received this message because you are subscribed to the Google Groups
>> "play-framework" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/play-framework/-/IaItKa68ZWMJ.
>> To post to this group, send email to play-framework@googlegroups.com.
>> To unsubscribe from this group, send email to
>> play-framework+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/play-framework?hl=en.

> --
> You received this message because you are subscribed to the Google Groups
> "play-framework" group.
> To post to this group, send email to play-framework@googlegroups.com.
> To unsubscribe from this group, send email to
> play-framework+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/play-framework?hl=en.