When you want to retrieve data from a different server, your web application behaves like a web client. Rather than serving a resource to a client, it requests one from a different server. For example, that’s what you would do if you want to interact with the Twitter API or if you want to build a web based feed reader.

HTTP Client Calls in Play 1.0

Play has a pretty cool http client library – pretty cool in the sense that it’s very simple to use compared to what you usually get in Java. I can get the content of a resource by calling:

[java]
String body = WS.url(“http://erwan.jp/”).get().getString();
[/java]

In the same fashion, I can do a post and retrieve the JSON result:

[java]
JsonElement response = WS.url(“http://api.server.tld/new”).body(“content”).post().getJson();
[/java]

As a comparison, see how it works with Apache HttpClient.

However there’s a big flaw in this API: it can only be used synchronously. That means that your Java thread will be blocked until the response from the server is received. Depending on the server it could take several seconds, so it is a real issue. If you need to do 5 calls then work on the result, you will have to wait for the previous call to be done before you can launch the second. In Play you can use jobs to have your calls executed in a separate thread, but it’s a burder to have to create jobs for that and kind of defeats the purpose of using play.libs.WS.

Play 1.1: Introducing Asynchronous Calls

Since a commit I did last week, additional methods are available on the request object. Now you can do:

[java]
Future<HttpResponse> response = WS.url(“http://erwan.jp/”).getAsync();
[/java]

Now your call is done in a thread – you can manipulate your Future object to test if the result is available, to cancel the call or to block the thread until the result is ready. Let’s say you need to do 3 API calls, and then use the results together. With the synchronous library you have to serialize the calls, but now you can do the calls in parallel:

[java]
// Launch all three calls in parallel
Future<HttpResponse> future1 = WS.url(“http://server/api/one”).getAsync();
Future<HttpResponse> future2 = WS.url(“http://server/api/two”).getAsync();
Future<HttpResponse> future3 = WS.url(“http://server/api/three”).getAsync();
// Now that the calls are launched in separate threads, wait for the results
Document xml1 = future1.get().getXml();
Document xml2 = future2.get().getXml();
Document xml3 = future3.get().getXml();
[/java]

Launch the calls in parallel means a much quicker response, so that’s an improvement in the case we have several calls to do. But we are still blocking one of Play’s threads until the three calls are done.

Avoid blocking Play’s threads

Before we go on, it’s important to understand Play’s threads pool. It’s configurable but usually there is one IO thread and 2 execution threads. When the IO thread gets a request it passes it to one of the execution thread, the execution thread calculates it and passes it back to the IO thread that will queue it to serve it to the client who originated the request.

That means that the execution of the action on the controller will block one thread. So if you do a synchronous web service call from your action, you’ll block a precious thread for all the time you wait for the remote server to respond to your server. When all threads are blocked waiting for a result, other requests get queued. Your site’s response is slow, and your users are unhappy.

So here is how you can free the thread while you wait for the remote server to respond. The following code is an action, within a controller:

[java]
private static Future response;
public static void mirrorFeed() throws Exception {
if (request.isNew) {
response = WS.url(“http://planet.playframework.org/feed”).getAsync();
waitFor(response);
} else {
renderXml(response.get().getXml());
}
}
[/java]

This can be tricky to understand at a first glance, so here is the process.

• Your action gets called a first time: request.isNew is true. An asynchronous HTTP call is made to the playframework.org server.
• The “waitFor(Future)” (static method on the Controller class) tells Play to wait until the response is received.
• When the answer is ready, Play will call the action again. This time, request.isNew is false. We know that the Future is ready so we can do a get() to retrieve the HttpResponse instance. Here we’re just serving it to the user, but you see how we could parse the feed to use just some information in our response.

So here you go: the use of an asynchronous call prevents to block an execution thread, and the performance of your application will not be affected by the response time of the remote server.

When you should still use a job

While the waitFor trick prevents you from blocking a Play thread, your user still has to wait for the web service call to be back before he gets his response. In other words, your application may feel slow to the user.

When the information you need is general enough, for example when it comes from a public feed, it can still be a better approach to keep the information up-to-date using a job. At the time the user will fetch the information it will not be the most recent, but the page will be served to the user much quicker.

This is what I am doing for the Twitter box on Planet Play: I don’t pull it for each visitor at request time (that would be insane), but I have a Job refreshing the information every 5 minutes. Any page rendered will never get anything older than 5 minutes.

[java]
@Every(“5mn”)
public class TwitterJob extends Job {
public void doJob() {
try {
TwitterSearch.refresh(“playframework”);
} catch (UnsupportedEncodingException e) {
Logger.error(“Error refreshing Twitter search”);
}
}
}
[/java]

The information is then stored in cache and retrieved to render the front page.

Play Tests in Eclipse

The obvious next step would be that, in case of a failure typically, links from the page brings you directly to your code at the correct line. That would be also very useful for error pages, just like Guillaume did in his Textmate integration. So I did some research, what is it possible to do with Eclipse?

I found a very old bug, opened in 2001, to support opening files directly from the command line. After nearly 10 years the bug is finally fixed: it’s in the not-yet-released 3.6 version of Eclipse. It’s such a basic feature it’s surprising they couldn’t do it earlier, but at least they eventually did it. So with a nightly build of Eclipse, you can open files like this:

eclipse -name Eclipse --launcher.openFile <qualified file name>

That’s the most important piece already in place, so it’s good news. But that’s not enough. To jump right to the error, you need to be able to open the file at a given line number. You don’t want to have to search in your code for the line responsible for the error. So I opened bug 305336. Looking at the patch for bug 4922, adding the line number seems trivial to do. I’ll probably submit a patch and cross my fingers to have it in 3.6 before it’s released.

The last piece we would need is Eclipse registering itself as a protocol handler. That would allow us to insert URLs such as:

eclipse://open?url=file://<qualified file name>

Again, I opened a bug (#305345). It’s not as critical as the other items because this one can be created manually. For Windows there’s a key to add to the registry, for Gnome it’s a key in gconf and for OSX I’m sure there is something similar. Of course, it would be better if it Eclipse registered itself so the user won’t have to mess with his registry.

Note that, just like EC2, it’s not free hosting – you have to pay for it. But they have fairly reasonable prices.

1. Create a server on Gandi

Make sure you choose a solution that gives you root access to the machine, “expert mode”. In the rest I’ll assume you choose Ubuntu, but any distribution would work.

2. Install the Requirements

ssh to your server, and su to get root access. Now:

apt-get install openjdk-6-jre unzip

See how fast is the download, I bet they have a local proxy!

3. Download Play

exit to get back to regular user mode, then:

wget http://download.playframework.org/releases/play-1.0.1.zip
unzip play-1.0.1

4. Run It!

Now you’re ready to run your app! Copy your app to your server by using scp for example, switch to to prod mode and you can run:

play start yourAppFolder

That’s it, your application is running on your Gandi cloud server.

5. HTTP Port, database

Since it’s a Cloud environment, you can easily create one server for each app. In this case, just configure Play to run on port 80 and you’re done. But if one Gandi server part is too big for one application and you can’t afford buying too many parts, you can run a web front-end to host several Play apps on the same server.

See the Play documentation about running in production for instructions on how to do it.

For the database, you could configure one manually on the same server, but it’s much easier to create a separate MySQL server. You can create a server in “Gandi AI” mode, where the server is managed by Gandi and you don’t have direct access to it. That way, you can create a MySQL servers in a few clicks and point your Play app(s) to that separate server.

]]> http://erwan.jp/2010/02/23/deploy-a-play-application-on-gandi-cloud/feed/ 3 http://erwan.jp/2010/01/23/going-to-fosdem-talking-about-play/ http://erwan.jp/2010/01/23/going-to-fosdem-talking-about-play/#comments Sat, 23 Jan 2010 20:21:20 +0000 erwan http://erwan.jp/?p=475 I will be at FOSDEM in Bruxelles on Saturday 6 February. I will make a talk about the Play framework in the Free Java session, at 17:15.

Specifically, they (I mean “we”) have an Open Source project called the Play! Framework. It’s an MVC framework similar to Django or Ruby on Rails, in Java. Within the Java world, I think it’s pretty disruptive. It contrasts from bloated stacks, and manages to provide simplicity and productivity to Java web development. Also, it speaks the language of the web by making it easy to create RESTful web apps, pretty URLs and web services.

Here is a screencast I did last month for the 1.0 release.

A web app in 10 minutes using Play! from zenexity on Vimeo.