17 December 2010

Testing with Selenium Grid

This week I tasked myself with finding and fixing memory issues that we've found in the current app I'm working on. Now Java is supposed to be good at reclaiming memory and leaks can be difficult to find.

A little background on the project: it was originally outsourced to a company in India, but has sense been brought in-house for future development and enhancement.

After looking what we were given and fixing initial problems, there were obvious spots that needed refactoring. Moving from the blatant, we started working on the more intricate parts.

Among other things, the application uses Hibernate for persistence. This isn't my first interaction with Hibernate and I rather like it. To call the implementation we were given bastardized might be a compliment. Ripping out the most obscene parts, we were left with a workable solution.

Further refactoring and we had a solution that no longer referenced any of the old code. Usually this is a good thing (tm), but after doing some load testing, it became apparent that we had some memory issues that needed addressing.

After looking at what we were given and what it was changed to, I got a hunch that something wasn't right. Digging through documentation, I had the a-ha moment. We were loading a new SessionFactory for each new database connection. As the documentation says, the SessionFactory should be a singleton. So after making that change, the memory issue was resolved.

Helping find the issue was the load testing environment that was setup. Utilizing Selenium Grid to run tests helped identify the issues we were facing. If you haven't heard of Selenium, I suggest checking it out for doing your acceptance testing. Our environment consists of 5 VMs running Fedora. One has an application and database server and the other 4 run the Selenium Grid. If you have some free time and some extra capacity, check it out.