grails

by

The dark side of Grails

Grails can be an extremely enjoyable framework to work with. Some days productivity is super-high, code keeps flowing and I find new plugins which fits just like a glove. Grails automatic reloading of changed classes minimizes distractions. And then – bang! – a nasty SQLException with its accompanying 200 line stack trace is dumped on my terminal and brutally interrupts my flow.

The status of the Grails Bug Tracking system.

The status of the Grails Bug Tracking system October 13, 2009.

During my three months with Grails I’ve stumbled on several confusing bugs in the framework, the majority of which were related to the Grails’ ORM-layer GORM – particularly troubling for me personally as I’ve only limited SQL experience and practically no knowledge of Hibernate (the underpinnings of GORM) at all. Frankly speaking I’d very much prefer it to stay that way, with GORM doing the database heavy lifting behind the scenes and me knowing very little about these mundane tasks. This may be wishful thinking, it certainly is with the current (1.1) version of Grails. I’ve now adopted the routine to always check the Grails JIRA before proceeding with debugging of my own code when I encounter SQLExceptions.

Dean Del Ponte asks if bugs in grails are hurting adoption? The answer is a resounding yes, grails is simply to buggy!

But what does really “too buggy” mean? Its meaning lies of course it the eye of the beholder. Grails is not too buggy to be used in a production setting (if you are willing to accept a fair amount of hacking to get around bugs in the framework and the accompanying loss of developer productivity and morale). Grails is not too buggy for me, its advantages (convention over configuration, brevity, exciting plugins, CRUD scaffolding) far outshines the bugs. Grails is however way too buggy to provide for the smooth learning curve it really deserves.

I finish with some of my pet peeves:

  • GRAILS-2735 – Criteria.list() with paginate and sort order causes SQLException
    With us since 1.0.2, 13 watchers as of today.
  • GRAILS-4089 – Default Sort Order for associations causes java.sql.SQLException: Column not found
    With us since 1.1-RC1, 16 watchers as of today.
  • GRAILS-2475 – Criteria Builder causes SQL errors when using pagination and sort
    With us since 1.0, 2 watchers as of today.
by

64 bit JVM:s may come with severe penalties on memory constrained systems

I’ve been toying around with Spotifun – a Grails based webapp  – on a Rackspace cloud virtual machine.

The entry level rackspace offering is an instance with just 256 MB memory. I quickly discovered that 256 of RAM doesn’t cut it for running Tomcat with a single Grails app with a few grails plugins (~50MB WAR file size). The WAR barely deployed before the JVM ran OutOfMemory.

Decided to migrate my instance to a Rackspace plan with 512 MB of RAM.  This offered a sort-of reasonable experience. But just sort-of,  frequently episodes which excessive 10+ second response times would occur. Heavy garbage collection and/or swapping activity appeared to be a likely culprit, but as I was to cheap to just upgrade to a plan with even more memory I decided to whip out JConsole and have a look on the running JVM via JMX. I discovered that the JVM on the Rackspace instance was far more memory hungry than the JVM on my development work station.  Almost twice the amount of heap memory was used (measured post Tomcat startup)! And this on a system constrained to 512 MB (of which mysql and the base Ubuntu OS will obviously claim a significant share). Further investigation led me to the reason:

# uname -a
Linux 2.6.24-23-xen #1 SMP Mon Jan 26 03:09:12 UTC 2009 x86_64 GNU/Linux

Rackspace is obviously running on x64 hardware, causing Ubuntu apt-get to install a 64-bit JVM when java is installed. 64-bit software generally occupy more memory than their 32-bit counterparts, see the Wikipedia article on the subject for further details. The remedy is in this case however only a:

apt-get install ia32-sun-java6-bin

…away. A quick change to JAVA_HOME in Tomcat’s startup script to ensure that the correct JVM is used and memory consumption was back to sane levels. After reverting to a 32 bit JVM I’ve yet to see abnormal response times from Spotifun.