[FRS-442] Forgotten FusionReactor v7 password / Reset FusionReactor v7 password


This technote will guide you through resetting the password for your FusionReactor 7.x instance, the process is also relevant for FusionReactor versions 5.x and 6.x.

To reset the password for FusionReactor you can follow these steps:

  1. Stop your application server
  2. Locate your reactor.conf file at {FusionReactor Directory}/instance/{instance name}/conf/reactor.conf
  3. Open this file in a text editor
  4. Remove the line beginning with "user.0=Administrator"
  5. Restart your application server.

When you access FusionReactor you will be asked to set a new password for the administrator user.

 

Issue Details

Type: Technote
Issue Number: FRS-442
Components: FusionReactor Settings
Environment:
Resolution: Fixed
Last Updated: Today 1:55 PM
Affects Version:
Fixed Version: 7.0.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-321: Forgotten FusionReactor v5 password / Reset FusionReactor v5 password

[frs-389] Manually uninstalling FusionReactor


Manually uninstalling FusionReactor from your application server is as simple as it is manually installing, but the process is reversed.

Typically uninstalling FusionReactor is a matter of removing 1 or 2 arguments from your JVM startup arguments. The procedure in general is:

  • Stop your application server
  • Remove the -agentpath:<…fusionreactor native library…> if present from your JVM startup arguments
  • Remove the -javaagent:<…fusionreactor.jar> if present from your JVM startup arguments
  • Start your application server.

If you are experiencing startup issues such as your server won't start after installing FusionReactor, they may be due to the -agentpath:<…fusionreactor native library…>. This argument refers to a native library that must exist and must match your Operating System, installed libraries and the 32/64bit nature of the JVM you are using. Removing only the -agentpath and restarting the server will typically allow you to still use FusionReactor, just without the Production debugger capability. The -agentpath argument is not essential for the normal operation of FusionReactor.

Provided below is an overview of how to remove FusionReactor from a number of common application servers:

Server Configuration method How to remove
Tomcat 7
Tomcat 8
Tomcat 9
Linux: setenv.sh configuration file
Windows: Tomcat*w.exe GUI Tool

where * is your tomcat version number
Tomcat FusionReactor Removal
ColdFusion 9
ColdFusion 10
ColdFusion 11
ColdFusion 2016
jvm.config configuration file ColdFusion FusionReactor Removal
ColdFusion 9 Solr Linux: solr.lax configuration file
Windows: cfsolr configuration file
ColdFusion 9 Solr FusionReactor Removal
ColdFusion 10 Solr
ColdFusion 11 Solr
Linux: jetty.lax configuration file
Windows: cfjetty configuration file
ColdFusion 10 Solr & 11 Solr FusionReactor Removal
ColdFusion 9 Multi individual jvm.config configuration files ColdFusion 9 Multi FusionReactor Removal
Glassfish 4 domain.xml configuration file Glassfish 4 FusionReactor Removal
Railo 3 Linux: setenv.sh configuration file
Windows: Railow.exe GUI Tool
Railo 3 FusionReactor Removal
Railo 4 Linux: start configuration file
Windows: Railow.exe GUI Tool
Railo 4 FusionReactor Removal
JBoss 7 Standalone
Wildfly 8
Wildfly 9
Wildfly 10
standalone.conf configuration file JBoss 7 & Wildfly FusionReactor Removal
Jetty 7
Jetty 8
Jetty 9
start.ini configuration file Jetty FusionReactor Removal
Lucee 4
Lucee 5
Linux: setenv.sh configuration file
Windows: Luceew.exe GUI Tool
Lucee FusionReactor Removal
FusionAnalytics FusionAnalytics Server.vmoptions configuration file FusionAnalytics FusionReactor Removal

For a more complete and detailed description with more information on how to remove FusionReactor from your application servers, visit the Manual Uninstallation documentation.

Issue Details

Type: Technote
Issue Number: FRS-389
Components: Installer, Instance Manager
Environment:
Resolution: Fixed
Last Updated: 11/May/16 11:33 AM
Affects Version:
Fixed Version: 6.2.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-386] Network IO Graph can show negative values if a server enters sleep mode


