This article applies to FusionReactor On-Premise customers running FusionReactor 5 to 7 only. These customers are identified by their license keys which do not begin with CLOUD-. Some users run FusionReactor behind restricted firewalls which do not allow all outbound connections. In this case, these users may need to add specific firewall rules to allow FusionReactor to communicate with our licensing infrastructure.

PLEASE NOTE THAT THIS TECHNOTE IS VALID IF YOU ARE RUNNING FUSIONREACTOR 5.0.0 – 7.4.3 ONLY

To configure FusionReactor versions 8 and above see: FRS-454

Using DNS Firewall Rules

FusionReactor licensed with on-premise (non-Cloud) licenses requires access to the following DNS address in order to communicate with our licensing service

• data.intergraldata.com – port tcp/80 and port tcp/443

This address resolves to one or more IP addresses which are attached to a load-balanced cluster.

Using Static Addresses

If you are unable or unwilling to use the dynamic DNS rules above, we have provided two static IP addresses which can be used for this service.

• 75.2.12.72 and 99.83.190.216 – port tcp/80 and port tcp/443

After enabling this firewall rule, the following -D option needs to applied to your JVM environment, to instruct FusionReactor use this address for licensing:

-Dfrlicenseservice=api-intergraldata-static.fusionreactor.io

Locked-Down Environments

If you are using a non-standard Java security policy, you may have to add rules to it to allow FusionReactor to connect to these services. The form of these rules is:

permission java.net.SocketPermission “api-intergraldata-static.fusionreactor.io:443”, "connect, accept, resolve”;
permission java.net.SocketPermission “api-intergraldata-static.fusionreactor.io:80”, "connect, accept, resolve”;
permission java.net.SocketPermission “18.200.148.71:443”, "connect, accept, resolve”;
permission java.net.SocketPermission “18.200.148.71:80”, "connect, accept, resolve”;
permission java.net.SocketPermission “52.208.77.63:443”, "connect, accept, resolve”;
permission java.net.SocketPermission “52.208.77.63:80”, "connect, accept, resolve”;

Manual Licensing

Should FusionReactor be completely unable to communicate with our licensing service, you should note the following:

• FusionReactor will require to be activated by hand using an activation code provided by the software. This must be done from a computer which does have internet access using the FusionReactor Portal. The resulting activation key must be entered back into FusionReactor.
• The activation key generated is valid for 10 minutes, after this point FusionReactor will reject the key.
• Your manual activation will be valid until the expiry date of the license in the case of subscription license and forever in the case of a perpetual license.

Upgrading to FusionReactor Cloud

Customers upgrading from FusionReactor On-Premise to FusionReactor Cloud should also read technote FRS-418: FusionReactor Cloud Firewall DNS and Static IP address rules (Fusion Reactor 5.0.x – 7.4.x)

FusionReactor Cloud Transport: Transaction Shipping

When licensed with a CLOUD-* key, FusionReactor will connect to FusionReactor Cloud and begin shipping metric data periodically.

Apart from numeric metrics like memory and CPU Usage, FusionReactor will also ship certain transactions to FusionReactor Cloud. These key transactions are visible in the Transactions tab, after selecting a server.

Transaction Shipping

Master (also known as ‘parent’) transactions are selected for shipping to the cloud based on a set of criteria buckets. There is one set of buckets per application. Only the first 100 distinct applications are tracked per minute, and there’s also a global limit of 100 master transactions per minute too.

• Error Transactions – the first 4 transactions to close in error (e.g. web requests resulting in 500-series results) are selected.
• Long – the longest 4 transactions which ran longer than 500ms are selected.
• Slow – the longest 4 transactions which were slower than the threshold set in FusionReactor > Requests > Settings > WebRequest History > Slow Request Threshold are selected.

All of the subtransactions of these masters are also kept and transferred (but see the section on Subtransaction Trimming later).

Effect of Limits

If a transaction is seen which would fall into one of these buckets, but:

• It belongs to the 101st or laster application to be seen that minute, or
• There are already 100 transactions in all buckets across all applications,

… then that transaction will not be sent to the Cloud.

Subtransaction Trimming

Transactions can have a virtually-unlimited quantity of subtransactions. For example: a ColdFusion page (which is tracked as a parent transaction) can perform a CFHTTP call to a REST endpoint. That call will be detected and tracked as a subtransaction on the CF page. This could happen multiple times and they would all be tracked by FusionReactor.

In order to keep the size of shipped data within an acceptable margin, a culling algorithm ensures that at most, 500 subtransactions are shipped to the cloud.

The algorithm looks at culling subtransactions of the long bucket first, then slow, and then error last. We do it in this order so that the error transactions are less likely to be trimmed because they’re most important.

