Windows 7: Page 2

[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

[frs-299] Railo instances are not updated to the correct server type


This technote is about updating an instance of FusionReactor on Railo Express or Railo Server.

Description

Version 4.5.0 of FusionReactor Instance Manager will prompt you to update any existing instances when you have completed the Setup.

Previous versions of FusionReactor allowed you to add Railo as Jetty (Railo Express) or Tomcat (Railo Server) server. When FusionReactor Instance Manager scans for new target servers it will list these existing servers as Railo server in addition to the already existing Jetty and Tomcat servers.

This does allow the user to accidentally install a new FusionReactor instance to a server that already has FusionReactor installed. As a result the previous server will report itself as not connected. However, the new instance will work as expected.

Resolution

Do not install a new instance on a target server that has FusionReactor already installed (identify the belonging server by the directory listed behind the server).
Alternatively uninstall the FusionReactor instance from the Apache Tomcat resp. Jetty Server and re-install it on the appropriate Railo Server. Afterwards delete the Tomcat resp. Jetty server from the Instance Manager.

Whether your instance is installed on the Tomcat resp. Jetty server or the Railo server has no effect on functionality. Just make sure that you do not install it on the same server twice. Future versions of FusionReactor will display Railo server only and omit the Tomcat and Jetty servers if these represent a Railo server.

Issue Details

Type: Technote
Issue Number: FRS-299
Components: Installer, Instance Manager
Environment:
Resolution: Fixed
Last Updated: 22/May/12 5:27 PM
Affects Version: 4.5.0
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-298: Instance Manager picks up the Tomcat based version of Railo twice

[frs-288] Windows: Changing the user of a FusionReactor installation


During installation, the FusionReactor Administration Manager is installed as the Administrators group, and the FusionReactor AM Service is installed to log on as the Local System account

If you have changed the user under which your J2EE container runs, we recommend changing FusionReactor to be owned by, and run as, the same user as your J2EE container. This is because the component installed into your J2EE container and FusionReactor itself will need to share files.

You may need to change the runtime user of FRAM/FusionReactor if:

  • Your J2EE container is not owned by the Administrators group and/or runs as a user other than the Local System account.
  • FusionReactor reports it "Cannot modify the web.xml" during instance installation
  • A FusionReactor instance doesn't start, and reports configuration exceptions, possibly reporting Permission Denied on file operations
  • You change the user under which your J2EE container runs

In order to change the runtime user of the FusionReactor system, the following procedure can be used. The procedure uses coldfusion as the runtime user, but you should substitute your J2EE service user as necessary. The procedure uses C:FusionReactor as the install location of FR – again, adjust this as necessary.

Procedure

Log in to the system as user with Administrative privileges.

  1. In the Services Control Panel stop the FusionReactor AM Service.
    • Right click the FusionReactor AM Service and select the Log On tab.
    • Select This account and provide the runtime user name, and the password for that user.
    • Click OK.
  2. In a file Explorer window, right-click your C:FusionReactor and select Properties.
  3. Select Security, then Advanced.
  4. Select the Owner tab.
    • In the box marked Change owner to… select the new owner of the system. If the new owner is not displayed, click Other Users or Groups and enter the new owner name., followed by OK. That name should appear in the *Change owner to…" box.
    • Ensure the box marked Replace owner on subcontainers and objects is checked
    • Click OK. This will change the owner of the FusionReactor system files.
  5. Select the Permissions tab.
    • You may see an Allow entry for your runtime user in the Permissions box.
      • If you do not, click Add, then enter the name of the runtime user, and click OK.
      • If you do, double-click on that user. Both actions bring up the "Permission Entry for FusionReactor" dialog.
    • In the "Permissions Entry for FusionReactor" dialog:
      • Change the Apply onto dropdown to This folder, subfolders and files
      • Check the Allow column's Full Control box.
      • Ensure the last checkbox on the dialog, entitled Apply these permissions to objects and/or containers within this container only is not checked.
      • Click OK.
    • Back in the Permissions tab of the Advanced Security Settings for FusionReactor dialog, you should now have an Allow entry for your runtime user.
      • The entry should list Allow, and Full Control for this user, applied to This folder, subfolders and files.
    • Check the box marked Replace permission entries on all child objects with entries shown here that apply to child objects
    • Click OK, and say Yes to the warning dialog which appears.
  6. Click OK to close the FusionReactor Properties dialog.
  7. Restart the FusionReactor AM Service

Issue Details

Type: Technote
Issue Number: FRS-288
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 19/Mar/12 5:09 PM
Affects Version: 4.0.0
Fixed Version: 4.0.0
Server:
Platform: Windows 2003, Windows 7, Windows 2008
Related Issues:

FRS-270: Unix: Changing the user of a FusionReactor installation

[frs-286] Fixing a FR 4.0.4 installation so that it can be updated by later versions


Problem

Users who have installed FusionReactor 4.0.4 may not be able to upgrade their installations to a newer version due to a bug in the FusionReactor 4.0.4 installer. The problem only pertains to users who installed FusionReactor 4.0.4. The following procedure details a workaround for users who wish to avoid a complete uninstall of FusionReactor 4.0.4 and new installation of the later FusionReactor version.

Procedure

Windows

  1. Start the Windows Registry Editor and browse to the HKEY_LOCAL_MACHINE/SOFTWARE/ej-technologies/install4j/installations hive.








  2. Rename the value allinstdirs9866-5861-3195-1737 to allinstdirs7439-1350-6687-7781
  3. Rename the value instdir9866-5861-3195-1737 to instdir7439-1350-6687-7781








  4. Exit the Registry Editor
  5. Open the file i4params.conf located in the .install4j directory









    of your FusionReactor 4.0.4 installation in an editor.
  6. Find the two occurences of the string 9866-5861-3195-1737 and replace them with 7439-1350-6687-7781.
  7. Save the file and exit the editor to complete the procedure. You can now run the latest Setup to update your version 4.0.4 to the most recent version of FusionReactor.






Linux and Solaris

  1. Stop the FusionReactor daemon
  2. Become user root and execute the cd command to change to the home directory.
  3. If the file /etc/.java/.systemPrefs/com/install4j/installations/prefs.xml exists open it in an editor.
  4. If the files does not exist open the fallback file ./java/.userPrefs/com/install4j/installations/prefs.xml instead. It looks similar to the one shown below:
    </xml version="1.0" encoding="UTF-8" standalone=no"?>
    <!DOCTYPE map SYSTEM "http://java.sun.com/dtd/preferences.dtd">
    <map MAP_XML_VERSION="1.0">
      <entry key="allinstdirs9866-5861-3195-1737" value="opt/fusionreactor"/>
      <entry key="instdirs9866-5861-3195-1737" value="opt/fusionreactor"/>
    </map>
    
  5. Find the two occurences of the string 9866-5861-3195-1737 and replace them with 7439-1350-6687-7781:
    </xml version="1.0" encoding="UTF-8" standalone=no"?>
    <!DOCTYPE map SYSTEM "http://java.sun.com/dtd/preferences.dtd">
    <map MAP_XML_VERSION="1.0">
      <entry key="allinstdirs7439-1350-6687-7781" value="opt/fusionreactor"/>
      <entry key="instdirs7439-1350-6687-7781" value="opt/fusionreactor"/>
    </map>
    
  6. Open the file i4params.conf located in the .install4j directory of your FusionReactor 4.0.4 installation (typically /opt/fusionreactory in an editor.
  7. Find the two occurences of the string 9866-5861-3195-1737 and replace them with 7439-1350-6687-7781.
  8. Save the file and exit the editor to complete the procedure. You can now run the latest Setup to update your version 4.0.4 to the most recent version of FusionReactor.

Issue Details

Type: Technote
Issue Number: FRS-286
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 08/Dec/11 6:58 PM
Affects Version: 4.0.4
Fixed Version: 4.0.5
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, Solaris, Windows Vista, Windows x64, Windows 7, Windows 2008
Related Issues:

[frs-278] How to get a thread dump from the JVM


Background

To assist in debugging potential issues it is sometimes necessary to generate a thread dump. This is a list of all threads in the JVM and their current stack of processing code.

Generating a thread dump

Preferred method: If you have access to FusionReactor, you can goto the "Resource->List All Threads" page in the left-hand menu, then click the "Stack Trace ALL" button at the top-right of the page.

Other ways to generate a thread dump differ depending on the platform:

Windows systems

  • Press Ctrl-Break in the command console you used to start your application.
    • If a command console isn't an option (eg when started as a service) you can use a tool like StackTrace to get a stack trace. At the time of writing, the licence allows free use when started with the JNLP Web Start option.
  • If you start your application with the com.sun.management.jmxremote option you should be able to attach jconsole and get a thread dump (JDK 5.0 or higher.)
  • There is a little tool called SendSignal which uses a clever trick to call the ctrl-break signal handler of any process.
  • JDK 5 & 6 offer tools for monitoring, management, and troubleshooting (jconsole, jps, jstat, jstatd, jinfo, jmap, jstack.)

Mac OS X

  • Press *Ctrl-* in the terminal console you used to start your application.
  • You can also generate a thread dump by sending the QUIT signal to the Java VM running your application kill -QUIT process_id where process_id is the process number of the respective java process.
    • Note: This method outputs the stacktrace to the standard output stream which may be redirected to a log file.
  • Thread dump by using gdb.
    • Attach to the target process with gdb and run the following command:
    • (gdb) call (void)pss()
  • The latest Apple 1.5 JVMs offer all the monitoring tools available for Linux and Solaris (jconsole, jps, jstat, jstatd, jinfo, jmap, jstack.)

Unix systems

  • Press Ctrl- in the terminal console you used to start your application.
  • You can also generate a thread dump by sending the QUIT signal to the Java VM running your application kill -QUIT process_id where process_id is the process number of the respective java process.
    • Note: This method outputs the stacktrace to the standard output stream which may be redirected to a log file.
  • JDK 5 & 6 offer tools for monitoring, management, and troubleshooting (jconsole, jps, jstat, jstatd, jinfo, jmap, jstack.)

Issue Details

Type: Technote
Issue Number: FRS-278
Components: Logging
Environment:
Resolution: Fixed
Last Updated: 08/Nov/11 3:01 PM
Affects Version:
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-265] Windows Firewall blocking connections to FRAM


FusionReactor Setup

If Windows Firewall is enabled when installing FusionReactor 4.x the following warning message (or similar) is sometimes displayed when clicking 'Next' on the "FusionReactor Administration Manager (FRAM)" or "Configure Ports", screens in the Setup.


Windows Firewall Warning message

This is due to the FusionReactor installer testing if the selected ports (8087 and 8004 by default) are already in use, by attempting to bind to them. Windows Firewall will pick this up, and the above poup will be displayed. However, as this is only for the setup (for example FusionReactor_Windows_4_0_0.exe), it will not affect the FusionReactor Administration Manager, but only the Setup. Click 'Unblock' to allow the Setup to continue.

FusionRector Administration Manager (FRAM)

If Windows Firewall is enabled on the machine, this can cause issues for FRAM, when machines other than localhost attempts to access FRAM. Therefore in most cases an exception will need to be added in Windows Firewall, for whatever port FRAM is on (8087 by default).

The following procedure is for opening port 8087 for public access on Windows XP:

  • Open Windows Firewall (Control Panel -> Windows Firewall on Windows XP) and click the tab 'Exceptions'
  • Click the button 'Add Port'
  • Enter "FRAM" in the 'Name' field and the port FRAM is running on (8087 by default) in the 'Port' field.
  • Click the button 'Change scope' and select the appropriate access level.
    • Private – to allow machines only on the same network as FRAM are allowed to connect.
    • Public – to allow any machine to connect.

Windows Firewall: Add Port Exception


By following the guide above, Windows Firewall should now have been correctly configured to allow connections to the FusionReactor Administration Manager.

Issue Details

Type: Technote
Issue Number: FRS-265
Components: Installer
Environment:
Resolution: Fixed
Last Updated: Today 1:16 PM
Affects Version:
Fixed Version: 4.0.0
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Windows Vista, Windows x64, Windows 7, Windows 2008
Related Issues:

FRS-418: FusionReactor Cloud Firewall DNS and Static IP address rules

[frs-245] Hotfix FR-2069: JDBC Prepared Statements throw ‘NullPointerException’ when called with null binding values.


Hotfix 2069 for FusionReactor 3.5.5 Description

This technote describes a fix for a condition under which FusionReactor's JDBC Driver Wrapper may throw NullPointerException when used with PreparedStatements whose binding values are null

Symptoms

When using the JDBC Driver Wrapper, passing a null to a setX method of PreparedStatement throws NullPointerException.

Analysis

FusionReactor's JDBC driver expects passed binding values to be non-null. The expected method of setting null for a given parameter is the setNull(...) method, however the JDBC API does not specifically prohibit null as a binding value being passed directly to the setX methods of PreparedStatement. Internally, the wrapper does some marshaling of this value in order to log it and display it in FusionReactor, and this operation was not null-guarded.

We confirm this to be a bug in the JDBC Driver Wrapper shipped up to FusionReactor 3.5.5.

Resolution

Customers with FusionReactor 3.5.5

Customers with FusionReactor 3.5.5 only installed should apply the attached Hotfix 2069, which resolves this issue.

Instructions for applying the hotfix are supplied in instructions.txt within the hotfix zip file.

Hotfixes are cumulative: any future hotfixes on the FusionReactor 3.5.5 stream, up to but not including the next point release, will contain this hotfix (and all earlier hotfixes since the last point release).

Customers with prior versions (< 3.5.5)

Customers with versions earlier than FusionReactor 3.5.5 should update to that version using the published installer/updater prior to applying this hotfix.

Included Hotfixes

  • None. This hotfix is the first to be issued on the 3.5.5 stream.

Files

hotfix-FR-2069.zip

Taxonomy

After installation, FusionReactor's "About" page should identify itself as *"
Revision: 3.5.5, Build: FusionReactor 3.5.x Maintenance Branch.17.19877"*

~Hotfix FR-2069 (B/P FR-2070) – obf. (Stream: FusionReactor 3.5.x Maintenance Branch, build 17, SVN 19877 JRH)

Issue Details

Type: Technote
Issue Number: FRS-245
Components: JDBC
Environment:
Resolution: Fixed
Last Updated: 02/Mar/11 2:27 PM
Affects Version: 3.5.5
Fixed Version: Pending
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, Flex Data Services, JBoss, Jetty, JRun 4, LiveCycle Data Services, Railo, Resin, ServletExec, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, AIX, Windows 7, Windows 2008
Related Issues:

[frs-238] Getting Started With FusionReactor


Guide to Getting Started With FusionReactor

New to FusionReactor? Use this guide to help you Get Started.

This document refers to FusionReactor 3.0.1 and JDBC Wrap/Un-Wrap tool version 0.8 and is applicable to FusionReactor 3.5.1.

Getting Started with FusionReactor

Useful Links

Download FusionReactor
Install Guide (pdf)
JDBC Wrapper Tool

About the Author

Ajas Mohammed is a Sr. Software Engineer / Sr. ColdFusion Programmer at Absentys LLC with both a Bachelor's and Master's in Computer Science. Ajas has worked in the Information Technology field for over 10 Years.

Ajas Mohammed's Blog

Issue Details

Type: DevNet
Issue Number: FRS-238
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: 20/Nov/09 1:15 PM
Affects Version: 3.0.1, 3.5
Fixed Version: 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


Creating Daily Log Files in FusionReactor

FusionReactor captures a lot of very useful data into log files. These log files can be used to analyze a server in great detail. FusionReactor's logging mechanmism allows you to decide how many log files you want to keep and how big each log file should be but it doesn't allow you to rotate the log files every day.

It would be great to rotate the log files every day so that we can keep a record for as long as we want instead of losing data when the log files rotate automatically.

Using FRAPI (FusionReactor's API) this is easy to achieve.

Requirements

FusionReactor 3.0.1+

The Article

FusionReactor captures data about Requests, JDBC Requests, Resources, CrashProtection actions and details about itself into log files. These log files are typically placed under a log folder that can for each instance of FusionReactor. On a Windows installation the log folder might by for example:

   C:FusionReactorinstancecoldfusion.cfmx9.INT000Blog

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.

Here's how to instantiate the FRAPI interface in CFML. Once we have FRAPI available we are able to read this FusionReactor's configuration:

        <cftry>
            <cfset frapi = createObject("java", "com.intergral.fusionreactor.api.FRAPI").getInstance()>
            <cfset config = frapi.getRunningConfiguration()>
            <cfdump var="#config#">
            <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 "frapiconfig.cfm" file with the CFML code above and run the page on a system that has FusionReactor installed. After the page has completed you should see a dump of FusionReactors configuration for this instance.

Once we have the configuration, we can change it and tell FusionReactor to update very easily like this:

            <cfset config.setValue("logfile", "#install_location#/instance/#instance_name#/log/#datetime#/reactor.log")>
            <cfset frapi.setRunningConfiguration(config)>

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>

Notes

  1. Log File Sizes
    Some of FusionReactor's log files can fill very quickly. This is especially true of the JDBC log files. You need to take this into consideration when you set the log file size(s). As a counter point you have to be aware that using very large log files sizes and rotating the log files every day can very quickly use up lots of disk space. Please take care when setting the log file sizes and consider archiving or removing log files based upon there age.
  1. Log File Count
    FusionReactor lets you set the number of log files you want to keep for each log type. It's tempting to set this to a large number so that FusionReactor doesn't lose any information but you should consider that the more log files FusionReactor has to manage and rotate, the slower the log file rotate will be. I would not advise you to set the log file count higher than 20 log files. It is more advisable to balance the number of log files and the log file size. For example, of you set the log file count to 10 and the log file size to 20480 (log file size is set in KBytes) then you would create a maximum of 200MBytes of log data (for the specific log).

Fast Track

  1. Copy the frapi.rotatelogdirectoy.cfm file linked to this article to a folder where you run ColdFusion (for example): <coldfusion folder>/wwwroot/fusionreactor
  2. Create a scheduled task to run this page once per day at 00:00:00 midnight

Summary

By rotating FusionReactor's log files daily you can keep log files for as long as you want and can prevent you from losing this valuable data when FusionReactor rotates it's log files automatically when the size of the file has been reached.

Issue Details

Type: DevNet
Issue Number: FRS-237
Components: Logging
Environment:
Resolution: Fixed
Last Updated: 06/Nov/09 6:51 PM
Affects Version: 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Fixed Version: 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-232: Capturing ColdFusion’s Debug Output in FusionReactor

[frs-231] The Hostname in Request URL’s show “null” instead of the server name or IP address in ColdFusion 9


Due to an issue in the JRun version used with ColdFusion 9, the Hostname in Request URL's can sometimes contain the string "null" instead of the actual hostname.

Finished: 18:48:30.774 28-Sep-2009  200  192.168.0.11  11841  web-0  http://null:8500/test/test.cfm  0  Cur:(13%)67,809 Free:437,086

The problem occurs when a request is made against a port that is not the default port (e.g. 80) and the port number is not included in the HTTP Host header sent to the ColdFusion server by the web client. For example:

http://server.yourdomain.com:8500/test/test.cfm

Some web clients incorrectly do not include the port number in the Host: header that is sent for the request. For example:

GET /test/test.jdbcfast.cfm HTTP/1.1
Host: server.yourdomain.com
User-Agent: Mozilla/4.0 (compatible; MSIE 4.01; Windows 98)
Accept: */*
Accept-Encoding: gzip, deflate
Accept-Language: en-us
Connection: Close

This problem has been confirmed for Microsoft Web Application Stress (which does not send the port number in the Host header), but other clients may suffer from the same bug.

Workaround

To work around the issue you should use the default web port (e.g. 80), or use a different client that correctly sends the port number in the Host: header of HTTP requests.

A bug report has been submitted to Adobe for this issue.

Issue Details

Type: Technote
Issue Number: FRS-231
Components: Request Managment
Environment:

Windows XP (Darren’s laptop)
ColdFusion GM2
Via internal webserver.

Resolution: Won’t Fix
Last Updated: 30/Sep/09 1:55 PM
Affects Version: 1.0, 2.0, 2.0.3, 2.0.4, 3.0, 3.0.1, 3.5
Fixed Version: Pending
Server: ColdFusion 9
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, Windows 7, Windows 2008
Related Issues: