FusionReactor Blog - News and expert analysis for Java APM users.

Best root cause analysis Java tool

“Best root cause analysis Java tool”

What do you like best?

The installation is simple – I typically go with the manual JAR install because it’s super simple… drop a JAR on the filesystem and add a JVM argument.

Once running, the UI is easy to navigate – but not overly simplistic. You can drill down from high-level overview charts down to profiling stack-traces within a few clicks.

Easily the best tool I’ve used for root causes analysis on the JVM – and one of the cheapest too.

What do you dislike?

FusionReactor can do long-term trending but it’s not it’s strongest feature. In my experience, FusionReactor is much better at solving acute problems – sometime automatically through its crash protection features.

The cloud offering is improving all the time and does have better long-term trending (e.g. capacity planning)

Recommendations to others considering the product:

Install and give it a go – there’s a 14day free trial.

Automated installer is great if you have a GUI. If you’re in a container or CLI only, manual install is super-simple.

Try the profiling features!

What problems are you solving with the product? What benefits have you realized?

Root cause analysis (in production) of acute failures. When there’s a problem in production sometimes it’s not so simple to replicate – perhaps your data tier doesn’t have the same volume or differentiating set of data; or perhaps the network topology, redundancy or traffic levels are different. FusionReactor adds no noticable overhead and gives a wealth of insight – it’s always running and ready for us if we have a problem.

See review on G2

Start free trial

Tips for handling escalations for customer support engineers

These days the development of software is a rapidly changing process. The introduction of cloud hosting and containerization has made big applications running in your server room a thing of the past.

Where before you would maintain one or two big projects with a team of engineers dedicated to a single project. Now you have hundreds of small services split into bite-sized chunks with developers working on several projects.

In the perfect world, every software project will have a full suite of unit, integration and system tests in place. Even in these rare cases, it is still nearly impossible to avoid an escalation or critical performance issue when you are running at scale in production.

In my role as a technical support engineer, I have seen all manner of escalations. 

They can come in the form of;

  •  A performance bug in the product
  • A corner case issue you wouldn’t consider a user hitting
  • A service being offline that the product depends on
  • A third party library the product depends on being upgraded
  • Many more!

From a support engineers perspective, here are a few tips I have learned over the years on how to approach an escalation.

Tip 1: Reassure the customer

The initial customer contact in support is crucial. Letting the customer know their issue is under investigation reassures the customer and takes the pressure off the support engineer.

The initial response from support can often be automated, these days using a bot for first-line support is often standard practice.

A simple example of an email would be:

 “Dear {{ticket.requester.name}},

Thank you for reaching out to the {{team.name}}, a ticket has been created for you with the Ticket ID – {{ticket.id}}.

A support engineer will get back to you as soon as possible and work with you to resolve your issue.

Thank you for your patience.



This simple email lets the customer know their issue is assigned to an engineer and the team is willing to help. You could enhance this email by adding elements such as:

  • Common issues / solutions section
  • A personal sign off specific to one engineer
  • A phone number or chat to use if the situation is critical
  • A link to a support portal so they can see their ticket status

If the support case comes in via phone or chat, this is not so much of an issue. The customer is getting live responses from the support engineer.

Tip 2: Gather all the information you need

Investigating an issue can be simple, unfortunately this is often not the case. If the product you support is complicated, escalations could be caused by a wide variety of factors.

The goal of the support engineer is to find the route cause of the issue quickly, with as little time to set up a reproduction case as possible. 

When the customer sees an issue, getting their logs, screenshots and environment data will often show the root cause of the problem. You can get this information through email or chat, but a call is usually the quickest way to access this information.

Having a template email or call script to get this information in place will ensure a new support engineer can gather all the essential data. They can use this data to consult with the other engineers if they need assistance.

With this information, an engineer will be able to report the issue without needing to reproduce the issue themselves, drastically reducing the time taken to resolve the issue.

Tip 3: Where possible process the issue into an email

When you have all the information, you may need from the customer; It is often best to halt direct communication when you are investigating the issue.

If you are on a call or chat with the customer, filtering through log files and attempting to reproduce the issue can be a demanding process. Often it is better to convert the call or chat with the customer into an email. The customer will typically understand if you tell them you will get back to them when you know more about the issue.

Having to only focus on finding the issue removes any distractions. Even if finding the issue is your sole task, it may take hours or in extreme cases days to find the exact cause.

Tip 4: When reporting the issue, be clear on its priority

So now you have your issue, this process could have taken you five minutes or five days. At this point, the development team must be notified.

How the team is notified will change based on the process within the engineering team. Often the two conventional approaches are to raise an alert in a chat room or create an engineering ticket.

For a severe/blocking issue such as a service being unavailable, raising an alert in the office chat will alert the engineers, and they can restart the services as appropriate. It may be they already know there is an issue and are investigating.

For an issue in the product, like missing data or a page in the UI erroring; A ticket to fix the product must be created. The priority of an issue is often not something you as a support engineer can control, but you can advise.

The priority is based on several factors, such as:

  • How many customers it affects
  • What it prevents a user from doing
  • If the issue can be worked around
  • Who reported the escalation

For example;

  • If the issue has been reported into support five times in the last 24 hours, this is something hitting a lot of customers. Not fixing the issue right away will cause the number of reports for the problem to build up in support.
  • If the issue prevents the user from logging in, or from seeing any data in the software, this has a higher priority than if it prevents them from clicking a link to the documentation.
  • If a user has to uninstall your product to continue their task, this has a higher impact. If they have to refresh every 6 hours to get the UI working, it should be fixed, but it can wait.
  • If the issue is reported by a customer who generates 60% of the revenue for your company, it must be treated as a higher priority than a customer who is on a free trial.