If subtransactions were trimmed from the shipped data, this will be indicated in FusionReactor Cloud.

FusionReactor Cloud Transport: Transaction Shipping

When licensed with a CLOUD-* key, FusionReactor will connect to FusionReactor Cloud and begin shipping metric data periodically.

Apart from numeric metrics like memory and CPU Usage, FusionReactor will also ship certain transactions to FusionReactor Cloud. These key transactions are visible in the Transactions tab, after selecting a server.

Transaction Shipping

Master (also known as ‘parent’) transactions are selected for shipping to the cloud based on a set of criteria buckets. There is one set of buckets per application. Only the first 100 distinct applications are tracked per minute, and there’s also a global limit of 100 master transactions per minute too.

• Error Transactions – the first 4 transactions to close in error (e.g. web requests resulting in 500-series results) are selected.
• Long – the longest 4 transactions which ran longer than 500ms are selected.
• Slow – the longest 4 transactions which were slower than the threshold set in FusionReactor > Requests > Settings > WebRequest History > Slow Request Threshold are selected.

All of the subtransactions of these masters are also kept and transferred (but see the section on Subtransaction Trimming later).

Effect of Limits

If a transaction is seen which would fall into one of these buckets, but:

• It belongs to the 101st or laster application to be seen that minute, or
• There are already 100 transactions in all buckets across all applications,

… then that transaction will not be sent to the Cloud.

Subtransaction Trimming

Transactions can have a virtually-unlimited quantity of subtransactions. For example: a ColdFusion page (which is tracked as a parent transaction) can perform a CFHTTP call to a REST endpoint. That call will be detected and tracked as a subtransaction on the CF page. This could happen multiple times and they would all be tracked by FusionReactor.

In order to keep the size of shipped data within an acceptable margin, a culling algorithm ensures that at most, 500 subtransactions are shipped to the cloud.

The algorithm looks at culling subtransactions of the long bucket first, then slow, and then error last. We do it in this order so that the error transactions are less likely to be trimmed because they’re most important.

If subtransactions were trimmed from the shipped data, this will be indicated in FusionReactor Cloud.

Using the new download location for FusionReactor, you will guarantee to always download the latest available version of FusionReactor for your platform.

We highly recommend you use this link if possible, particularly if you are using automatic deployment tools or spun up virtual machines. You can then ensure you have all the latest features and bug fixes available to you and avoid the hassle of manually updating all your instances.

The links for each platform are listed below:
Manual Installation files
FusionReactor Single Jar – https://intergral-dl.s3.amazonaws.com/FR/Latest/fusionreactor.jar
Debug Native Libraries – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/debuglibs.zip
Debug Library for Windows (frjvmti_x64.dll) – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/frjvmti_x64.dll
Debug Library for Mac OS (libfrjvmti_x64.dylib) – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/libfrjvmti_x64.dylib
Debug Library for Linux (libfrjvmti_x64.so) – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/libfrjvmti_x64.so

Installers
FusionReactor Full Installer (Mac OS) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_macos.dmg
FusionReactor Full Installer (Linux 64 bit) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_linux-x64.sh
FusionReactor Full Installer (Windows 64 bit) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_windows-x64.exe
Pre Configured No JRE (Unix) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_unix_nojre.tar.gz
Pre Configured No JRE (Windows) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_windows_nojre.zip

To find the exact version of FusionReactor is the latest, you can download the version.json file
You can download this file at https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/version.json

Using the new download location for FusionReactor, you will guarantee to always download the latest available version of FusionReactor for your platform.

We highly recommend you use this link if possible, particularly if you are using automatic deployment tools or spun up virtual machines. You can then ensure you have all the latest features and bug fixes available to you and avoid the hassle of manually updating all your instances.

The links for each platform are listed below:
Manual Installation files
FusionReactor Single Jar – https://intergral-dl.s3.amazonaws.com/FR/Latest/fusionreactor.jar
Debug Native Libraries – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/debuglibs.zip
Debug Library for Windows (frjvmti_x64.dll) – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/frjvmti_x64.dll
Debug Library for Mac OS (libfrjvmti_x64.dylib) – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/libfrjvmti_x64.dylib
Debug Library for Linux (libfrjvmti_x64.so) – https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/libfrjvmti_x64.so

Installers
FusionReactor Full Installer (Mac OS) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_macos.dmg
FusionReactor Full Installer (Linux 64 bit) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_linux-x64.sh
FusionReactor Full Installer (Windows 64 bit) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_windows-x64.exe
Pre Configured No JRE (Unix) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_unix_nojre.tar.gz
Pre Configured No JRE (Windows) – https://intergral-dl.s3.amazonaws.com/FR/Latest/FusionReactor_windows_nojre.zip

To find the exact version of FusionReactor is the latest, you can download the version.json file
You can download this file at https://s3-us-west-1.amazonaws.com/intergral-dl/FR/Latest/version.json

Introduction

We recently had a performance issue in FusionReactor where a user saw high CPU when running FusionReactor reported into our technical support team. Upon investigating the issue, we found this was due to both FusionReactor and the Adobe PMT tracking sessions by making a large number of calls to the Redis database.

In FusionReactor 8.2.3 we released a fix that will stop session tracking if Redis sessions are in use. The result of this is that you will only see an overview of total session activity, there are no metrics for the active, created or destroyed sessions from ColdFusion.

In the Sessions page of FusionReactor you would only see something like:

Abode have an open bug for this (https://tracker.adobe.com/#/view/CF-4205489), this fix has been scheduled for a HF7 release. Until Adobe fixes the issue, we do not enable full session tracking when using Redis sessions in ColdFusion 2018.

To confirm if you are affected by this issue

Go to Transactions > Activity and filer by Redis transactions. You will see something similar to:

This performance issue is caused by two factors:

• A bug in FusionReactor that every second sends 2 get requests to Redis for each active session
• A bug in the Adobe PMT that every second sends 1 get request to Redis for each active session

These Redis calls are all tracked by FusionReactor which slows down the performance of the server due to the volume of requests when a ColdFusion server has a high number of sessions even if these sessions where created on a different ColdFusion server but are using the same Redis server for the sessions.

The Workaround

To work around this issue please upgrade to version 8.2.1 or higher of FusionReactor which disabled session tracking from FusionReactor. Note that in this version, there will still be one set of Redis calls made to Redis if you are viewing the session information in the Adobe PMT.

When the bug for session tracking is fixed in ColdFusion 2018, we will update FusionReactor to reenable session tracking.

Introduction

We recently had a performance issue in FusionReactor where a user saw high CPU when running FusionReactor reported into our technical support team. Upon investigating the issue, we found this was due to both FusionReactor and the Adobe PMT tracking sessions by making a large number of calls to the Redis database.

In FusionReactor 8.2.3 we released a fix that will stop session tracking if Redis sessions are in use. The result of this is that you will only see an overview of total session activity, there are no metrics for the active, created or destroyed sessions from ColdFusion.

In the Sessions page of FusionReactor you would only see something like:

Abode have an open bug for this (https://tracker.adobe.com/#/view/CF-4205489), this fix has been scheduled for a HF7 release. Until Adobe fixes the issue, we do not enable full session tracking when using Redis sessions in ColdFusion 2018.

To confirm if you are affected by this issue

Go to Transactions > Activity and filer by Redis transactions. You will see something similar to:

This performance issue is caused by two factors:

• A bug in FusionReactor that every second sends 2 get requests to Redis for each active session
• A bug in the Adobe PMT that every second sends 1 get request to Redis for each active session

These Redis calls are all tracked by FusionReactor which slows down the performance of the server due to the volume of requests when a ColdFusion server has a high number of sessions even if these sessions where created on a different ColdFusion server but are using the same Redis server for the sessions.

The Workaround

To work around this issue please upgrade to version 8.2.1 or higher of FusionReactor which disabled session tracking from FusionReactor. Note that in this version, there will still be one set of Redis calls made to Redis if you are viewing the session information in the Adobe PMT.

When the bug for session tracking is fixed in ColdFusion 2018, we will update FusionReactor to reenable session tracking.

FusionReactor Cloud Firewall DNS and Static IP address rules

Introduction

This article applies to FusionReactor Cloud users. Some users run FusionReactor behind restricted firewalls which do not allow all outbound connections. In this case, these users may need to add specific firewall rules to allow FusionReactor to communicate with FusionReactor Cloud.

Note that as of November 2018, the static IP rules that allow FusionReactor 7 to connect to the FusionReactor cloud have been deprecated. If you wish to configure DNS rules or static IP addresses for a cloud license, you must upgrade to FusionReactor 8.

To configure FusionReactor versions 8 and above FusionReactor 8 – http://fusionreactor.dev.onpressidium.com/support/kb/frs-454/

FusionReactor Cloud Firewall DNS and Static IP address rules

Introduction

This article applies to FusionReactor Cloud users. Some users run FusionReactor behind restricted firewalls which do not allow all outbound connections. In this case, these users may need to add specific firewall rules to allow FusionReactor to communicate with FusionReactor Cloud.

Note that as of November 2018, the static IP rules that allow FusionReactor 7 to connect to the FusionReactor cloud have been deprecated. If you wish to configure DNS rules or static IP addresses for a cloud license, you must upgrade to FusionReactor 8.

To configure FusionReactor versions 8 and above FusionReactor 8 – http://fusionreactor.dev.onpressidium.com/support/kb/frs-454/