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]

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)

This is one of the very rare occasions where Microsoft actually did something cool. A couple days ago I needed to test one of my web apps with Internet Explorer 8 and just for giggles with IE6 – although we’ve dropped support for that dinosaur a while ago. Remembering my previous experience with IE8 and my inability to go back to 7 all too well – yes don’t laugh at me, I should have known better I know – I was preparing to fire up VMWare and create two XP Images, one for each browser version. But imagine my surprise when I discovered that Microsoft actually offers pre-configured ready to launch Windows XP VirtualPC Images for every possible IE version for free.

Be advised that these images expire in a couple of months but Microsoft seems to make new images  available shortly before the old ones expire.

Here’s the link: http://www.microsoft.com/downloads/details.aspx?FamilyID=7c2b5317-a40f-4e86-8835-d37170c5923e&displaylang=en

I admit it – I’m a performance junkie. I can’t stand code that just works but performs poorly. Being said, I recently fell in love with Django (a fantastic Python powered web application framework). In one of my current projects – xarmory.com – the number of requests for static resources issued during page load began to bother me. The project makes intensive use of jQuery and it’s my personal belief that Django + jQuery is a match made in heaven. When working with jQuery you will find yourself often in the situation to rely in cool little jQuery plugins – each distributed as a seperate javascript file of course. When a project grows, those files begin to add up. In the case of xarmory.com we now had eleven javascript references in the header section of the page. Although the individual files are were only 3-11k in Size, the request overhead for all those tiny files became unacceptably in my eyes.

To alleviate the problem I decided to resort to a simple solution and just merge the individual script files into a single file. A pretty common practice. Before reinventing the wheel I surfed the net for existing solutions and found two which I gave a shot. Short story, both solutions had their share of problems mostly stemming from the fact that they wanted to do it all and integrate their own Javascript Minifier in addition to the merging. During my short evaluation both Minifiers choked on fifty percent of my javascript files, even on the official jquery 1.2.6 script. A bit frustrated I decided to roll out my own Django Template Tag based on this code.

[More]

I’ve spent the past week juggling with GWT, Maven 2, Eclipse, Jetty 6 and Tomcat 6. My goal was:

• Run GWT hosted mode using noserver switch in order to use my own application server / container. The reason for this was that I wanted to experiment with Jetty 6’s continuations and Tomcat 6’s Cometprocessor servlet interface
• Keep full debugging support for both server and client code in Eclipse in noserver mode
• Fully automated command line builds, packing and deployments using Maven

Switching to noserver hosted mode in GWT has a couple of implications. When using the -noserver flag, your external server is used by the GWT Hosted Mode browser to serve up both your dynamic content, and all static content (such as the GWT application’s host page, other HTML files, images, CSS, and so on.). GWT’s internal Tomcat is no longer used. This also means that you are totally on your own with everything happening on the server side.

[More]