I just added a Cron job to “ping” my application every 1 minute. After a short discussion with Paul Cusch, whom commented on one of my previous posts regarding the load request issues Grails on AppEngine is seeing. I decided to give it a try. This solution is entirely based on Paul’s idea I’m just writing it up.

Grails AppEngine plugin is missing a feature to use cron out of the box. I hope to submit a patch for it. This is how it works. You need to have a cron.xml file next to your appengine-web.xml file. In the cron file you describe which url and how often a GET operation should be done on the specified url.

Details can be found here.

I simply added a request to a specified url, which I added to my URL mapping:

"/today"(controller: "user", action = "ping")

Then added a cron file to ping it every minute:

<?xml version="1.0" encoding="UTF-8"?>
<cronentries>
    <cron>
        <url>/today</url>
        <description>Keep the app alive by ping every 1 minutes</description>
        <schedule>every 1 minutes</schedule>
    </cron>
</cronentries>

The cron.xml file I keep in my grails-app/conf directory, following the conventions used by the AppEngine plugin, for similar files.

The user controller unfortunately got the honor for hosting the ping request.

def ping = {
  render "ping ${new Date().toString()}"
}

And there it is. Next time that application is uploaded to the AppEngine, the ping method on the user controller will be executed every 1 minute. Helping to keep the application loaded.

This method comes with a few drawbacks however. The application will still hit loading requests every now and then, and those requests will take from your quota. This setup can easily eat up all your free quota.

Also, if everyone sets up this cron job. Then a lot of quota is wasted in general, which might affect the service for other applications. This workaround tries to fix a problem that should be fixed in the inner workings of AppEngine it self (not excluding changes to Grails initialization).

There is however a query that is ongoing. Google is considering the possibility to allow people to pay for keeping their application in memory. If you would consider such an option then star the this issue. I myself starred it, I think it’s quite acceptable.

I turned the cron loading task off in my application, instead seeing it as an experiment with Cron on Google AppEngine. The payoff for this solution wasn’t that great and for me it comes with the expense of some of my code quality.

In the 1.2.8 version of the AppEngine SDK there is an option to precompile your solution as you deploy it to the AppEngine. Apparently precompilation can save up to 30% runtime on loading requests.

I added the option to turn on the precompilation-enabled setting in appengine-web.xml to the AppEngine plug-in this morning. Hopefully I can submit a patch with change, I’ll get back to that in a bit.

As I’m writing this I’m deploying to AppEngine for the first time. What happens is that during the deployment to Google AppEngine, the appcfg.cmd compiles the solution locally.

Showing the following lines in the input:

37% Cloned 600 files.
40% Uploading 4 files.
52% Uploaded 1 files.
61% Uploaded 2 files.
68% Uploaded 3 files.
73% Uploaded 4 files.
77% Precompiling.
80% Precompiling. 174 files left.
82% Precompiling. 94 files left.
84% Precompiling. 22 files left.
90% Deploying new version.

Now it’s deployed, I’m going to let it run for a while while I fix something else.

I have Pingdom set up for checking the AppEngine project every minute. That way I can see the changes in response time, and from the dashboard I can see if the CPU use goes down.

As far as I can tell, the precompilation doesn’t help with the timeout issues when starting a grails application hosted on AppEngine, it might help, but it doesn’t affect the loading time noticeably. However I for one am going to have my application precompiled.

If you use the app-engine plug-in deploy command using AppEngine SDK version 1.2.8 it will fail with the following error:

[java] Bad argument: email requires an argument, for example, "email=FOO"
[java] usage: AppCfg [options] <action> <app-dir> [<output-file>]
[java] Action must be one of:
[java]   help: Print help for a specific action.
[java]   request_logs: Write request logs in Apache common log format.
…
[java]                         request logs are returned.
[java]   -n NUM_RUNS, --num_runs=NUM_RUNS
[java]                         Number of scheduled execution times to compute
[java] Java Result: 1

Google changed so deployment is targeting a directory instead of a war file.

What you need to do to deploy is instead to use the AppEngine built in command to deploy

%APPENGINE_HOME%/bin/appcfg.cmd update c:\users\morten\.grails\1.2.0.RC1\projects\<projectname>\stage

After this all I had to do was to update my deployment scripts, and the stage is set for some serious Grailsing.

I should point out that all previous workarounds for working on Windows still need to be in place.

Google just announced their attack plan for handling the long startup cost for, among others, Grails applications.

Apparently what I can do as a developer is to enable pre-compilation of my application. I’ll experiment with this at the end of the week I hope.

Read the full post on the AppEngine blog

Regarding the logging issue with Grails and Google AppEngine, I’ve just installed the latest build of Grails1.2 and deployed to AppEngine, and it works.

No change to the loading time of grails however, I’m still getting timeouts on my initial requests.