Play 2 : play.libs.WS VS 3rd party client library for async processing

5
votes

My Java Play2 app is calling some external web services to get data through a synchronous 3rd party client library. For this app I need high traffic and scalability.

The play documentation says :

Cases when your code may block include: Using REST/WebService APIs through a 3rd party client library (ie, not using Play’s asynchronous WS API) [...]

Note that you may be tempted to therefore wrap your blocking code in Futures. This does not make it non blocking, it just means the blocking will happen in a different thread[...]

In contrast, the following types of IO do not block: The Play WS API, ...

In a Play2 Java app, it's not really useful to use promises to make things asynchronous because the default play pool is used for Futur tasks. As a result, using a lot of Futur will result as the same thing as using only synchronous calls with a large default thread pool : roughly same number of threads in the same pool.

So my questions are :

  • is the play.libs.WS API in the the Java API really asynchronous (not blocking any thread in the play default pool) ?
  • should I always use it rather than my 3rd party client library if I want high traffic and scalability
  • what is the thread pool used by play.libs.WS API and should I increase its size if my application do a lot a WS calls?
  • is there a way to be as async as the play.libs.WS API, by wrapping the 3rd party synchronous client in futures?

Thanks a lot

Loïc

1
playframeworkplayframework-2.0
Looking at the code, play.libs.WS seems to use the Netty pool (using a AsyncCompletionHandler<com.ning.http.client.Response>) Am I right? – Loic

1 Answers

1
votes

As Guillaume Bort said on the Play mailing list, play.libs.WS API "has its own thread-pool, managed by the AsyncHttp library itself, but since it uses NIO under the hood, it doesn't matter as it is basically really non-blocking."

So it should be used as often as possible.