Save those (test) results and logs

Organizations typically have well defined archive policies for the production logs and data.  However, a lot of test environments are ignored.  There is nothing more frustrating than trying to look at test results from a couple of weeks ago and the logs are gone.  Thus any sort of analysis (i.e. pulling the verbose GC data from native_stderr) can not be conducted.  That means the test was inconclusive. 

If your organization does not have archival procedures and processes for the test environments (at least the performance one) make sure that it gets on someone's agenda.

Coding for resiliency : long running (or infinite) loops : stop the madness

....
while(exception instance of MyException) {
    exception = (MyException)exception;
}
....

This was code (not verbatim) that was found in a production application.  Please, always have a valid exit condition for your loops.  And then a 2nd way to exit the loop somehow if the primary condition always reverts to true.

Coding for Resiliency : thread locals and cleaning them up in a finally block

I haven't updated this site because I had a brief vacation that was cut short by a blocked tear duct.  I'm still suffering with this and the medication seems to have alleviated but not rectified the problem.  Unfortunately that means going to an eye doctor on Monday if it hasn't cleared.

A colleague of mine is working on a problem where they plan to use a thread local within a servlet filter.  When I read this it reminded me of another problem; uncleaned thread local variables.  The key here is to be sure to clear out the thread local in a finally block before exiting the servlet filter.  This is because it is very likely that a thread in WebSphere Application Server will be reused by subsequent requests (especially in high volume environments).  If the thread local is not properly cleaned up during an exception situation then the next request on the same thread will be looking at a thread local in an invalid state.  So use those finally blocks for what they were purposed for!

HTTP Session failover and performance

One of my colleagues wrote a good article that covers HTTP session failover.  There are performance implications to using HTTP sessions and persisting them.  This spurs me to start a series of articles to discuss some of the pros/cons with these mechanisms. 

Before session persistence existed there was no fail over capability for sessions.  This is, though, probably the most performant deployment.  Sure, users have to log back in but the application server doesn't have to spend time on serializing objects and then pushing them out to a database.  You save on both memory (for the serialized objects) which then have to be garbage collected which is paid for through CPU utilization. 

If your business requirements can stand it, and require users to relogin in a failure, then this is a good deployment strategy.  I know a number of intra departmental applications that can tolerate such activity. 

The WebSphere Contrarian: Back to basics: Session failover

My preferred alternative is to rely not on session distribution, but instead to rely simply on HTTP server plug-in affinity to “pin” a user to an application server, although this does mean that stopping an application server JVM will result in the loss of the HttpSession object. The benefit of doing so is that there is no need to distribute the session objects to provide for HttpSession object failover when an application server fails or is stopped. The obvious down side is that a user will lose any application state and will need to log back in and recreate it, and this may or may not be acceptable for your application or business requirements. I'll mention that I’ve worked with a number of customers that in fact agree with this view and make this their standard practice.

pClusters on JDK 1.4.2

When enabling pClusters on the 1.4.2 JDK be sure to enable gcpolicy:subpool otherwise it won't work as expected.