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

“If you don’t have it yet, get it NOW“

What do you like best?

Don’t know, theres too much… but favourites are:

* That we are totally in control of our application server in Realtime

* What the guys of FusionReactor did add to their products in recent years is absolutely awesome. 5 years ago, we thought we have all we need – and what we get now in the newest version is simply mind-blowing

* The guys of FusionReactor are there for you, high competence in support and very effective sales

What do you dislike?

Sitting here and thinking… honestly, I’m missing absolutely nothing and no feature at the moment.

Recommendations to others considering the product:

Take the time to read the docs and to “play around with this tool – not just jump on the first figures and lists you see. It’s really worth to understand and see all the options and possibilities FusionReactor offers.

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

We are not having internal tec guys, but external DevOps team. With FusionReactor we have the tool in our hands to react before any monitoring would report an outage. We share access to the tool with most developers and get the hints and tips, what to work on first, and what queries or transaction are a threat for the future.

See full review

Start a free trial

The De Facto Standard for ColdFusion / Java Application Monitoring

What do you like best?

FusionReactor is a necessary tool if you’re running a ColdFusion application of any appreciable size. Not helpful, not convenient. Necessary.

It provides insights and alerts that you’re not going to get anywhere else, and in many cases it’s the only tool that’s going to be able to help you track down obscure bugs, memory leaks, or other issues that make you want to pull your hair out. And on top of that, the team behind it is incredibly responsive and always pushing the product forward.

What do you dislike?

The price of the Ultimate Edition is the biggest pain point. Configuration and use within a containerized environment continues to improve, but still isn’t as strong/easy/helpful and the on-premise FR offering.

Recommendations to others considering the product:

If you’re considering FusionReactor, talk to the team there and evaluate the product (it’s free to trial). They can answer your questions and help you get started. There’s no-risk, and the benefits are obvious from the moment you start using it.

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

The benefit is twofold. 1) FusionReactor provides alerting when there are issues with our applications. We set thresholds for memory usage, request quantity, or request length, and we get alerts when they’re exceeded. This is helpful in proactively addressing potential issues. 2) FusionReactor also provides detailed insight into what is going on within applications, which we’ll use when we need to track down the cause of a problem or an area that we’d like to optimize.

See full review

Start free trial

Latest review on G2

What do you like best?

The most helpful feature of FusionReactor is the fact that you can introspect all the requests running in production. You can easily see how much time it takes to run a specific process, identify its pain points and optimise them. What is highly appreciated is also the profiling functionality! You can even profile your app and dig into very low level optimisations which otherwise would be not easily pinpointed!

What do you dislike?

What probably needs more rework is the documentation when you are exporting the java cache files from the FR JVM. I spent quite some time looking into what each value ment, which could have been better documented.

Recommendations to others considering the product:

Since there is a lack of actual debugging tools for ColdFusion, I consider FusionReactor to be the only tool that actually gives you an insight within your application!

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

Real time monitoring of processes is a huge benefit. Optimising slow processes is a huge plus.

See full review

Start a free trial

FusionReactor and Your ColdFusion Queries

In my last article on FusionReactor, I talked about slow pages and how the tool helps you find them. In that article I specifically avoided talking about one of the biggest culprits of slow pages – database queries. My history with ColdFusion goes back to about version 2 and even back then database queries were the primary culprit in poorly performing applications.

There’s multiple reasons why database queries can be a choke point for your application:

• A poor connection to the database.
• A poorly configurated database.
• A poorly configurated table.
• A poorly written query.
• And so forth.

In an ideal world, your organization has a DBA (database administrator) who tunes the database and tables and then crafts a beautiful SQL (or stored procedure) you can simply drop into your application. Unfortunately very few of us live in that ideal world. It’s also very easy to simply ignore the problem. SQL, like any language, let’s you get stuff done quickly and it can be easy to not consider the performance aspects of your query. Like any poorly written piece of code, a “slightly bad” query in a request can then be joined by another slightly bad one and slowly compound into a poorly performing page.

Being that database activity is such an important part of performance, it’s no surprise FusionReactor has specific reporting tools focused on just that area. In this post I’m going to share what that looks like and share some examples of the kind of reports you can find.

JDBC Reports

In my last post, I explained that JDBC stands for Java Database Connectivity. Any time you use a cfquery tag (or queryExecute function), you’re making use of JDBC to allow your ColdFusion templates to speak to a database. Within FusionReactor, you’ll want to start with the JDBC icon on the left:

