About Richard Warburton

Richard is a Principle Software Engineer at jClarity, interested in deep dive performance issues and compiler verification, Adopt-aJSR, Adopt OpenJDK and the LJC. He holds a PhD from the University of Warwick and lives in London.

Java Debuggers and Timeouts

My kingdom for a debugger!

So you’ve been coding away merrily on a project and everything is going well until a bug appears. You reach into your developer’s toolbox and pull out a debugger. It’s great – you can set breakpoints, you can interrupt when there’s an exception and you can inspect expressions at runtime. Whatever challenge awaits, you can be sure that a debugger will help!

Unfortunately life isn’t that easy. A lot of code needs to have some kind of timeout – an event that happens after a period of time. The problem with this is that timeouts tend to ruin the debugging experience. You’re sitting there looking at your breakpoint, thinking “Now why is x 2 instead of 1?” Poof! The timeout kicks in and you are no longer able to continue. Even worse the JVM itself quits! So you go through the process of increasing your timeout, debugging and fixing your problem. Afterwards you either return the timeout to its original setting and have to go through the same tedious process again or accidentally commit the fix into your source tree thus breaking a test or maybe even production. To me this seems less than ideal.

“For somehow this is timeout’s disease, to trust no friends”

There are many reasons that people introduce timeouts. I’ve listed a few below, a couple of good and a couple of bad, and I’m sure you can think of a few more yourself.

Checking that an asynchronous event has been responded to within a certain period of time.

Avoiding starvation of a time based resource, such as a thread pool.

You’ve got a race condition that needs a quick fix.

You are waiting for an event to happen and decide to hard code an assumption about how long it’ll take. (Can be most frequently spotted in tests)

Now obviously if your timeout has been introduced as a hack then it’s a good time to clean and boy-scout the code. If you need to rely on an event happening in tests then you should treat those tests as clients of your API and be able to know when the event has occurred. This might involve injecting a mock which gets called when an event happens or subscribing to a stream of events. If you’ve got a race condition – fix it! I know it’s painful and hard but do you really want a ticking timebomb in your codebase ready to generate a support call at 3am?

Managing your timeouts

Having said that we should remove the bad uses of timeouts, it’s pretty clear that are perfectly legitimate uses of timeouts. They are especially common in event driven and asynchronous code. It would still be good to be able to debug with them around. Good practice regardless of other factors is to be able to standardise your timeouts into configuration properties which can be set at runtime. This lets you easily alter them when running in a local IDE vs production. It can also help with managing the different performance properties that you encounter from differing hardware setups.

Having externalised your timeouts into configuration from your code, you can then detect whether your code is running inside a debugger and set timeouts to significantly longer periods if this is the case. The trick to doing this is to recognise that a debugger involves running a Java agent, which modifies the command-line arguments of the program that it runs under. You can check whether these command-line arguments contain the right agent matcher. The following code snippet shows how to do this and has been tested to work under both eclipse and Intellij IDEA.

I can see why some people would view it as a hack as well, you’re actively discovering something about your environment by looking at your own command-line arguments and then adapting around it. From my perspective, I’ve found this to be a useful technique. It does make it easier to debug in the presence of timeouts.

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Join Us

With 1,240,600 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Examples Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.