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)
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]
Sometimes I can’t help but getting nostalgic when I think about the old days when Microsoft Visual Studio was the benchmark for Integrated Development Environments. Back then when I used Visual C++ 2.0 the first time, I immediately fell in love with it. The IDE ran under Windows NT (I refused to use Windows 3.1 and 95 for anything productive), had an excellent editor and kick-ass debugger, was fast, and just did what it was supposed to do without getting in my way. The following releases improved on that foundation and introduced features such as IntelliSense, incremental Compilation and minimal Rebuild. Everything was good in Developer Land.
Unfortunately, all of that ended with the release of Visual Studio .Net 2002. This was the first release which introduced support for the .Net Framework in the IDE. Don’t get me wrong. I still regard the .Net Framework as one of Microsoft’s better products, but this post is about Visual Studio and the impact the framework plus other contributing factors had on the quality of IDE. Visual Studio .Net 2002 took approximately two hours to install on my relatively powerful workstation. After that, when I was allowed to launch the IDE, the greatly increased startup time was immediately noticeable. But hey that’s the price you got to pay for all those shiny new features right?
[More]