Under here you’ve got a variety of options:

• JDBC Activity – i.e. what’s going on right now.
• JDBC History – historical activity.
• JDBC Error History – past query errors.
• Activity Graph and Time Graph – a “live” graphical report of JDBC activity.
• Longest Transactions and Slowest Transaction – to be honest this was a bit confusing. Wouldn’t the longest transaction also be the slowest transaction. The “Longest” report will show the transactions that have taken the longest to execute, no matter how long. The “Slowest” report is a report of all transactions over a particular threshold. So it may be possible that you have nothing there as your queries are performant, but the “Longest” report will still rank them for you.
• Trans. By Mem – reports on queries with high memory usage.
• Stack Trace Filter – it’s possible that multiple different things are making use of your database. The stack trace filter lets you reduce the amount of “noise” you may get from other applications. By default there’s filters set up for .cfm, .cfc, and .jsp.
• Databases – this gives a really cool report on how you’re using your databases. I’ll be sharing an example of this later.
• Settings – this is where you can configure how FusionReactor logs and monitors your database transactions

Examining Database Requests

Let’s take a look at how FusionReactor reports your database requests. First we’ll open the “JDBC History” page. Remember that the first option shows a “live” version and unless your site is actively getting hits, you won’t see anything.

As with the previous examples I’ve shown from FusionReactor, take note of the controls on the top right allow for filtering, reloading, and so forth. What isn’t obvious from the screen shot is that the “All SubFlavors” button actually lets you filter by the type of query, select, insert, and so forth. That’s pretty neat.

The main table of data reports on the app that was being used (I’m just working in my default Lucee home directory) and the SQL that was used. You can see the file name as well as timing information. Note the Time column which shows you how long the particular query took.

Notice how the SQL is reported as well. One of the features of FusionReactor is to automatically replace queryparam values with their ‘real’ values when reporting on the query. You can enable or disable this feature under the “JDBC/Settings” page. While this is a cool feature, it means it’s difficult to see where you’ve forgotten to use queryparams. I’ve reported to the FusionReactor folks that it would be nice if it was obvious when such a replacement has happened, maybe by using bold tags or some such. That way if you a query is not using queryparams it will be easier to find and correct.

The detail view is very deep. Here’s the main tab of information:

There is almost an overwhelming amount of information here, but I’d probably focus mostly on the execution time values under JDBC and the memory section. Here’s the JDBC tab:

As before, there’s a lot of information, but I’d focus in on the row count. If you’ve ever seen someone select everything from a table and then use ColdFusion conditionals to restrict what is shown, then you know why this is a problem. The query is returning a mind boggling twenty-seven thousand rows. There’s no way that was intentional. (Ok, for my test it was, but you get my point.)

The final tab, Relations, gives you a good look at the query within the page it was working. For example, this page had multiple queries and you can see how they impacted to the overall total page performance.

Finding Query Errors

Let’s now take a look at how FusionReactor reports errors. To test, I ran two requests with simple SQL errors, one trying to get a field that didn’t exist and one against a table that didn’t exist. Here’s how the main error history page shows the results.

For the most part this is fairly similar to the history report, except now you can get a short report of the error. As a test, I shut down my MySQL server and ran my request again. As expected, I got an error. However, that error does not show up in this report. It does show up under “Request/Error History” though. My guess is that since Lucee couldn’t ever speak to MySQL, a JDBC transaction was not made. That makes sense to me, but just keep in mind that you may want to check both error reports when hunting down issues.

The detail view is the same as before but with a new tab called “Error Details”:

As always, I find the stack trace a bit hard to parse, but the error details on top seem nice and clear to me. Notice the debug button on the right. This allows you to add a breakpoint for future errors like this. I’m going to talk about FusionReactor’s debugging features later.

JDBC Graphs

FusionReactor offers two reports of JDBC activities. The first is just raw activity (Activity Graph) while the second (Time Graph) reports on how long queries are taken. Both default to a “live” view but also let you look at specific time ranges. Here’s an example of both, but note the graphs are a bit boring for me as this is just my local laptop.

Finding Those Bad Queries

As I explained above, FusionReactor provides two reports to help you find slow queries. “Longest Transactions” will simply list out all your recorded transactions sorted by time. “Slowest Transactions” focuses on queries that are slower than a defined threshold. You can set that threshold in the settings panel, under “History”. The default value is 3 seconds. There’s quite a few interesting things you can tweak in the settings panel so I recommend taking a look at it. For my laptop, with again a simple test and not “real” data, here’s the “Longest Transactions” view:

