Logging

Seems you are stuck with using the JDK logging. Let’s face it, no developer in his right mind chooses that over Log4j. There just isn’t enough functionality there to make it worthwhile (reporting anyone?).

Persistence

You are limited to JDO. This can be both good and bad. JDO and related technologies, are fine for many applications, but there are times when you just need more power than object queries allow. The upside is that you probably don’t have to worry about data scaling needs.

Threading

You can’t create your own threads, nor presumably can anything else. This may be a big hindrance for many applications. For example I use the Quartz library all the time for various scheduling needs (especially in Grails).

There are a few other things you can and can’t do, but the ones above require some serious consideration before choosing to deploy on the app engine. On some brighter news, it looks like the Grails group is working on making Grails compatible with GAE. That alone will probably be the biggest use on GAE, and that isn’t a bad thing at all.

I.B.M. withdrew its $7 billion bid for Sun Microsystems on Sunday, one day after Sun’s board balked at a reduced offer, according to three people close to the talks.

The article goes on to say that other possible suitors could be HP and Cisco. I think with HP it would be similar to IBM in that HP would buy and dissolve the company with the possible exception of Java. As for Cisco, which is just entering the server business it would be a definite expansion of products all around.

Granted, Java has never really been a money maker for Sun but for IBM Sun’s Java software is a big competitor all the way from JVM to JEE servers. The other two companies don’t have a Java stack at all and would most likely leave the Java side alone, keeping out of Big Blue’s death.

Although IBM has pulled out, there is nothing from them getting back into it, and if Sun’s upcoming earnings report looks bad IBM may be the only one willing to buy them. Let’s hope for the best.

Let’s face it, not a single IBM java product is really worth a shit. Their JVM is and always will be the slowest one around, their app server is second worst piece of software I have ever had the displeasure of using, is slow, sluggish and can only run on their JVM.

If Sun needs to be bought to be saved, so be it. But please, please IBM, don’t screw up Java by dumping Sun’s products for your own!

JMX

After I got it all running and the domain name switched over, I started to look for ways to tune it a little bit without going too overboard. Being a fan of JMX, my first step was to see what was available via the jconsole. It turns out there are all kinds of things from hibernate, but none of them are enabled by default.

I searched and couldn’t find anything on the Grails site about it, so it took quite a bit of digging to find it and eventually I found it on the hibernate site. So in your DataSource.groovy file in the hibernate section, just add

generate_statistics=true

and you are good to go.

The nice thing about hibernate’s stats is they provide all kinds of good stuff, but I was mostly interested in the caching side of it.

Caching

After enabling the stats I could see that the cache hits were pretty damn small, as in non-existent. Hmm… I enabled caching using the cache.use_second_level_cache=true setting as advised in the Grails documentation. Nothing.

A few hours of searching later I found a post in Nabble that said the caching is only enabled by default for Domain.get() operations. Well that sucks! That should have been in the docs! For me those kinds of calls are extremely rare. Matter of fact, a good 99% of all my queries are of the Domain.withCriteria variety. Well, sprinkle in a cacheable( true ) call in each of those withCriteria closures and presto I was getting cache hits stats.

What surprised me the most was the number of cache hits I was getting. The site averages about 3000 visitors a day at the moment, and in one 24 hour period I got over 2 million cache hits. That is a lot of saved DB traffic! As I write this, in 2 hours and 8 minutes since the last restart, there have been 1,013 visitors, with 396,917 2nd level cache hits with 86 misses and 55,050 query cache hits with 7,390 misses. That is phenomenal.

The majority of these hits are from articles and comments and thus can afford to be cached. However if the docs had been more clear on this I would have saved a ton of time. Oh well.

User Stats

The visitor stats I got by looking at the sessions from tomcat. That information is available via JMX as well and I covered it more in my Using Groovy to Monitoring via JMX post.

Don’t forget SQL

While the api that grails provides via GORM is pretty nice and I do like it, let’s face it, sometimes SQL is just better for the task at hand. In my case I have a dashboard that shows various statics, like the cache stuff mentioned above, but it also does some basic report-type queries.

At first I attempted these by using criteria calls and manipulating the data as needed. It worked. It was horribly slow. One “query” took about 15 seconds on each call. Just not acceptable. Thankfully Groovy has a nice little SQL api built in and I took advantage of that. I wrote my sql, threw it into a sql.eachRow call and it executes in milliseconds now like it should.

I have about four of these queries, so it was a huge improvement. As for caching, it isn’t important in this case as there are only four people that have access to the dashboard, but speed was important.

Overall the site is running pretty smoothly in it’s first week and half of operation. A few little things here and there are expected of course and we have some plans or expansion. In future posts I’ll elaborate on more things I’ve picked up in working with Grails and Groovy in general.