Oliver’s Place

This article is the second one in my article series about fast loading web pages. The first article dealt with the Django Framework while this one is about Grails which I have recently elected as my preferred rapid web application framework. Ever since I switched from Django to Grails there was one issue that bothered me and that was the loss of the ability to serve complete pre-rendered pages from a distributed cache to the enduser while bypassing the application server.

The solution described in this article is in use on the production servers powering mmogle.com where it ensures page response times below 100ms for cached content.

Let me summarize the concept for readers not familiar with my first article: The goal we want to achieve is to greatly decrease the load on the application server (container) by storing the raw HTML output of rendered pages in a (distributed-) cache to be picked up by a Frontend Web Server without even bothering the application server behind it for the current request. Since we would need stuff like Edge Side Includes (ESI) for dealing with personalized pages, we are going limit ourselves to anonymous users.

[More]

Today I could once again not find a proper way to express a query needed for my current Grails project in either Hibernate HQL nor the DSL based variant of Hibernate’s Criteria API.

While it is quite simple to run native SQL Queries in Grails Project using Spring’s NamedParameterJdbcTemplate I never had to actually Map the result of a native SQL back to one of my Grails Domain Classes. After a bit of fiddling around it turned out that everything becomes quite trivial once you get ahold of the Hibernate SessionFactory that is made available by Grails for each request.

Let’s pretend we have the following Grails domain class:

package com.acme.domain
 
class Foo
{
  String name
}

You would execute a native SQL Query that returns a List of Foo instances like this:

import com.acme.domain.*
 
def sessionFactory
sessionFactory = ctx.sessionFactory  // this only necessary if your are working with the Grails console/shell
def session = sessionFactory.currentSession 
 
def query = session.createSQLQuery("select f.* from Foo where f.id = :filter)) order by f.name");
query.addEntity(com.acme.domain.Foo.class);
query.setInteger("filter", 88);
query.list()*.name;

Did you ever had to implement a menu in Grails GSP where every link element should be seperated from its predecessor by a separator character and where some of the elements can be missing when certain conditions are not met (security etc)?

The part with the optional elements can turn the separator handling into a real mess. So today I decided to end this nonsense. The result is a tiny taglib which can be integrated into every grails project. The usage is pretty self explanatory:

<mx:toolbar separator=’|'>
  <mx:item>
    <shiro:hasPermission permission=”topic:delete”>
      <g:link controller=”topic” action=”delete” id=”${topic.id}”><g:message code=”topic.delete”></g:message></g:link>
    </shiro:hasPermission>
  </mx:item>

  <mx:item>
    <shiro:hasPermission permission=”topic:lock”>
      <g:link controller=”topic” action=”lock” id=”${topic.id}”><g:message code=”topic.lock”></g:message></g:link>
    </shiro:hasPermission>
  </mx:item>
</mx:toolbar>

[More]

The other day I was writing a medium complex HQL query for a Grails App and no matter what the line executing the query would crash like this:

java.lang.NullPointerException
	at $Proxy13.createQuery(Unknown Source)
	at com.acme.PerformanceService.makePerformanceSheet(PerformanceService.groovy:38)
  ...

So how the hell do we figure out what the problem given so few information? Turns out that grails sanitizes the exception stacktrace, resulting in better readability by removing a lot of clutter. Sometimes though this optimization will also hide some important details from you. Luckily we can still refer to stacktrace.log which usually resides in the project root folder in development mode. In this particular case opening the file reveiled this:

