The ability to quickly troubleshoot problems with an instance’s heap, cpu, web requests and so much more. The dashboard provides so much information in real-time.
I haven’t found anything to dislike about this product.
I have been able to quickly diagnose slow performance with an instance, with specific scripts causing bottlenecks.
FusionReactor allows me to monitor and quickly troubleshoot my ColdFusion and Lucee servers. You simply should not run an enterprise-grade ColdFusion application without it. I has saved me so much time getting to root cause faster. More uptime for my customers, more free time for me. On rare occasions I have had to reach out to Intergral for service or support, hands down, best support in the business. It’s also reasonably priced, with many flexible licensing options available. Worth every penny.
Sometimes things are not where I expect them to be in the GUI.
Production web applications are incomplete without FusionReactor. Go ahead and install a cheaper subscription if you need it, or even a trial. That way it will be installed when you need it.
FusionReactor helps me determine where the problem lies, whether it be web server, traffic, Java, or database. I’ve solved all sorts of problems with FusionReactor over the last 10 years. It’s also the go-to for our 24×7 monitoring team, allowing us to remotely troubleshoot and diagnose issues quickly.
This summer, we are pleased to offer some special discounted pricing on the Adobe ColdFusion suite! If you purchase before the end of August 2019, you will receive 10% discount on the following Adobe ColdFusion 2018 products – see conditions below.
ColdFusion® 2018 Enterprise Edition – AOO
Part# – US: 65293676JA EU: 65293674FA
Rapidly build and deploy scalable, high-performing web and mobile applications
ColdFusion® 2018 Enterprise Edition (Upsell License FLP CSTD)
Part# – EU: 65293690FA
This license is for customers who wish to upgrade from CF Standard to Enterprise, though you must be currently using ColdFusion® 2018, to use this.
ColdFusion® 2018 Enterprise Edition UPG CF ENT From 1 Version Back
Part# – US: 65293699JA EU: 65293701FA
This license allows you to upgrade from ColdFusion® 2016 Enterprise to ColdFusion® 2018 Enterprise
ColdFusion® 2018 Standard Edition – AOO
Part# – US: 65293630JA EU: 65293629FA
Rapidly build and deploy scalable, high-performing web and mobile applications
ColdFusion® 2018 Standard Edition UPG CF STD 1 Version Back
Part# – US: 65293592JA EU: 65293591FA
This license allows you to upgrade from ColdFusion® 2016 Standard to ColdFusion® 2018 Standard
ColdFusion® Builder 2018 – AOO
Part# – US: 65293525JA EU: 65293527FA
ColdFusion® Builder™ 4 software is the only professional IDE for quickly and easily building ColdFusion applications.
This product has saved so much time and effort. It is solid and seems to have little or no impact on the running of our applications. The interface is clean and easy to use, and there are many monitoring options that cover everything we need. The fairly new log archive viewer has also been very helpful.
In our case, we have many instances and servers, and the licensing can seem a bit expensive, especially for developer licenses.
We use FusionReactor primarily for monitoring. When applications have problems we can see exactly what is running or what was running. Being able to go from requests right down to database queries, object calls, and web service calls, we get a good picture of all requests. We also use it to monitor memory usage.
A summary of the exciting new features and improvements made in FusionReactor 8.1.0
FusionReactor 8.1.0 enhances its already powerful feature set
Our production safe debugger now has an entirely new user interface, you can now see your source code, breakpoints and paused threads in one convenient location so you can debug your application as if you were debugging in an IDE.
In the new user interface, we have combined the breakpoints, sources and paused threads into a single combined view. Offering an experience similar to what you would get in an IDE.
This new view allows for much simpler debugging as all the information you need is in one location. Setting a breakpoint in your code can is now as simple as viewing the file you wish to debug then clicking in the margin, you can still add an exception, field access and method entry breakpoints by clicking new breakpoint.
All your configured breakpoints are configured in a single list to allow for quick modification, where you can set conditions, pause time, firecount and also trigger email alerts as you could previously.
Your paused threads and breakpoint data is now available in one place, meaning if you have multiple breakpoints you are able to switch context between the 2 breakpoints instantaneously.
Our enterprise Dashboard now supports registration for ephemeral instances, meaning you can add FusionReactor instances hosted in the cloud, in docker or any other environment automatically when they start. When your instances connect a tunnel is established between the dashboard and the instance, meaning you can access the user interface of the FusionReactor instance without needing to configure access rules.
We have also performed thorough testing to scalability and ensured that you can run a single dashboard with hundreds of groups and thousands of instances connected simultaneously.
Adding ephemeral instances now uses a new set of system properties, that allow for scaling instances to be connected to the dashboard. A guide for configuring ephemeral instances can be found here. Note that with ephemeral instances health checks and custom scripting is not available, but you do gain functionality that allows tunnelling to connected instances without configuring network access rules.
When an instance is connected to the Enterprise Dashboard through ephemeral configuration the communication between the dashboard and the instances has been redesigned. Traditionally the dashboard would send a request to every connected instance via HTTP / HTTPS requests, to do this requires that the dashboard and the instance have a direct connection to one another but we found this was not always possible due to network limitations, particularly in virtualized environments.
Ephemeral instances connect out to a dashboard, in doing so they establish a tunnelled connection, so data can flow between the dashboard and the instance without depending on two-way communication via HTTP. This means if the instance is hosted in a virtual network such as a docker network, were routing to instances via HTTP is not simple you are able to retrieve data for the dashboard.
The tunnelled connection can be used for more than just dashboard data, with the tunnel we are able to stream the whole user interface of FusionReactor through a proxied connection meaning as long as the instance can connect to your dashboard you are able to utilize the full user interface of FusionReactor.
In cases where you have a static server hosting your application, where these servers restarting periodically we recommend using the non-ephemeral connections explained here
Our improved HTTP client tracking gives you access to data such as headers, cookies and JSON data for all of the http requests made within your application.
Headers for the request and the response are now captured as well as cookies so you can more easily trace the source of an error when making a HTTP call. If any JSON is sent or recieved through the HTTP call this is also tracked to the transaction.
This improved tracking makes finding and fixing your services simpler as you will have access to all the data see exactly what was sent and received from your HTTP requests to another service.
FusionReactor now officially supports applications running on Java 12.
You will now receive a banner notification within FusionReactor for available updates. These notifications can be dismissed if you are happy with the version you are currently running.
You can now configure the JSON tracking within the user interface of FusionReactor. Allowing you to enable/disable tracking, smile decoding and the limit of data captured without using file-based configuration.
We now use the FernFlower compiler for application servers running in Java 8 and above, dramatically decreasing the time taken to decompile files.
To upgrade FusionReactor to FusionReactor 8.1.0 head to our downloads page and get the latest installer or installation files and follow the guides listed below:
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
Sitting here and thinking… honestly, I’m missing absolutely nothing and no feature at the moment.
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.
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.
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.
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.
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.
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.
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 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.
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!
Real time monitoring of processes is a huge benefit. Optimising slow processes is a huge plus.
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:
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.
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:
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.
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.
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.
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:
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.
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
FusionReactor are sponsors of Velocity 2019 in San Jose June 10 – June 13 2019.
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.