Updated: Mocking Hibernate Create Criteria in Grails' Unit Test with GMock

Using the GMock Library I have updated my unit tests to mock out the create criteria methods the following way:

void testSomeFunction() {
    def results = []

    def mockCriteria = mock() {
      list(instanceOf(Closure)).returns(results)
    }

    mock(Book).static.createCriteria().returns(mockCriteria)

    play {
      assertEquals null, bookService.getDefaultBook(null)
    }
  }

You need to add the following to the top of the unit test file with the import statements:

import org.gmock.*
import static org.hamcrest.Matchers.*

@WithGMock

Also add the following to your BuildConfig.groovy:

dependencies {
    test "org.gmock:gmock:0.8.0"
    test "org.hamcrest:hamcrest-all:1.0"
}

I learned this from the following blog post: http://adhockery.blogspot.com/2010/01/using-gmock-to-complement-grails.html

Unit Testing a Android Activity which contains a Runnable

In order to unit test an Android Activity to verify that the Runnable is called you need to add a call to waitForIdle to the Instrumentation, which is called when all Runnables have been executed.

Here is the activity that we are testing:

public class SplashScreenActivity extends Activity {

public final int SPLASH_DISPLAY_LENGTH = 1200;
 
   @Override
   public void onCreate(Bundle icicle) {
 super.onCreate(icicle);
 setContentView(R.layout.splash);

 new Handler().postDelayed(new Runnable() {

  public void run() {    
   Intent mainIntent = new Intent(SplashScreenActivity.this, NextActivity.class);
   startActivity(mainIntent);
   finish();
  }

 }, SPLASH_DISPLAY_LENGTH);
   }
}

Here is the method in the Unit Test Class:

public void testSubLaunch() {
        SplashScreenActivity mActivity = startActivity(new Intent(), null, null);
        getInstrumentation().waitForIdle(new Runnable() {
  public void run() {
   assertNotNull(getStartedActivityIntent());
   assertTrue(isFinishCalled());
  }         
        });    
    }

Why you should upgrade to Grails 1.3.5

I did a profile of my Grails application with JVisualVM running Grails 1.3.4 and then again running Grails 1.3.5.  What a difference!  The memory leak issue that was referred to here http://jira.codehaus.org/browse/GRAILS-6622 was fixed in the 1.3.5 release.  I believe that a similar memory leak was affecting my application as well.  Across the board, the application is faster and has a much smaller memory footprint.  I have attached a snapshot of the memory comparison for the two versions to this post.

Memory Comparison of Grails 1.3.4 and Grails 1.3.5

Adding HTTP Access Logging to Glassfish 3.0 Server

Recently I had the need to monitor the requests that were being sent to my Glassfish server. Here is the simple configuration change that needed to be done to the domain.xml file:

<configs>
<config name="server-config">
<http-service enabled="true"></http-service>
<access-log format="%client.name% %auth-user-name% %datetime% %request% %status% %response.length% %header.referer%"></access-log>
<virtual-server id="server" log="/mnt/httpd/logs/access" listeners="http-listener-1"></virtual-server>
<virtual-server id="__asadmin" listeners="admin-listener"></virtual-server>
....
</config>
</configs>

Sun's Documentation: Enabling Access Logging

Killing Long Running Processes in MySQL

This should never happen, but it does and so I'm going to tell you one way that I kill stale processes on my MySQL database server:

cat longprocesses.txt | awk '{print "kill "$1";"}'

I run the show full processlist command on MySQL and then copy the list of stale processes to a file that I have named longprocesses.txt. Once that is done I have several lines of code that look like this:

kill 12345;
kill 93479;
....

I then copy this into MySQL or SequelPro and run the kill commands. This is somewhat tedious so I'm looking for a faster way to do this, any ideas, just post a comment. Thanks.

3 Tips to Help Avoid the Hibernate Flush

When using Grails, the default behavior of Hibernate is to do a flush before queries, at the end of requests, and pretty much whenever Hibernate feels like it. So here are three tips that can help you avoid some of the flushing and/or at the very least decrease the number of database connections that Hibernate attempts to get:

1. Use read() function when possible: If you are only going to read some field of a domain object and will make no changes to it, then just use object.read(), instead of the get() method
2. Make sure your services are only transactional if they need to be, so if you are not updating, saving, or deleting records in the db chances are you do not need your Service to be transactional
3. If you do have some transactional logic, put it inside a domain.withTransaction {} closure instead of making the entire function or class transactional
   

Configuration of DataSource.groovy for Highly Concurrent Grails Application

In developing a highly concurrent Grails Application, I ran into an issue where many connections were being created to the database and were subsequently not released. After reading several blog posts it seems that the library used to handle the connection pooling was not designed for highly concurrent systems. I found that using the following setup in your DataSource.groovy file eliminates the stale connection issue and allows a high level of concurrency.

dataSource {
pooled = true
driverClassName = "com.mysql.jdbc.Driver"
dialect = "org.hibernate.dialect.MySQL5InnoDBDialect"
properties {
maxActive = 50
maxIdle = 10
initialSize = 10
minEvictableIdleTimeMillis = 10000
timeBetweenEvictionRunsMillis = 20000
maxWait = 10000
validationQuery = "/* ping */"
testWhileIdle = true
numTestsPerEvictionRun = 3
testOnBorrow = true
}
}

Hope this can help someone else.

Monitor Hibernate Cache Statistics in Grails Application v2

In an earlier post I wrote about monitoring your cache hits in a Grails Application using a programmatic approach, this time I will show you how to use jconsole and have it done for you automatically.