Your Database Use

The final thing I want to show is probably the coolest. The “Databases” report gives you a report on how you are using each of the datasources on your server. It breaks it down by type of operations as well as table usage. It also reports on the queries sent to the datasource.

This is just freaking cool as heck to me. While I think most of us will deal with one database per server, larger more complex applications could be dealing with numerous databases. A report like this could help you figure out if one, or more, are perhaps being used rarely enough to be decommissioned or transitioned to one main database. The table report could be really useful too. I’ve dealt with projects hitting a database with a huge amount of tables. This can give you an idea of what’s actually being used.

Summary

As I said in the beginning, database issues tend to be the number one culprit when it comes to poorly performing ColdFusion sites. I think the JDBC set of features in FusionReactor will probably be your top tool for helping improve your applications. I know this is where I’d start looking!

Thanks to our special guest author Raymond Camdem for writing this article for us.

Blog : www.raymondcamden.com
Twitter: raymondcamden

FusionReactor are sponsors of Velocity 2019 in San Jose June 10 – June 13 2019.

Win Bronze Tickets

Winning is easy, simply

• Start a new 14 day FusionReactor trial
• Tweet about your trial using the hashtag “ImTryingFusionReactor”

This year Velocity is all about building, managing and scaling cloud-native systems.

To get ahead today, your organization needs to be cloud native. The 2019 Velocity program will cover everything from Kubernetes and site reliability engineering to observability and performance to give you a comprehensive understanding of applications and services—and stay on top of the rapidly changing cloud landscape. Learn new skills, approaches, and technologies for building and managing large-scale, cloud native systems, and connect with peers to share insights and ideas.

The 2019 program focusses on –

• Cloud, Cloud Native, and Infrastructure
• Serverless
• Containers, Kubernetes, and Microservices
• Monitoring, Observability, and Performance
• SRE and DevOps
• Distributed Data and State
• Security
• Systems Engineering and Architecture
• Leadership
• Emerging Tech (Machine Learning, AI, Blockchain)

Bronze 2-Day Pass Includes:

• All sessions (Wed & Thu)
• All keynote and plenary presentations
• Sponsor Pavilion and all events held there
• All on-site networking events
• Lunch (Wed & Thu)

Terms and Conditions

• No purchase required
• You must download, install and fully activate your trial using your work email address
• When the tweet is selected the winner will be asked to prove trial by giving us your valid licence number
• Only one entry per person
• By entering the prize draw you are opting into marketing and your details may be used in publicity
• Prize draw will take place on 1 June 2019
• No cash alternative will be offered
• Judges decision will be final

Have you wished you could change the name given to your monitored instance in FusionReactor (the name that appears in the UI and various reports/emails)? Did you know you could change it easily, on the fly, from within the instance and without need of restarting your instance?

(more…)

The FusionReactor team are delighted to announce that we are sponsoring the  O’Reilly Velocity conference 2019 in San Jose.

We are offering a 25% discount on all event tickets – you can receive your discount, using the following coupon – FusionReactor25. To use the discount code visit the O’Reilly Velocity registration page.

We will be demonstrating FusionReactor 8 at the event and introducing our latest features including our root cause analysis tool.

This year Velocity is focussing on Performance Resilience and Security. To get ahead today, your organization needs to be cloud-native. The 2019 Velocity program will cover everything from Kubernetes and site reliability engineering to observability and performance to give you a comprehensive understanding of applications and services—and stay on top of the rapidly changing cloud landscape. Learn new skills, approaches, and technologies for building and managing large-scale, cloud-native systems, and connect with peers to share insights and ideas.

Get expert insights and essential training on:

• Kubernetes
• Monitoring, Observability, and Performance
• Building Resilient Systems
• Building Secure Systems
• Distributed Data
• Leadership
• Building Cloud Native Systems—New for 2019
• Production Engineering, SRE, and DevOps
• Serverless
• Emerging Tech—New for 2019

See the full O’Reilly Velocity 2019 Agenda

Get 25% Discount

Don’t forget to use the FusionReactor25 discount code at registration and get a 25% discount. 

Finding (and Fixing) Your Slow ColdFusion Pages with FusionReactor

