Production debugging Java
FusionReactor’s Remote Java Debugger is a game-changing “Production debugging Java” tool that gives you INSTANT insight into your development & production environments and minimizes the time needed to identify issues
Start Free Trial Compare Editions See Examples Pricing
Production debugging Java overview
FusionReactor’s debugger contains a fully featured, low overhead, ‘IDE’ Style debugging browser console (see below) as well as the ability to capture stack trace and variable context state at any point where you may set a breakpoint in your code. No need to write variables out to logs – just run FusionReactor and set a breakpoint and receive an email with all the information you need. Easily perform remote Java debugging for any JVM or Docker container.
Production debugging Java using a Java IDE Debugger
All built into FusionReactor! The Java Debugger gives you all the control you need to simply and securely interact with your production environment as issues unfold. The insight it provides will revolutionize how you identify problems. Unlike a typical debugger, you can set up conditional breakpoints and be alerted by email when they fire. The email will contain a link to the debug session, as well as stack trace and variable details at the instant the breakpoint fired. It has NEVER been easier and faster to get to the root of issues.
Email Stacktrace & Variable Context for production debugging Java
FusionReactor can be configured to send you an email containing the complete stack trace PLUS all the scope variables which were set at the moment the breakpoint trigger fires – at that exact point in the code.
This capability means that you no longer have to include debug code in your applications to write variables into log files or force dumps to capture context.
Having the stack trace plus variables can often be enough to pinpoint what the actual issue is – so you may not even need to debug via the integrated debugger.
Pause A Single Thread when production debugging Java
One of the options on the Production Debugger is to pause a single thread for a specific period of time when a breakpoint fires. The Debugger can control how many threads it will halt, so this ensures it doesn’t halt your whole application. In this example, you can see that the thread will Timeout in 19 seconds. Unless we attend the breakpoint within that time, then the thread will simply continue to process.
Set breakpoints and trigger handlers when you are production debugging Java
Setting Breakpoints (BP) is really easy and FusionReactor supports various methods to control breakpoints, such as On Exception, Field Modification, Java Method Entry, and Source File-Line Number. You can also set up conditions which need to be met before the BP fires. The Fire Count controls how many times the BP will fire.
Other elements control how the engine will attend to the breakpoint e.g. open a debug window, email a stacktrace or capture metrics.
Production debugging Java
Remote Java debugging is not a new concept and you can find numerous articles explaining how to set up various IDE’s such as Eclipse, Netbeans or IntelliJ to perform remote debugging of a Java Application. There are many reasons you may want to be able to do this e.g. local debugging is not possible, you are running Docker containers and it’s difficult to attach a regular debugger, the code you wish to debug is not running on your local machine or the problem you’re trying to isolate only occurs on another environment (usually production) etc.
Before we go any further though, let’s take a step back and look at the main reasons you may NOT want to debug a remote (production) application. (Make sure to read on, to understand how FusionReactor addresses and solves these concerns though!)
- When you set a breakpoint – it could halt your whole application as the breakpoint would (theoretically) trigger on all threads at that point in the code. Ouch – well you definitely don’t want that happening in production.
- When you use a debugger – you imagine sitting in front of it and stepping through your code – i.e. you set a breakpoint – allow your application to run to that point in the code and then take a look at some variables. However, what happens if you’re not in control of when the breakpoint fires? What happens if your breakpoint would only fire in a rare corner case, which is what you’re actually trying to figure out. Well, then you could be faced with a long wait before that breakpoint would ever fire – order the pizza, it could take a while….
- Attaching ECLIPSE or some other IDE is going to cause too much system overhead and it’s also fairly tricky to set up. Or, you’re using an IDE which doesn’t even allow remote debugging.
- The core developer perception that you should not use a debugger in a production environment (very probably based on the reasons mentioned above).
Solve developer issues when you are production debugging Java
- Problem: Breakpoints affect all threads.
Solution: FusionReactor has implemented a suite of (patent pending) control mechanisms by which the debugger interacts with the environment it’s running on. Examples of these control mechanisms are:
- Fire once (or n times) for any breakpoint which means only 1 thread would ever be affected even when the breakpoint fires.
- Controlling the debugging capability from a specific IP address.
- Rate limiting the number of threads which can be paused in the debugger at any 1 time or how many threads a single break point can pause. If an application server has a thread pool of 16 you could say only 2 threads can be paused at once (either globally or per breakpoint)
- Thread pause timeout: if you (the user) would not intercept a paused thread within a specific time then FusionReactor will release the lock and allow thread execution to continue. This reduces the thread pause time to n seconds when debugging on a production server. When used with the thread limits or file count limits this reduces the possible impact to 1 thread only 1 and only for n seconds.
- Problem: If you’re debugging, you usually have to wait for a breakpoint to fire – which could be a big problem if you’re waiting for that elusive issue to occur.
Solution: FusionReactor is capable of holding a single thread either for a period of time in hours, minutes, seconds – or indefinitely. This removes the need for the developer to babysit the application waiting for the trigger to fire. Essentially, it enables the debugger to run in an ‘Unattended’ fashion – rather than it would typically i.e. one would usually, always attend a debugger whilst using it.
- Problem: Setting up remote debugging is tricky and incurs too much overhead.
Solution: FusionReactor is simple to install and has its own built-in IDE for debugging – FR is designed to be installed on production servers and has an overall impact of <1%. For the debugging part, it uses the JVMTI library from the Java Virtual Machine. This exposes a debug API to our debugger (this is the same method used by other IDE’s like Netbeans and Eclipse). Getting this configured in FusionReactor is simple. The normal impact of having FR’s Debugger installed is ZERO (unless you use Java 220.127.116.11 or earlier due to a bug in Java) apart from the memory used to load the library into memory. FusionReactor only enables the features in JVMTI when the user wants to use them. So only when a breakpoint is set will it start to process class load events to install breakpoints into those classes. Exception event hooks only become enabled when the exception breakpoint trigger is configured and enabled. It’s a small price to pay for the benefits you get.
FusionReactor Works with your Framework
Production debugging Java with FusionReactor
To start production debugging Java simply download the free FusionReactor trial. FusionReactor has a number of license options including our Developer license, Ultimate, Standard, and Enterprise; all licenses give you an outstanding APM for a reasonable price.
Start Free Trial Compare Editions See Examples Pricing