Debug Java Applications from Development to Production
FusionReactor’s Remote Java Debugger is a game changing “production-ready” tool to give you INSTANT insight into your development & production environments and MINIMIZE time needed to identify issues
Start Free Trial Compare Editions See Examples Pricing
Production Debugger 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.
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 setup 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 break point fired. It has NEVER been easier and faster to get to the root of issues.
Email Stacktrace & Variable Context
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
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
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 setup 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.
Remote Java Debugging
Remote Java debugging is not a new concept and you can find numerous articles explaining how to setup 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 setup. 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).
- 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 break point 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 126.96.36.199 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 break point is set will it start to process class load events to install break points 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