When a sever falls into sleep mode the Network IO Graph may show negative values. The Network IO Graph is located in FusionReactor under:

  • System Resource > Network Usage

Network IO Graph displaying negative spikes in FusionReactor

Negative values will cause the 1 Hour, 1 Day, and 1 Week graphs to display incorrectly where the negative values occurred.

FusionReactor will be fixed by preventing the negative values in a later release.

Issue Details

Type: Technote
Issue Number: FRS-386
Components: Metrics
Environment:
Resolution: Fixed
Last Updated: 23/Feb/16 3:40 PM
Affects Version: 6.0.0, 6.0.1, 6.0.2, 6.0.5
Fixed Version: 6.x
Server: BlazeDS, ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, ColdFusion 10, Flex Data Services, GlassFish, JBoss, JBoss 7, Jetty, JRun 4, Open BlueDragon, LiveCycle Data Services, Railo, Resin, ServletExec, Tomcat, Tomcat 7, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-233] FusionReactor Nagios Plugin


FusionReactor Nagios Plugin

What is Nagios?

"Nagios is an enterprise-class monitoring solution for hosts, services, and networks released under an Open Source license."

Source: http://www.nagios.org, March 12th 2009

Many companies use Nagios throughout the enterprise to alert them of operational abnormalities. This plugin allows you leverage the unique monitoring capabilities of FusionReactor from within your existing Nagios environment.

Nagios Exchange

Plugin Details

This is a Perl plugin for the Nagios monitoring system to allow monitoring of your J2EE application through the FusionReactor software.

You can monitor & track high level metrics (instance CPU, heap memory, JDBC calls, average request time, etc) from within Nagios. If/When an issue is alerted from Nagios, you can use FusionReactor to investigate further.

Monitoring ColdFusion with Nagios

FusionReactor can monitor any type of J2EE server. ColdFusion runs on a J2EE server meaning that you can monitor your ColdFusion application with Nagios using FusionReactor and this plugin.

You can also monitor your Railo server with Nagios or OpenBD (Open BlueDragon) using this Nagios plugin.

Requirements

System to be monitored (J2EE server)

  • FusionReactor Enterprise Edition

Monitoring Host (Nagios server)

The following modules can easily be installed via CPAN. Further instructions are available in the documentation:

  • Nagios::Plugin
  • File::Basename
  • LWP::UserAgent
  • Digest::MD5
  • MIME::Base64
  • XML::XPath
  • XML::XPath::XMLParse

Latest Version

Latest Stable: Nagios Plugin 1.0

Download
Documentation

Changelog

1.0 – Initial release

Issue Details

Type: DevNet
Issue Number: FRS-233
Components: Compression, Content Filters, CPU + Memory, Crash Protection, Enterprise Dashboard, FR Enterprise Dashboard Desktop Application, FusionReactor Settings, Installer, JDBC, License + Activation, Logging, Metrics, Request Managment, Thread Management
Environment:
Resolution: Fixed
Last Updated: 25/Aug/15 4:32 PM
Affects Version:
Fixed Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5, Pending
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-324] License activation is unreliable with Glassfish servers


Background

A standard Glassfish 3.x or 4.0 installation is deployed with a keyStore and no keyStorePassword.

This configuration is not supported by Java.

When FusionReactor attempts to acquire a license it makes a connection to the Intergral license servers via HTTPS. The strange glassfish configuration causes the exception "Password cannot be null" and causes the license request to fail.

The user has to then perform a manual activation.

The issue can affect the auto-activation of the license inside Glassfish and make it a little random. This is dependent on what WebApps (if any) are deployed into Glassfish and the FusionReactor and Glassfish startup order.

Workaround

There are multiple workarounds for this problem:

  • Add the following JVM option to the domain.xml file
    • <jvm-options>-Dfrlicenseservice.protocol=http</jvm-options>
  • Comment out the keyStore line to the domain.xml file
    • <!--<jvm-options>-Djavax.net.ssl.keyStore=${com.sun.aas.instanceRoot}/config/keystore.jks</jvm-options>-->
  • Add the missing default keyStorePassword line to the domain.xml file
    • <jvm-options>-Djavax.net.ssl.keyStorePassword=changeit</jvm-options>

Any one of these solutions fixes the activation of the license.

Issue Details