You should consider these factors when creating a ticket and your rationale for your suggested priority should be documented on the ticket. This will give the engineers some context for when they will start work on the issue.

Tip 5: Keeping the customer up to date on the issue

As soon as the issue has been reported, it becomes something you as a support engineer has no control over. Until the developers resolve the issue, all you can do is keep the customer updated on changes.

It is essential to let the customer know the issue has been reported. If you have a ticket ID or public issue board providing them with the link to this means they can check the status themselves whenever they need.

Promising hard deadlines on when the issue will be resolved can be risky. If an issue is more complicated than it initially appears the fix may be delayed which could potentially annoy the customer. Being vague on a fix date is often the best solution, using “as soon as possible”, “in the next release” or “we hope to fix the issue within the week” are good alternatives to utilise.

Having a specific inbox or state for a ticket waiting on the development team gives you an easy 

If it has been a while since the ticket was created, it is often beneficial to let the customer know they have not been forgotten.

When the developers have resolved the issue, you can finally notify the customer and resolve the ticket. This entire process could take less than an hour, or it could take months. However long it takes you to get the satisfying feeling of making the customer happy.

The best tool for Diagnosing issues with CF/Tomcat

“The best tool for Diagnosting issues with CF/Tomcat”

What do you like best?

Lets you dig into running apps and stack traces and find causes for slow running pages and hangs and kill stuck threads.

What do you dislike?

Can be very daunting and complex to get to grips with.

What problems are you solving with the product? What benefits have you realized?

We used FusionReactor with ColdFusion and Lucee application servers.

Read review on G2

Start free trial

Just as useful as a development tool as it is for production debugging

Just as useful as a development tool as it is for production debugging

What do you like best?

FR is very polished with tons of data. Automatic JDBC wrapping takes zero setup and nearly every screen or dashboard is customizable. I use FR to debug queries that have run, how long they took, and even to fish out long running requests. I always use it when performance testing, and it has excellent reporting on the most hit pages and DB calls in my app. The profiler is the best tool I’ve never seen to tell me exactly what a request did after it’s done executing by pinpointing the exact lines of code in the stack traces that spent the most time.

What do you dislike?

FR is not free like other tools, but it also offers immensely more features once you get to know it. Now that they offer a cheap developer license, it is much more accessible.

Recommendations to others considering the product:

There is a 2 week trial you can use for free. The simplest installation method is via the commandbox-fusionreactor module for CommandBox CLI.

What problems are you solving with the product? What benefits have you realized?

I use it for general web development to track the processing of Ajax calls and REST APIs that can’t output debug information easily to the browser. I use it as a companion tool to JMeter when performance testing to track web request and JDBC throughput as well as response times, status codes, and errors. I’ve used it to find production errors, memory leaks, and performance issues as well. It also can notify me of long running requests so I have a heads up immediately if my site has slowed down. FR Cloud also serves as a consolidated place for metrics from my Docker swarm.

See review on G2

Start a Free FusionReactor trial

Couldn’t do without it!

What do you like best?

The ability to be able to see instantly exactly what is going on with my applications, in real time, and to be able to quickly and efficiently pinpoint and debug issues all in one package.

What do you dislike?

There is very little not to like. The only thing that would make it better would be if it was free!

What problems are you solving with the product? What benefits have you realized?

Application bottlenecks, garbage collection tuning, badly performing database queries, and even the odd bug in the application server have personally all been successfully solved using FusionReactor.

See review on G2

Get a Free FusionReactor trial

FusionReactor is Enlightening


What do you like best?

ability to quickly identify issues quickly

historical logs and trends using powerful graphing tools

What do you dislike?

having to install and manage agent updates (although it is relatively easy)

What problems are you solving with the product? What benefits have you realized?

finding errors in applications

find slow performing applications

Start your free trail on up to 3 servers

See full review on G2

Must have tool for ColdFusion performance monitoring

What do you like best?

Being able to see all of the request details, e.g. activity, history, long running requests.

The profiler is a killer feature.

What do you dislike?

Not really much to dislike, maybe the profiler UX could be improved (a lot of scrolling).

What problems are you solving with the product? What benefits have you realized?

Several performance issues in production environments under high load. Finding long running queries.

Concurrency tests in combination with Gatling.

Start a Free FusionReactor trial

See review on G2

Mandatory Tool for ColdFusion

“Mandatory Tool for ColdFusion”

What do you like best?

The metrics that FusionReactor provides are by far the most used feature. The ability to drill down and find out specific memory or database issues is invaluable.

What do you dislike?

Could use some additional visualizations.

Recommendations to others considering the product:

Test it out and check out all of the features. You’ll be sold.

What problems are you solving with the product? What benefits have you realized?

Solving database query issues, either hanging or taking too many resources. We’ve been able to focus in on problem queries or processes and get them fixed.

Start your free trial on up to 3 servers

See this review on G2

Has the technology to monitor performance level at a high level working to debug issues working against software

What do you like best?

Has the technology to monitor performance level at a high level working to debug issues working against software.

What do you dislike?

Software shows some grey areas in reference to processing time for performance to complete its initial check.

Recommendations to others considering the product:


What problems are you solving with the product? What benefits have you realized?

Clearing out software’s on computers or company software. Allow analysis to be done efficiently.

Read full review on G2

Start free trial

Reliable developer focused Java application performance monitor

What do you like best?

It has been able to help me analyse,diagnose and keep my servers alive.

What do you dislike?

Nothing, I dislike nothing about it and it has been a great experience.

Recommendations to others considering the product:

I recommend this to any company or organization that want to improve on their data base performance and monitoring.

What problems are you solving with the product? What benefits have you realized?

It has been able to help me monitor Java application server. It has also boost my application performance.

Read full review on G2

Start free trial