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.

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.

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/

[FRS-355] FusionReactor Production Debugger fails to start due to missing GLIBC_2.14

UPD uses a native library to provide some of its features. UPDs native library requires GLIBC_2.14 to function.

Centos 6.x, Red Hat Enterprise Linux and other linux systems don’t provide this version. When it’s not available you will see error messages like this during startup :

$ sudo bin/catalina.sh run
Using CATALINA_BASE:   /opt/apache-tomcat-8.0.3
Using CATALINA_HOME:   /opt/apache-tomcat-8.0.3
Using CATALINA_TMPDIR: /opt/apache-tomcat-8.0.3/temp
Using JRE_HOME:        /usr
Using CLASSPATH:       /opt/apache-tomcat-8.0.3/bin/bootstrap.jar:/opt/apache-tomcat-8.0.3/bin/tomcat-juli.jar
Error occurred during initialization of VM
Could not find agent library /opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so in absolute path, with 
error: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by /opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so)

On CF servers this error information is redirected to /dev/null so its never seen but you could be hitting this error.

Check glibc version

To check the version of glibc on a linux system you can run one of the following:

# red hat / centos
rpm -q glibc

# debian / ubuntu
dpkg -l libc6

# via ldd
ldd --version

Workaround

To work around we have build a libc.so6 version 2.14.1 for uses on Centos (64 bit only) which must be explicitly loaded via the LD_PRELOAD variable

E.g. in tomcat you would set the following lines in the ‘setenv.sh’

export FR_OPTS="-javaagent:/opt/fusionreactor/instance/tomcat8/fusionreactor.jar=name=tomcat8,address=127.0.0.1:8088 -agentpath:/opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so"
export JAVA_OPTS="$JAVA_OPTS $FR_OPTS"

export LD_PRELOAD=/opt/fusionreactor/instance/tomcat8/libc.so.6

Disable the FusionReactor Production Debugger

You can disable the debugger completely by removing the

-agentpath:/opt/fusionreactor/instance/tomcat8/libfrjvmti_x64.so

argument from your application server. For Tomcat this is in setenv.sh and for CF servers its in the jvm.config.

Files

libc.so.6 – md5 checksum fa05af08d2993c478786a1f5b0335e1a

Requests from the Adobe Performance Monitoring Toolset are tracked in FusionReactor

A customer recently reported strange requests tracked in FusionReactor with ColdFusion 2018 and the performance monitoring toolset installed.

With a ColdFusion instance and the Adobe performance Monitoring Toolset (PMT) FusionReactor users will see web requests for the URL http://localhost/connector appear for the Adobe ColdFusion 2018 application.

These requests are made from the PMT to the ColdFusion server as a “heartbeat” that ensures your ColdFusion server is running.

These requests will not have any effect on the performance of the PMT or the ColdFusion server, the only issue with these requests being tracked will be that as we store by default 100 web requests and these requests can fill your request history so you no longer see as much useful data.

When configuring the PMT you can specify the heartbeat interval which would limit the number of requests you would see in FusionReactor.

It is also possible to navigate to FusionReactor (top left) > Restrictions and add the following restriction:

Match Strategy: Exact Match

Request: localhost/connector

HostName: Check

Parameters: Ignore

This will stop FusionReactor from tracking the heartbeat requests from the PMT process so they no longer appear in your history lists.

It is possible for certain configurations of the ColdFusion connector to not have a hostname, this can result in the restriction above not stopping the connector requests being ignored by FusionReactor. If this is the case, we recommend using the restriction below:

Match Strategy: Exact Match

Request: /connector

HostName: Ignore

Parameters: Ignore

This restriction will not check the hostname and ignore any traffic to the /connector url.

Introduction

This article applies to FusionReactor users running version 8.0.0 and above. 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.

This Technote covers configuring both the on-premise and cloud editions of FusionReactor.

If FusionReactor versions 5 -7 were previously installed your DNS or static IP rules should still be valid, but your FusionReactor instances will need to be reconfigured.

To configure FusionReactor versions 5 to 7 see:

FusionReactor 5 to 7 On-Premise – http://fusionreactor.dev.onpressidium.com/support/kb/frs-425/

FusionReactor 5 to 7 Cloud – http://fusionreactor.dev.onpressidium.com/support/kb/frs-418/

PLEASE NOTE THAT THIS TECHNOTE IS VALID IF YOU ARE RUNNING FUSIONREACTOR 8.0.0 and above only

Using DNS Firewall Rules

In order to communicate with the FusionReactor infrustructure, each FusionReactor instance attempts to connect to the following services, which are identified by their DNS names:

• wss://cc.fusionreactor.io – port tcp/2804
• https://api.fusionreactor.io – port tcp/443

These services require outgoing firewall rules for FusionReactor to communicate with FusionReactor Cloud. All communications are protected by SSL cyphers.

If possible, the firewall should be configured with the DNS names of these services, since they can change in response to scaling events.

If the IP addresses are required, nslookup can be used to find their current values. Most services will yield two addresses: both must be added.

Using Static IP Addresses

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

• 52.214.198.96 – port tcp/443 and port tcp/2804

After enabling this firewall rule, the following -D options need to be applied to your JVM environment, to instruct FusionReactor to use the single address:

-Dfr.gcs.client.endpoint=wss://cc-static.fusionreactor.io:2804/
-Dfr.cloud.endpoint=https://api-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 “cc-static.fusionreactor.io:2804”, "connect, accept, resolve”;
permission java.net.SocketPermission “api-static.fusionreactor.io:443”, "connect, accept, resolve”;

Introduction

In FusionReactor 8 we introduced a new licensing server that offers better support for dynamic environments and increased stability, in summary the changes to the licensing mechanism are as follows:

1. FusionReactor instances ping every minute, rather than once per day
2. The licensing server can no longer disable an instance to stop it from pinging
3. ​Servers will go to an offline state after 2 minutes of not contacting the licensing server, rather than 7 days
4. If a FusionReactor instance is running it will try to ping every minute regardless of whether the response from the licensing server allows it to activate, the only way to stop it from doing so is to click deactivate on the about page
5. FusionReactor will automatically attempt to manually activate itself on startup, if your server is able to contact our license server and receive responses then you should not have any problems.

If however, we are not able to contact the license server or receive a valid response you will see a banner in FuionReactor:

There are 3 alternative approaches to activate FusionReactor:

• Configuring a proxy
• Setting a firewall rule to allow contact to the licensing server
• Performing a manual activation

Configuring a proxy

If you require a proxy to connect to external sites you can configure FusionReactor to use this proxy, this will route all FusionReactor traffic to the licensing server through your proxy and activate automatically.

To configure your proxy you can click on proxy settings on the about page of FusionReactor, in the menu you can configure your proxy location and choose from basic, digest, NTLM or no authentication:

When you have configured your proxy you can click test proxy to ensure a connection to our licensing server can be made. If the connection is successful you will now be able to activate FusionReactor.

Setting a firewall rule

If you are running FusionReactor in a locked down environment where your firewall is restricting access to certain external sites you can configure a firewall punch to allow FusionReactor to contact its licensing server.

The punch can be done either by allowing connections to the hostname of the server or by allowing connections to a static IP address for the licensing server.

If you are using the IP address in a firewall rule you will also need to set system properties in your application server to point FusionReactor to an alternate licensing server with the static IP address configured.

For information on the firewall rules required and instructions on how to configure the application server see: FusionReactor Firewall DNS and Static IP address rules

Performing a manual activation

If your server is locked down and has no way of contacting external sites you will need to perform a manual activation. This involves taking an activation code from your server and applying this code on the FusionReactor portal via a machine that has access to our licensing server.

This is typically a more time-consuming process than relying on automatic activations, you are also required to perform this manual process each time you upgrade FusionReactor or renew your license as there is no way to retrieve the updated information from our licensing server.

For more information on manually activating FusionReactor see:  Manually activating FusionReactor