If you're using JNDI to connect to your database through Tomcat, then it's possible you've had to deal with database connection pool leaks. Your code tests fine, it's been reviewed, but in load tests or in production your app is unable to acquire database connections, the pool is empty!

Fear not, there are some handy parameters which can be set in your application's XML configuration file (in tomcat/conf/Catalina/YOUR_IP/YOUR_APP.xml):

removeAbandoned: Enables automated monitoring of pooled DB connections, and closes them if they time out. This is a catch-all, which prevents bugs in your code from bringing a system to its knees. If your app fails to close a connection, this will close it after a certain time period.

removeAbandonedTimeout: Sets the timeout value for use with the removeAbandonded parameter.

logAbandoned: Logs stack trace information when a pooled DB connection times out. This is invaluable information which can help you quickly track down the offending lines of code which failed to close the connection.

These helpful parameters are documented here on the Apache Tomcat site, along with many other hints and suggestions.

Posted by Vance at 10:27 AM | Permalink

We've been expanding our development team lately, and that means lots of developers who are suddenly tasked with becoming VoiceXML certified. Having gone through this myself (I'm certified, now if only the VoiceXML Forum would update their Certified Developer's list), I am often asked "how much do I need to study?".

There is a lot of content to cover for this exam, I spent about a month studying before my exam and I feel comfortable recommending the same to others. As VoiceXML developers, we're lucky to have a user-friendly specification to study from, unlike some other languages. It's actually quite remarkable that both platform developers and application developers study and work from the same source (the spec). How many people do you know that learned Java from the Java spec?

Spend at least half of your time reading and working with the spec, and the other half of your time studying from a good VoiceXML book or two, and give yourself at least a month to absorb the material.

Posted by Vance at 09:08 AM | Permalink

How many times have you ran a Checkstyle ruleset against your Java code, investigated a problem line, and then wanted to scream out "but I did it the way it's supposed to be done!" If you're me, the answer is many. Additionally, some of the suggestions Checkstyle makes can leave you scratching your head, depending on how many of the more esoteric rules have been enabled.

One particular rule I have been wrestling with for some time now states, for each public method (paraphrasing here):

"This method must be declared as either abstract, final or have an empty implementation."

It's not immediately clear (unless you wrote this rule) why this is required. But then I discovered this wonderful index, which made it all clear. Using this index, you can lookup each of the generic Checkstyle warnings and see their justification.

So the war is over, Checkstyle and I have made peace now that I can determine the impetus behind its often cryptic warnings.

Posted by Vance at 09:14 AM | Permalink