java.lang.NullPointerException
	at org.hibernate.dialect.Dialect$3.getReturnType(Dialect.java:125)
	at org.hibernate.hql.ast.util.SessionFactoryHelper.findFunctionReturnType(SessionFactoryHelper.java:405)
	at org.hibernate.hql.ast.tree.AggregateNode.getDataType(AggregateNode.java:44)
	at org.hibernate.hql.ast.tree.SelectClause.initializeExplicitSelectClause(SelectClause.java:165)
	at org.hibernate.hql.ast.HqlSqlWalker.useSelectClause(HqlSqlWalker.java:727)
	at org.hibernate.hql.ast.HqlSqlWalker.processQuery(HqlSqlWalker.java:551)
	at org.hibernate.hql.antlr.HqlSqlBaseWalker.query(HqlSqlBaseWalker.java:645)
	at org.hibernate.hql.antlr.HqlSqlBaseWalker.selectStatement(HqlSqlBaseWalker.java:281)
	at org.hibernate.hql.antlr.HqlSqlBaseWalker.statement(HqlSqlBaseWalker.java:229)
	at org.hibernate.hql.ast.QueryTranslatorImpl.analyze(QueryTranslatorImpl.java:251)
	at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:183)
	at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:134)
	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101)
	at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80)
	at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94)
	at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156)
	at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135)
  ...

Which almost instantly gave me the hint that something’s wrong with the aggregate part of my query:

org.hibernate.hql.ast.tree.AggregateNode.getDataType

And indeed the problem was that I had ported an SQL Query to HQL and forgot to rename the sum() aggregate argument from the column name to the domain class property name:

sum(some_property) instead of sum(foo.someProperty)

I’m a big fan of using memcached for improving the scalability of websites so when I recently fell in love with the Grails Framework I began to look for a way to configure the memcached client which blends in with the framework. Luckily Grails provides a very easy way to configure Spring Beans using a DSL Just create grails-app/conf/spring/resources.groovy and add this:

beans =
{
  memcachedClient(MemcachedClient, 
    net.spy.memcached.AddrUtil.getAddresses(
      ConfigurationHolder.config.memcached_servers))
  { bean ->
    bean.scope = 'singleton' 
  }
}

Voila, from now on you can get a memcached client instance anywhere in your application either by standard dependency injection or by calling applicationContext.getBean(’memcachedClient’).

It is important to note that this example assumes that you have configured your memcached server(s) in grails-app/conf/Config.groovy like this:

environments
{
  development
  {
    memcached_servers = "192.168.230.2:11211"
  }
 
  production
  {
    memcached_servers = "localhost:11211"
  }
}

Every Web Application Project I’ve been involved in the recent past had one thing in common: the client demanded more and more rich-client features at an ever increasing pace – without committing itself to real rich-client frameworks such as Flex or Silverlight. This leaves us with Javascript / AJAX for implementing highly dynamic User Interfaces for Web Applications. A very common problem when working with Ajax is the requirement to update multiple parts of a page in response to a single request. This post aims to familiarize the reader with my own approach to this problem.

At its core my solution consists of just two functions – one running server side and the other executing on the client. The first function is intended to run on the server and is written in Groovy. It was originally written in Python for use with the Django framework and I’ve ported it to Groovy when I switched to Grails as my primary RAD Web framework. This function takes a map as argument and returns a JSON encoded map where the key is a valid jQuery Selector designating the targets for the update and the value is a map containing information how the matched elements should be modified and how the content for the update shall be produced. Don’t worry if you find this confusing at first. There’s a sample further down.

[More]

I’ve been doing a serious amount of Grails Development lately and if there’s one Grails Plugin I consider mandatory for any serious production deployment then it is the UI-Performance plugin by Burt Beckwith. One of the features of the plugin that reduces server load is versioning and far-future “Expires” and “Cache-Control” headers for static resources.

Each time you generate a new WAR for deployment, a new version is applied to all image, .js, and .css files so files can be cached forever. The next time you deploy a new version of your application, all of the resource file names will have changed, so only then will files be requested. The default process for determining the version is to look at the version of the root project folder in the Subversion metadata files. Since I’ve switched to GIT for all my projects a while ago the plugin would fallback to “System.currentTimeMillis().toString()” to compute the version.

My solution is to include the following line in my projects Config.groovy:

uiperformance.determineVersion = { -> "git rev-list --max-count=1 HEAD".execute().text.trim() }

This allows the HEAD commit SHA1 hash of the current branch to be used as the uiperformance version for deployment.