In my last article I described how I wanted to help introduce FusionReactor to ColdFusion developers with a special focus on helping solve practical problems and navigating terminology that may not be terribly familiar with if you haven’t used Java before. In that first article I focused on using the FusionReactor portal to find and diagnose pages that were throwing errors. In this follow up I’m going to highlight another great use of FusionReactor – finding slow pages.

Slow pages can be difficult to find. A page that runs fast on your local server could run much slower in production. A page with a complex set of inputs, like an advanced search field with numerous filters, can only run slow when a particular unique set of choices are made. Sometimes your code can be absolutely perfect, but an external factor is the culprit. Perhaps you’re integrating with a database that you have no control over, or maybe you’re using a third party API that has performance issues of its own.

In this article I’m going to highlight multiple examples of slow pages and how FusionReactor can help you find, and hopefully fix, each of them! Ready?

Finding Your Slow Requests

Before we begin writing some horribly slow code (I’m a pro at this!), let’s look at where FusionReactor displays these requests. In your left hand menu, under Requests, select Slow Requests:

You’ll notice the display is split between currently running slow requests and requests that have already finished but were considered slow. Which begs the question – what’s “slow”?

Under Requests, go to Settings, and then select WebRequest History. Here you will find multiple settings you can configure including what the threshold is for something being considered slow. In my FusionReactor 8 instance this was set to 8 seconds.

To me this is a bit high and I’d consider switching it to a lower number. Performance is an incredibly important topic for web sites and while most of the discussion concerns what happens on the client side (rendering of JavaScript, styles, and so forth), the browser can’t even render anything until you actually return the HTML. While there’s a lot of resources out there on how fast a page should load, the general consensus should be two seconds. If your ColdFusion page is taking more than that to return a result to the browser, than you have already failed. (Because remember, the browser still has to work with your result to render it!)

And just to be re-iterate, this is important even if your ColdFusion page isn’t returning markup. If you are using ColdFusion to power a client-side application with JSON data, then you still need to ensure you’re returning a speedy response.

So yes, this is very, very important stuff. I’d go ahead and change that number from 8 down to 1 or 2. See what works best for you.

Another view of your slow requests is the Longest Requests view, also found under the Requests menu:

This is a sorted view of requests with the slowest being displayed first. This is not filtered by the Slow Request threshold but covers everything. Also note it includes non-ColdFusion files as well!

Bring the Slow

Let’s start off by demonstrating two slow pages. One is always going to be slow and one uses an external resource that will also always slow. Here’s the first one:

<h1>Slow Testing</h1>

Go to sleep...<br/>
<cfflush>
<cfset sleep(30000)>
And done.

It simply uses the sleep function to pause the execution for 30 seconds. If you’ve never seen cfflush before, it tells the ColdFusion server to send out existing output to the browser. As a user, you would see the initial HTML, the browser continue to load, and then the rest of the results.

This will definitely cause a slow request to be logged. Unfortunately, unlike the error conditions we saw in the previous article, it’s a bit more difficult to diagnose. Let’s see why. First, here’s the details page for this particular request.

There’s a few things to note here. First, the slow time is nice, bold, and red. You can’t miss that and that’s a good thing. Now make note of JDBC. Don’t know what that means? JDBC is the acronym for Java Database Connectivity. Basically this is how ColdFusion speaks to databases. I started ColdFusion development way back in 96 or so, before ColdFusion ran on Java, but even back then the biggest culprit for slow requests was issues at the database layer. We aren’t doing any database requests on this page but nine times out of ten you want to turn your focus here. Every single one of those metrics is crucial and can be a flag for an underlying issue.

As a real example of this, I was working with a client and discovered they had about 1000+ database queries being run in a request. How did this happen? They had queries in an Application.cfm file, queries in a header file, queries in a file loaded by a header file, and so on and so on. 90% of these queries were the exact same query run multiple times. They weren’t stupid – they just didn’t realize everything going on in one particular request. This can happen as a web application grows larger and more complex, and is yet another reason to consider a tool like FusionReactor!

Alright, but this template isn’t slow because of a query. What do you do next? Click on the Profiler tab next. (And note, back in the main list of slow requests, every slow request has a direct link to this particular view.)

So in this case, you can’t really get to a particular line of your template or ColdFusion method. But even if you’ve never used Java before, seeing 100% correlated to java.lang.Thread.sleep should give you a clue as to which particular tag was the issue.

Let’s consider another example, this time the ColdFusion template is using a third party API built on a serverless platform:

<h1>Slow Testing 2</h1>