Type: Technote
Issue Number: FRS-324
Components: License + Activation
Environment:
Resolution: Fixed
Last Updated: 15/Jan/14 12:08 PM
Affects Version: 5.0.0
Fixed Version: 5.0.0
Server: GlassFish
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-320] Starting FusionReactor Administrator Automatically on Mac OS X


Warning: Unsupported Material

This material has been developed and carefully checked prior to publication but may not be kept up to date.

This material is provided on an 'as-is' basis, with no warranties or guarantees whatsoever. This material is not supported by Intergral GmbH.

Audience

This technote applies to customers using Mac OS X 10.8 "Mountain Lion" or above only. Earlier versions of OS X may work but have not been tested.

Starting FusionReactor Administrator Automatically on Mac OS X

A number of customers have enquired as to the possibility of starting the FusionReactor Administrator (commonly known as FRAM or FRAMD on Unix) automatically when OS X comes up.

We have not built this functionality into the installer because of the complexity of the OS X launch process, launchd and the fact that developers' machines tend to vary greatly (and unpredictably) in software layout.

We have, however, developed a procedure for adding this behaviour to OS X.

Please be aware that we cannot provide support for this procedure, because of the highly-diverse nature of developers' machines, and the difficulty of obtaining remote desktop or remote terminal access to them.

Plist and Launchd

The startup of Mac OS X is controlled by launchd. This is a system developed by Apple, designed to obviate the alternative systems in use in Unix-like environments (rc.d, upstart, service etc.).

Launchd uses 'plist', an XML grammar describing property lists (keys, values, arrays etc.). The specific keys required to develop a plist for launchd are described here.

We have developed a plist for launchd which starts FRAMD automatically on Mac OS X.

Instructions

