The status of various components of the FusionReactor Cloud system can be seen here.
Missing, incomplete or malformed data¶
FusionReactor is designed to be resilient to connectivity issues when shipping data to FusionReactor Cloud.
If your instance of FusionReactor has connectivity issues up to 60 mins of data is kept locally, once connectivity has been restored this data will be shipped intelligently in order to refrain from 'overloading' the transport system.
Data will then appear to 'back fill' and gaps in the data will be removed.
Live functionality not working correctly¶
Some functionality of FusionReactor Cloud requires a web socket connection to communicate directly with the FusionReactor instance. Examples of this functionality are recent or running transactions and the live graphing modes.
If you are experiencing issues with these areas of the software then you should refer to the following sections of this guide.
The Cloud status icon in the top right corner of FusionReactor shows the current connection status of the FusionReactor instance to the cloud.
|Agent connected and last transmission was successful||Connected|
|Agent connected and last transmission was not successful||Degraded|
|Agent disconnected and last transmission was successful||Degraded|
|Agent disconnected and last transmission was unsuccessful||Disconnected|
If you have a proxy server in place to access the internet, then you can configure it inside FusionReactor.
See [Proxy Settings]](../Settings/Main-Menu.md#proxy-settings) for more information on how to configure your proxy settings.
Importing SSL Cert¶
If you’re using FusionReactor with a Cloud license, the client connects to our services via encrypted SSL connections.
The certificate used to secure these connections is issued by DigiCert. Some older operating systems and older versions of Java don’t have the DigiCert certificate in the keystore.
In these cases, you’ll see an SSL error in the console, when FusionReactor tries to connect to the Cloud. Java may also complain about being “unable to build a certificate chain“.
Previously we included our own keystore, but this was problematic as in some cases, it supplanted the JEE container’s own store. The certificates we supplied would also expire eventually, necessitating a forced-update of FusionReactor.
In order to fix this, simply import the DigiCert certificate into your own keystore. As an example, here’s how to do it for IBM WebSphere, which supplies its own keystore. Adapt the path to your own keystore. IBM WebSphere Liberty Profile 9.
Download the certificate:
wget https://www.digicert.com/CACerts/DigiCertGlobalRootCA.crt -o /tmp/digicert.crt
Import the certificate into the JKS keystore for your server. On our system, for the default WebSphere server, this is done as follows:
keytool -import -alias digicert-global-root-ca -file /tmp/digicert.crt -keystore /opt/IBM/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks
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.
Using DNS Firewall Rules¶
In order to communicate with FusionReactor Cloud, 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
- https://license.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.
220.127.116.11 - port tcp/443.
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/ -Dfr.sasa.hapi.address=https://api-static.fusionreactor.io/ -Dfrlicenseservice.helix=license-static.fusionreactor.io -Dfr.sasa.kinesis.inhibit=true
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:443", "connect, accept, resolve"; permission java.net.SocketPermission "api-static.fusionreactor.io:443", "connect, accept, resolve"; permission java.net.SocketPermission "license-static.fusionreactor.io:443", "connect, accept, resolve"; permission java.net.SocketPermission "18.104.22.168:443", "connect, accept, resolve";
Please see this FusionReactor technote for more information on configuring your firewall settings inside FusionReactor.
Java only allows one debugger at a time to be used. If you use JDWP (Java Debug Wire Protocol) you need to disable it to use FusionReactor Production Debugger. Having 2 configured will result in a warning from FusionReactor Production Debugger saying it cannot acquire the capabilities to debug the java server. Please remove lines like this from the java arguments:
JDWP may be written to the config by the server if you are running ColdFusion and have the Line Debugger enabled. This can be disabled at Debugging & logging > Debugger settings > Allow Line Debugging in the ColdFusion admin panel.