Call API...<br/>
<cfflush>

<cfhttp url="https://wt-c2bde7d7dfc8623f121b0eb5a7102930-0.sandbox.auth0-extend.com/slow">
<cfdump var="#cfhttp#">

In this case, the serverless function I’m hitting is using setTimeout to delay the response for 3001 milliseconds. This page is going to be slow, but it’s something out of ColdFusion’s hands. (But to be clear, this is still something you could address. Can you cache the result? Can you fire it via a scheduled task and store the result locally? You’ve got options!) So how is this reported in the profile?

In this example, you can see two things that stand out – first Http.java and then Dump.cfc. The later clearly refers to the cfdump tag which typically wouldn’t be run in production. But Http.java should definitely be enough of a clue to tell you where the issue is. Of course, you may run into an issue if you have multiple HTTP calls in your ColdFusion page. In that case you’ll need to do further testing to see if you can determine the culprit. The important thing to note though is how FusionReactor got you nearly 100% of the way there!

What Next?

In this article I simply introduced the Slow Request views in FusionReactor and used it to find a few problem scripts that should be fixed. In my next article I’m going to turn my attention to database specific issues and show you how FusionReactor helps there. As always, leave me a comment below if you have any questions!

Getting Started with FusionReactor (for ColdFusion Devs)

As a ColdFusion developer, you may know that it’s running as a J2EE server but also may have zero to no idea what that means in a practical sense. ColdFusion has always been easy to use, especially for developers from a non-traditional background, and this sometimes means there’s aspects of the platform that aren’t quite as easy to understand as others. A great example of this are the things that are more Java-centric. FusionReactor integrates with your ColdFusion server from a Java-perspective, which means it maybe uses terms that may be unfamiliar to the developer who only knows CFML.

And yes, you can, and should, consider learning more about Java, but at the same time, we don’t always have the opportunity to pick up a new language! You may need to get things working now and what I’d like to do in this article is help you, the CFML developer, better understand how Fusion Reactor reports issues and get you to a point where you can quickly identify (and fix!) your problems.

My assumption is that you’ve already installed FusionReactor. If not, head over to the downloads and grab a copy. You can get your trial key there and use it to test and evaluate the product. As I’m writing this for CFML developers who aren’t familiar with Java, I strongly urge you to use the “Automated Installers”. I’m testing on a Windows machine with Lucee but obviously you can use Adobe’s ColdFusion product as well. I’m also assuming you’ve set up a FusionReactor instance pointing to your ColdFusion server so you can start monitoring and debugging. Once you have, you can open that instance.

Let’s Break Something!

There’s a heck of lot to FusionReactor but in this article I’m going to focus on just one particular aspect – errors. Luckily, I’m a born error creator. One of the best. I should probably get endorsed on LinkedIn for writing buggy code. Thankfully that’s made me something of an expert in debugging a file and figuring out what went wrong. That’s rather easy while I’m writing and testing code. It isn’t necessarily helpful when the code is in production and being used by the public.

Let’s consider a simple template that seems to be bug free.

<h1>Debug Testing</h1>
url.name = #url.name#
len is #len(url.name)#

This script simply outputs the value of a variable passed in the query string, `name`, and then reports the length of the value. Given that the file is named `ray.cfm`, you can test this like so:

<p>
http://127.0.0.1:8888/ray.cfm?name=raymond
</p>

Which gives you:

Ok, astute readers will recognize the issue with this code. What happens when you don’t pass the `name` value in the query string?

In this case it’s probably obvious what you did wrong. This is easy enough to fix by either setting a default or adding logic to redirect when the value isn’t defined, but what if you miss this and deploy the code to production?

Assuming you’ve done that and got a report from your users (or even better, your manager at 2AM on Saturday), let’s quickly see how FusionReactor can help you find this issue.

To the Requests, Batman!

Alright, so you’ve got a report about something going wrong. In a perfect world, that report includes the URL, query string, what the user was doing, the phase of the moon, and more. Also know that ColdFusion has excellent built-in error handling that can send you detailed reports… if you added that to your project.

But let’s pretend you have nothing, or something as useless as this:

“Hey, the web site is broke.”

Let’s begin by looking at the history of requests in the FusionReactor instance. In the left hand menu, mouse over Requests and select History:

There’s a lot to this table, but let’s focus on a few things in a somewhat descending order of importance:

* Status Code: When a request is made over the web, a server returns a code that represents how it was handled. `200` represents a good response. `500` is a bad response. (And note how FusionReactor is flagging that already!) There’s a great many different status codes out there and you should take a look at them sometime.
* URL: This tells you the URL of the request and normally, but not always, will give you an idea of the file that was requested. Many people will use URL Rewriting to “hide” the fact that ColdFusion is running. In this case it’s pretty obvious: `http://127.0.0.1:8888/ray.cfm`. Given that the URL path is `/ray.cfm` I can figure out that it’s the `ray.cfm` in my web root. But you can’t always count on it being that easy. Also note that the error in this view is Java-related: `lucee.runtime.exp.ExpressionException`. Don’t worry – we’re going to dig into this.

That was the general request view, but most likely you want to focus in on just the errors. In that same left-hand nav, you can do so by selecting: Requests, Error History:

This is showing the same information, just filtered to requests with errors.

Let’s Get the Error

Alright, so you’ve found a request with an error, how do we diagnose it? On the right hand side is a “book” icon which will load details. Let’s do that and see what we get.

Holy. Crap.

Overwhelming, right? Everything there is useful, but there’s a lot you don’t need right now in order to get to the issue at hand. Begin by clicking “Error Details” under “Transaction Details”

The first two blocks give you a good idea of what’s going on. `key [NAME] doesn’t exist` is a clue that your code tried to use a variable that didn’t exist. If the `key` aspect doesn’t make sense, it may be helpful to remember that ColdFusion variables are scopes, or structs, and when you access `url.something`, you’re trying to use a particular key in that scope.

Alright, so we’re closer. Now our particular ColdFusion file is very short but imagine a much larger template, how would we find where the error was thrown?

The bottom part of the template is the Java Stack Trace…

The stack trace can be overwhelming. In this case, you can slowly read line by line looking for a line mentioning a CFM file:

ray_cfm$cf.call(/ray.cfm:5)

In this case, `ray.cfm` is the file name (pretty obvious) and `5` is the line number:

url.name = #url.name#

In theory, you’re done, but FusionReactor can help you a bit more. In the left hand navigation, look for the Debug menu and select Sources.

Out of the box, FusionReactor doesn’t have any defined sources, so simply click the “Add” button and specify your web root. (Note that you can have more than one, and most likely you’ll have one root directory per application.)

In the screenshot above I’ve simply specified my Lucee root.

When you’ve done that go back to the Requests view, find that broken request, and get to the stack trace again.

Now if you click on the method call, which is `ray_cfm$cf.call`, FusionReactor will actually be able to show you the file itself!

Notice how FusionReactor even highlights the line in the file!

But Wait – There’s More!

FusionReactor contains a huge set of tools, but in this article we focused in specifically on helping diagnose an error in production. In the next one we’ll start expanding our use of FusionReactor and look for more performance related issues.

Thanks to our special guest author Raymond Camdem for writing this article for us.

Blog : www.raymondcamden.com
Twitter: raymondcamden

FusionReactor announces the immediate release of FusionReactor 8 embracing automated root cause analysis

FusionReactor 8 (FR8) has been designed to make a developers life easier and dramatically reduce the time required to figure out what’s gone wrong in a production environment.  The game-changing “Events Snapshot” capability takes the hard work out of debugging by automatically tracking all latency and thread errors and presenting the developer with insight immediately after the error has occurred.   

For decades, developers have had to struggle with analyzing log files to figure out why production software is broken – the capability in FusionReactor dramatically revolutionizes this process, by automatically capturing detailed, structured information at the point that errors occur.  FR8 will capture variable state across the whole scope of the stack, logged information and even instantly decompiles your code to show you the full context of where and why something is broken.

“In FR6 we introduced a Java debugger, which can be safely and securely used in production environments, FR8 takes this a step further and automates the process so that issues can be instantly identified allowing developers to spend less time looking for defects and more time creating new code” David Tattersall CEO

Richer metric information

FusionReactor will now automatically capture any information which has been written to logs using one of the standard logging API’s, such as cflog, log4j 2, logback, SLF4J and Apache Commons Logging.

Data-interchange information which is formatted in JSON (JavaScript Object Notation) is now captured by FusionReactor. Today, when any two applications communicate with each other across the internet, odds are they do so using JSON.  The ability to load and manipulate JSON feeds from other sites via AJAX has become a major part of the developer toolkit. FusionReactor will now auto-detect all transactions which pass JSON either in or out.

Start a free FR8 trial

Read Release notes