418 I'm a teapot

With the release of Grails 1.3.1 we decided that it was finally time to stop our ‘copy all the jars to lib’ process and use the awesome dependency manager.

As with any move from static lib directory to a smarter dependency manager we ran into some puzzling issues. One engineer set it all up and it worked great on our build system, but then about 50% of our engineers ran into some strange issues including this one which prevented any grails scripts from running:

...
SLF4J: This version of SLF4J requires log4j version 1.2.12 or later. See also http://www.slf4j.org/codes.html#log4j_version
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/Users/john_doe/.ivy2/cache/org.slf4j/slf4j-log4j12/jars/slf4j-log4j12-1.5.8.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/Users/john_doe/.ivy2/cache/org.slf4j/nlog4j/jars/nlog4j-1.2.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
...

Hacking around randomly seemed to fix it in every case. Here’s the crude process we ended up following to resolve these strange issues:

1. Purge the local caches by deleting ~/.ivy and ~/.grails
2. Reboot (Yes this fixed the problem for someone… go figure)
3. Run grails upgrade over and over until it started working

What is the root cause? I have no idea. Perhaps our dependency on the public repositories is to blame: one should never trust a free third party service.

Today I managed to set up my grails environment in such a way that it triggered deadlocks quite easily when stressed with a simple jmeter script. While this was unintentional, it did give me an opportunity to diffuse some ticking time bombs.

A few of the deadlocks were caused by some of the creative ways that my project uses the Groovy on Grails APIs for rendering pages from GSP code stored in a database, and with some tweaks most of those were resolved.

Some other deadlocks, though, seem to be the fault of Groovy itself. A quick google search turned up over 300 hits relating to deadlocks in the Groovy bug tracker:

http://www.google.com/search?hl=en&q=site:jira.codehaus.org+%2Bgroovy+%2Bdeadlock

This is when I had a sad.

I know that as an open source project if a bug really bothers me, I should submit a patch, which I am likely to do, but even if I find fixes for some of the deadlocks I’m facing, I’ll either have to wait for the changes to make it into the Groovy codebase, Groovy to release, grails to pick up the changes, etc. or I’ll have to hack the patch into my application and hope for the best.

Hopefully I’ll find some magic work around that does not tickle these bugs :)

Update: Someone must have seen this blog entry, or maybe they’re just cool. Anyway, they fixed this problem wicked fast: http://jira.codehaus.org/browse/GRAILS-6398 Grails continues to rock as a result.

Tablet computing is one technology that I’ve been attempting to early-adopt for years, but it’s never quite been there. What I’ve always dreamed of is the PADD device that everyone walked around with in Star Trek TNG: A small, light, sleek, multifunctional device that accepts pen input, accepts touch input, and is reasonable to carry around.

Around 2003 I purchased a Toshiba m200. It was a hybrid Windows XP Tablet computer. It had a keyboard but could also be converted into tablet mode. The operating system was a clunky afterthought on Windows XP, but it did have one shining star in the product offering (and it was not stupid marble game). It was OneNote. At the time everything Microsoft made seemed clunky and over-complicated, but OneNote did everything that made sense, and nothing else. It was, and still is, a great product.

I stopped using it, though. The application was great, but the operating system and hardware were just not there yet. Also people kept asking me why I was drawing on my laptop (since tablet computers were still fringe).

Now its 2010. Everyone has heard of the iPad. Tablet computing has gone mainstream but there does not seem to be a single killer OneNote like application for the iPad. This may have something to do with the lack of an included stylus. This void, however, can be filled using a combination of applications.

First off, you’ll need a system for organizing those notes. This is where Evernote comes in handy. The interface is clean, it supports cool features like automatic geotagging and you can even attach voice sound clips to your notes. Even better than OneNote, it supports automatic synchronization between all sorts of devices. It’s pretty mature, and has been around for awhile, but the iPad is the killer device for this service.

Unfortunately, since it started as a web browser / desktop application, Evernote does not yet allow you to scribble those quick notes. On the bright side it does allow you to email content to your primary notebook, and this is the trick.

For your stylus sketches and note taking, go grab a copy of Penultimate. Of the dozen or so drawing / sketching / scribbling apps I’ve tried, this one is by far the best. Input is clean and precise. It is also the only one I’ve found that works while your wrist is rested on the screen, which makes scribbling a lot more comfortable.

Once you’re done with that scribbled note in penultimate, use the ‘email this note’ feature to fire it off to Evernote. A quick synchronisation and there it will appear in your notebook.

It’s not perfect yet, and it’s a bit awkward, but it works well enough for me!

Joyent uses OpenSolaris zones for its accelerators. At some point I needed to verify the physical memory size of one of these zones but was unable to use the webmin tool that Joyent provides. This seemingly simple operation was actually pretty tricky to figure out. Here are the steps I followed:

 
$ sudo rcapadm -E
                                      state: enabled
           memory cap enforcement threshold: 0%
                    process scan rate (sec): 15
                 reconfiguration rate (sec): 60
                          report rate (sec): 5
                    RSS sampling rate (sec): 5
$ rcapstat -z 1 1
    id zone            nproc    vm   rss   cap    at avgat    pg avgpg
    46 foo            -    0K    0K 2048M    0K    0K    0K    0K
$ sudo rcapadm -D
                                      state: disabled
           memory cap enforcement threshold: 0%
                    process scan rate (sec): 15
                 reconfiguration rate (sec): 60
                          report rate (sec): 5
                    RSS sampling rate (sec): 5
$ 

rcapadm seems to be a resource management tool. I’m not sure if there’s an impact to leaving it running, but I disabled it just in case.

Sometimes you will need to switch up configuration in a hurry. For example, you may need to switch the database connection URL in order to use your warm standby database. This can be a pain in Grails because the convient-during-development Config.groovy is compiled both by grails run-app and grails war.

The simplest way to change configuration without rebuilding and redeploying your Grails application is to make use of an externalized configuration file. Although would appear to be very straight forward based on the docs, you will need to jump through a couple undocumented hoops to get it working in all environments.

1. Create your override configuration file in the grails-app/conf folder. I called mine override.conf. For now you can leave it empty.
2. Enable this external configuration file by pasting this into the top of your grails-app/conf/Config.groovy file:

grails.config.locations = [ "classpath:override.properties"  ]

This is where the docs end. When you start up grails you’ll see the following error message:

Unable to load specified config location classpath:override.properties : class path resource [override.properties] cannot be opened because it does not exist

1. Grails uses different paths in run-app mode and when being run as a war. We’re going to need to add a step post compilation to ensure our configuration file is available at all times. We’ll do this by modifying _Events.groovy (or Events.groovy if you’ve been migrating your grails app since v1.1). Open scripts/_Events.groovy, or create it if it does not exist. 1. Add the following to _Events.groovy (or merge it in if you already have an eventCompileEnd defined):

eventCompileEnd = {
    ant.copy(todir:classesDirPath) {
      fileset(file:"${basedir}/grails-app/conf/override.properties")
    }
}

1. Try setting a new property and fire up grails as usual. For example, if you want to set the database URL, you’d add this to your grails-app/conf/override.properties file:

dataSource.url=jdbc:postgresql://example.host/somedb:shutdown=true

Source: Some Grails - user mailing list post by Ian Roberts