All you need to do is start your Grails Application: grails run-app. Then start jconsole and choose your running Grails' process. Go over to the MBeans tab and navigate to the area of your application server where you can see the cache.

What I really love about this is that you can perform actions in your application and watch the cache hits over time.

Using Grails' mockParams with Associations

If you have a class Book which contains a list of authors and would like to test this functionality in your Controller's unit tests. This is how you would do it, using the Grails mockParams.

void testSaveOfBookWithAuthor() {
mockRequest.method = 'POST'
mockParams.title = "Book Title"
mockParams["authors"] = [["author.id":"123", "author":["id":"123"]]]
controller.save()
}

Even More Git Commands

Recent Git commands that have proved very helpful to me along with brief descriptions:

• git instaweb - this allows you to view your repo in a browswer; you can configure which web server you would like to use in your ~/.gitconfig file
• git log -n <filename> - you can restrict the number of commits that the log will show you for a given file
• git blame <filename> - you can see who author every line of code in a given file
• git diff ..origin/master <filename> - allows you to see the differences between your local file and the remote
• git merge --squash <branchname> - allows you to merge your commits from a local branch together as a group of modified files into the current branch
  

Spring Security vs. Apache Shiro

This is a high level comparison of Spring Security and Apache Shiro, two Security frameworks that have plugins available in Grails.

Spring Security (a.k.a. ACEGI)

• has users with roles
• to restrict users on a more fine grained level, use interceptors in your controller
• LDAP support
• integration with CAS single-sign-on
• has a new ACL option for the Grails Plugin
  
• somewhat 'heavy-handed'
  

Example (Using Grails Interceptor):
def beforeInterceptor = [action:checkViewableSites, except: "list"]

def checkViewableSites = {
if(!user.viewableSites.contains(Site.get(params.id) )) {
response.sendError 403
return false
}
}

Apache Shiro (a.k.a. JSecurity)

• has support for permissions out of the box
• LDAP support with Shiro plugin
  
• easy to customize
• Grails Nimble plugin that allows permissions on three levels: users, groups, and roles
• Nimble plugin has an easy to use UI component for adding/modifying users and permissions
• Nimble plugin has support for authentication through Facebook and OpenID out of the box
  

Example (Using Shiro Permissions):

• profile:edit:1 - this means a person can edit only the Profile object with id 1
• profile:*:* - this means that a person can do anything to any Profile object
  

Monitor Hibernate Cache Statistics in Grails Application

After going through the effort of adding cache:true all over your application to take advantage of the Hibernate caching you will want to monitor the results. In order to do so you only need to modify two files, DataSource.groovy and a desired Controller.

//In your DataSource.groovy
hibernate {
generate_statistics=true
}

//In your Controller
def sessionFactory

def showCacheStatistics = {
def statistics = sessionFactory.statistics
log.info(statistics)
render statistics
}

Here is the output of calling the showCacheStatistics method on your controller:
Statistics[start time=1269058393252,sessions opened=27,sessions closed=25,transactions=18,successful transactions=3,optimistic lock failures=0,flushes=21,connections obtained=15,statements prepared=219,statements closed=219,second level cache puts=45,second level cache hits=1,second level cache misses=0,entities loaded=40,entities updated=5,entities inserted=48,entities deleted=0,entities fetched=26,collections loaded=20,collections updated=0,collections removed=0,collections recreated=12,collections fetched=18,queries executed to database=93,query cache puts=6,query cache hits=8,query cache misses=6,max query time=89]

Currently I'm showing just a direct rendering of the statistics object, but you could specify which parameters are important to you and only show those, or perhaps send the data to a gsp file and have it formatted in some way.

Improve Performance of Grails Queries in MySQL

A web application that I was developing would become extremely slow as the number of requests increased per minute. I couldn't figure out why because with my local database everything seemed fine. Here is the process that I used in MySQL to determine the bottleneck in my database. The final problem was a missing index on a table that was used in the where clause of a select statement over and over again. I included a snapshot the MySQL Process list at the end of the post. Hope this helps someone.

Steps to Follow:

• show full processlist;
  • shows each database connection that has been allocated for your database
  • contains the time a connection has been Sleep
  • contains how long a Query is taking to execute, you want this to be less than a second ideally
• describe <query>;
  • this gives you the database's plan for executing the query
  • you want the number of rows that will be looked at to be as small as possible
• show index from <table>;
  • this will list all indices contained on a table
  • this is a quick way to discover if you are missing a key index that could improve query performance
• create index <tablename_fieldname_idx> on <table>(field);
  
  • this will add a new index to a table

Mocking Hibernate Criteria in Grails App

Testing is always a sore spot in many applications, and Grails is no exception, but mocking objects and methods is actually not as bad as you think. Here is a simple way to mock the Hibernate Criteria object that is available from Grails domain classes.

Example:
If this is the code that you want to test, and for this particular test you want to have no results, this how you would mock it out.

Code:


Test Code:


The key piece of code is the creation of the bookCriteria object, in this case it is a member of the test class that is why it is not declared locally in the function. However, you will notice that the bookCriteria is simply a HashMap that returns a empty list for the 'list' parameter. This way when testing 'c.list' a empty list will be returned. Simple hunh!

top Command Line Tool

Recently I have been introduced to the top command line tool. This tool is very useful in viewing the top processes running on a machine and their CPU and Memory usage. I have included a screen shot of the top command's output.

Some useful options are the i option which allows you to toggle back and forth between viewing and not viewing idle processes.

And the M option which allows you to sort the processes by memory usage.