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

How to use your debugger in the presence of timeouts in your code.

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.

RuntimeMXBean runtimeMXBean = ManagementFactory.getRuntimeMXBean();
String jvmArguments = runtimeMXBean.getInputArguments().toString();
boolean hasDebuggerAttached = jvmArguments.contains("-agentlib:jdwp");

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.

Reference: Java Debuggers and Timeouts from our JCG partner Richard Warburton at the Insightful Logic blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


+ 6 = twelve



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on 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.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close