The plist file, com.intergral.fusionreactor.framd.plist is attached, and requires editing before use.

  1. Copy the attached plist file to your desktop and open it with an editor.
  2. Locate the key UserName and change the associated String value to be your username.
    • If you do no know what your username is, open Terminal (/Applications/Utilities/Terminal and type whoami, followed by the return key.
    • This step must be completed because the FusionReactor installer installs the files as being owned by the user who ran the installer, and FRAMD must access them.
  3. Locate the key ProgramArguments and change the first String value to point to your installation of FusionReactor and framd. In our example, this is /Applications/FusionReactor/instance/FRAM/framd, but you may have installed FusionReactor into another location.
  4. Check that the formatting of the file is correct by running the plutil command in Terminal:
    • plutil ~/Desktop/com.intergral.fusionreactor.framd.plist
    • plutil will respond with an OK or an error message if the formatting has been damaged. Edit the file again until plutil responds OK.
  5. Copy the file using Finder to /Library/LaunchDaemons.
    • Finder may ask you to authenticate with your password to complete this operation.
  6. In Terminal, change the ownership of the plist file to root:wheel
    • Execute the following command, followed by the return key:
    • sudo launchctl load /Library/LaunchDaemons/com.intergral.fusionreactor.framd.plist
    • No errors should occur. After a few seconds, FRAM should be available on http://localhost:8087
  7. (Optional) You can stop FRAM by executing the following command in the Terminal:
    • sudo launchctl unload com.intergral.fusionreactor.framd.plist
  8. You should then perform a reboot to ensure FRAM starts at boot time.

If you have any issues, the Console (/Applications/Utilities/Console may contain more information. If you need to edit the plist file once you've changed its ownership, you must edit the copy located on your Desktop, then procede from step 5 above. It is not possible to easily edit the copy in /Library/LaunchDaemons.

Support

This procedure is not covered by Intergral's free installation support.

Issue Details

Type: Technote
Issue Number: FRS-320
Components: FRAM
Environment:
Resolution: Fixed
Last Updated: 03/Sep/13 11:53 AM
Affects Version: 5.0.0
Fixed Version: 5.0.0
Server:
Platform: MacOS
Related Issues:

[frs-232] Capturing ColdFusion’s Debug Output in FusionReactor


Capturing ColdFusion's Debug Output in FusionReactor

It would be great if you could capture the debug data from every page run but hide it away from the user so that they don't even see it. It's easy to do this with FusionReactor.

ColdFusion's powerful debug data output feature that lets you see lots of useful debugging information about the page run. Unfortunately the data is lost as soon as you run the next page in the browser window/tab and is only visible to the user that ran the page.

Requirements

FusionReactor
FusionDebug

The Article

We're all familiar with ColdFusion's debug output at the end of a CFML page. Many CFML programmers use it as the primary way of debugging CFML code.

There are a few problems with the way that debug data is made available to us however such as the fact that the only user that can see the debug output is the user that ran the page. This is even more of a problem if you want to see the debug data but don't want to scare the user that ran the page. Of course it's possible in CF to restrict the IP addresses that generate debug output but sometimes you want to be able to see the debug output from other users without them seeing it. It's easy to do with FRAPI.

About FRAPI

FRAPI is a powerful and easy to use API that allows you to take control of FusionReactor programatically. Using FRAPI you can change the running configuration of FusionReactor or add extra debugging information to requests using just a few lines of code.

Here's how to instantiate the FRAPI interface in CFML. Once we have FRAPI available we add extra information to a request data recorded in FusionReactor using FRAPI's trace() function:

      	<cftry>
            <cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
            <cfset frapi.trace( "Hello FRAPI!")>
            <cfcatch>
                <!--- FRAPI isn't available so FusionReactor probably isn't installed --->
            </cfcatch>
        </cftry>

Note that we always wrap FRAPI calls in a TRY/CATCH block. The reason for this is that FusionReactor may not be installed on every computer that you run the code on. The TRY/CATCH blocks will make sure that FRAPI calls will have no influence on your code even if FusionReactor isn't installed.

To try FRAPI, create a "frapitest.cfm" file with the CFML code above and run the page on a system that has FusionReactor installed. After the page has completed go into FusionReactor's Request History, select the Request Details for the request and click on the Markers tab to see the "Hello FRAPI!" message. Cool no? FRAPI tracks messages on the request as soon as trace() is called so it's possible to see the trace() statements in the Markers tab updating as a page is being run!

So how would we capture CF's debug output? We don't want to add FRAPI code to every page that we write that's for sure. We need to understand how ColdFusion's debug output is done to know how to capture it.

When enabled, CF Debug output is appended at the end of the page output by rCF running a "Debug Output Formatting" template. This is simply a piece of CFML code to that formats the debugging information into HTML. What's even better is the fact that the you can write your own and tell ColdFusion to use your template instead of the default one. So what if we wrote a CF Debug Template that simply calls FRAPI and adds that debug data to the FusionReactor Request using trace() calls? This means that the information would be available in FusionReactor but the user wouldn't even know that debug output was enabled because the FRAPI trace() calls don't output anything. It's that easy! Ok, there is always a but…

…but I don't know how to access all of this CF Debug Data and for sure it's complex, right?

The CF Debug data structures are fairly complex and very powerful but this is reason that few people ever write there own CF Debug Formatting template. The good news is we don't need to know anything about it due to a powerful CFML tag called <CFSAVECONTENT>. I know that the advanced CFML programmers out there just went… "OK, I get it…", but for the rest of us let's go into a little more detail on how we can do this.

<CFSAVECONTENT> is a tag that allows the programmer to capture output into a variable instead of sending it back to the user. Using <CFSAVECONTENT> we can capture the output from the classic CF debugging template into a variable and then simply call FRAPI's trace() function passing that variable as the information to record! Easy!

FRAPI.CFM

        <cftry>
            <cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
            <cfsavecontent variable="debugData"><cfinclude template="classic.cfm"></cfsavecontent>
            <cfset frapi.trace( debugData )>
            <cfcatch>
                <!--- FRAPI isn't available so FusionReactor probably isn't installed --->
            </cfcatch>
        </cftry>

All we have to do now is add our FRAPI Debug Template (frapi.cfm) to the CF debug templates by simply copying it folder where debug templates are placed, typically <coldfusion folder>/wwwroot/WEB-INF/debug.

Finally we have to Enable Request Debugging Output and select our new ("frapi.cfm") template as the Debugging Output Format in the ColdFusion Administrator -> Debug Output Settings page.

The next time you (or anyone) runs a CF page FusionReactor will capture the Debug data for the page. To see the data simple go to the FusionReactor->Request History, select the Request Detail for the request and then click on the Markers tab to see the CF Debugging Data for the page.

Notes

  1. Performance
    ColdFusion pages run slower when debugging is enabled and on some applications enabling CF Debug Output can seriously impact the performance of the server. You should test this on your applications before enabling debugging a production server.
  2. Memory
    FusionReactor will record the debug output on each request that it keeps in it's request history. This will use some memory; for example, if you have a Request History size of 100 requests and the average debug output data size is 20Kbytes then FusionReactor will use 2Mbytes of memory to
    record the debug data.
  3. Data
    The amount of debug data recorded is controlled via the settings on the Debug Output Settings page and the classic.cfm debug formatting output template. The data will not be added to FusionReactor until the page completes because this is when CF calls the Debug Output Formatting page. The
    debug data captured will honor any Debugging IP Address restrictions that you configure in the CF Administrator.

Fast Track

  1. Copy the frapi.cfm file linked to this article to your ColdFusion Debug Formatting Template folder (typically): <coldfusion folder>/wwwroot/WEB-INF/debug
  2. Select Debugging Output Format: "frapi.cfm" in the ColdFusion Administrator -> Debug Output.
  3. Enable Request Debugging Output in the ColdFusion Administrator->Debug Output Settings Settings
  4. Run a CF page.
  5. In FusionReactor->Request History select the Request Detail for the request and then click on the Markers tab to see the CF Debugging Data from the page.

Summary

FRAPI is a powerful way to capture extra debugging information on requests and makes FusionReactor a powerful platform for debugging on both development and production servers.

Issue Details

Type: DevNet
Issue Number: FRS-232
Components: Compression, Content Filters, CPU + Memory, Crash Protection, Enterprise Dashboard, FR Enterprise Dashboard Desktop Application, FusionReactor Settings, Installer, JDBC, License + Activation, Logging, Metrics, Request Managment, Thread Management
Environment:
Resolution: Fixed
Last Updated: 03/Nov/11 3:36 PM
Affects Version: 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Fixed Version: 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-237: Creating Daily FusionReactor Log Files

FRS-280: Setting VM Options via FRAPI

[frs-280] Setting VM Options via FRAPI


Setting VM Options via FRAPI

The Sun Java VM (JVM) offers many options to allow the user to control how the VM behaves. The HeapDumpOnOutOfMemoryError option for example is very useful if your server is suffering from heap memory problems and crashing.

By turning on HeapDumpOnOutOfMemoryError the JVM will create a dump file when java.lang.OutOfMemoryError is thrown that can be used in Memory Analysis tools such as MAT to track down memory problems.

A list of VM manageable runtime options includes:

Option Description
-XX:-HeapDumpOnOutOfMemoryError Dump heap to file when java.lang.OutOfMemoryError is thrown
-XX:-PrintClassHistogram Print a histogram of class instances on Ctrl-Break
-XX:-PrintConcurrentLocks Print java.util.concurrent locks in Ctrl-Break thread dump
-XX:-PrintGC Print messages at garbage collection
-XX:-PrintGCDetails Print more details at garbage collection
-XX:-PrintGCTimeStamps Print timestamps at garbage collection

Typically these options are added to the command line that starts the VM in the form of -XX:<optionname>.

There are however major problems with this:

  • Typically you have to edit the file that sets the command line options (e.g. jvm.conf) to change the settings.
  • If the -XX command line option wasn't added to the command line options at start-up then you can't set the option without restarting the server

Using FRAPI

It would be great if you control these VM options using code instead of the command line. FRAPI is a powerful and easy to use API that allows you to take control of FusionReactor programatically. Using FRAPI you can change the running configuration of FusionReactor or add extra debugging information to requests using just a few lines of code. We can also use FRAPI to set any "Managable" VM Option on the Sun JVM. (take a look at the following VM Options for details of all of the VM Options and look for "Manageable").

CFML
<cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
<cfset frapi.setVMOption("HeapDumpOnOutOfMemoryError","true")>
<cfset frapi.setVMOption("PrintConcurrentLocks","true")>
<cfset frapi.setVMOption("PrintGCDetails","true")>   
JSP
<%@ page import="com.intergral.fusionreactor.api.*" %>
<%
    FRAPI frapi = FRAPI.getInstance();
    frapi.setVMOption("HeapDumpOnOutOfMemoryError","true");
    frapi.setVMOption("PrintConcurrentLocks","true");
    frapi.setVMOption("PrintGCDetails","true");   
%>

Requirements

You must be using a version of FRAPI that includes the setVMOption method (introduced in FRAPI 4.0) and a Sun JVM 1.5 or higher.

Notes

  • Due to a Bug in Java the HeapDumpPath VM Option may throw a NullPointerException and typically cannot be used.
  • Only VM Options that are known as "Manageble" can be set/changed at runtime. Manageable means that the option is dynamically writeable through the JDK management interface.

Summary

FRAPI is a easy way to set powerful VM Options while the server is running, without having to restart the server or edit configuration files.

Issue Details

Type: DevNet
Issue Number: FRS-280
Components: FRAPI
Environment:
Resolution: Fixed
Last Updated: 03/Nov/11 5:35 PM
Affects Version: 4.0.0
Fixed Version: 4.0.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-232: Capturing ColdFusion’s Debug Output in FusionReactor

[frs-306] FusionReactor 4.5.3 Setup on MacOS does not set owner of files


Symptoms

Users who have installed version 4.5.3 of FusionReactor on MacOS may not be able to start and stop the FusionReactor daemon (framd) due to a bug in the Setup.
The owner and group of the installed files is not set to the user and group that have been defined during the Setup. The daemon control script (typically /Applications/FusionReactor/tomcat/bin/framd) does not work, as it contains an unresolved pattern (SCRIPT_HERE) which is normally resolved during the installation process.

When the Setup has finished it does per default start the framd daemon and open the FusionReactor Administrator web application in a new web browser window. However, the framd daemon runs as root user which means that any instances added to target servers are owned by root afterwards.

Resolution

If no instances have been added yet you can run the 4.5.4 Setup which will

  • update FusionReactor to version 4.5.4
  • change the user and group of all files under the installation directory (typically /Application/FusionReactor) to the correct values (which have been specified during the 4.5.3 Setup)
  • patches the framd daemon control script so that the process runs under the defined user afterwards

Alternatively you can manually apply the required changes:

  • stop the FusionReactor process (e.g. using the kill command)
  • do a sudo chown -R nobody:bin /Applications/FusionReactor to set the correct file ownership (please replace nobody and bin with the values matching your environment)
  • Open the framd daemon control script with an editor and replace the line
    ...
    SCRIPT_HERE
    ...
    

    with

    ...
    INSTALL4J_JAVA_PREFIX="sudo -u nobody "
    ...
    

    assuming your runtime user is nobody

  • restart FusionReactor with the command
    sudo /Application/FusionReactor/tomcat/bin/framd start

When choosing the user and group under which the framd daemon process will run please consider that this user must have read and write permissions to the target server files.

Issue Details

Type: Technote
Issue Number: FRS-306
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 26/Mar/13 11:33 AM
Affects Version: 4.5.3
Fixed Version: 4.5.4
Server:
Platform: MacOS
Related Issues:

[frs-298] Instance Manager picks up the Tomcat based version of Railo twice


This technote is about installing an instance of FusionReactor on Railo Server.

Description

Version 4.5.0 of FusionReactor Instance Manager picks up the Tomcat based version of Railo twice. As a result the list of suitable target servers will contain the following target servers

  • Apache Tomcat
  • Railo

which actually represent the same server. This can be seen in the Server Scan dialog shown below

(note the directory paths) which typically is displayed when FusionReactor does its initial scan for target servers and later on the Instance Manager page:

Resolution

An instance of FusionReactor should be installed in only one of the two candidates, preferable the Railo server. Future versions of FusionReactor will only display Railo and omit the Apache Tomcat if it represents a Railo Server.
If you have done so the Instance Manager page will look like the one shown below.

Issue Details

Type: Technote
Issue Number: FRS-298
Components: Instance Manager
Environment:
Resolution: Fixed
Last Updated: 22/May/12 5:28 PM
Affects Version: 4.0.10
Fixed Version: 4.5.1
Server: Railo
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

FRS-299: Railo instances are not updated to the correct server type