Solaris: Page 2

[frs-293] How to correct a FusionReactor environment on Solaris after upgrading from 4.0.6 or 4.0.7


Problem

This will not be an issue for you if you chose for FusionReactor Administration Manager (FRAM) to run as root user during the setup, if you did then you do not have to continue reading this technote.

There was a bug in the FusionReactor 4.0.6 and 4.0.7 installer for Solaris SPARC which resulted in the FusionReactor Administration Manager (FRAM) always running as root user. This bug was fixed in FusionReactor 4.0.8, FusionReactor Administration Manager (FRAM) is now able to be run by the user chosen during the setup.

The problem was that in 4.0.6 and 4.0.7 FusionReactor Administration Manager would place the fusionreactor.jar file in your server's shared lib directory as root which meant no other user except root could access or overwrite it. When trying to update your 4.0.6 or 4.0.7 instances to 4.0.8 (or higher) a lot of the time the update would fail. This is because FusionReactor Administration Manager now runs as the user chosen during the setup, most of the time this user is not root which causes the update to fail as it can't overwrite the fusionreactor.jar file that was placed there by FusionReactor Administration Manager when it was running as root in version 4.0.6 or 4.0.7.

Symptom

After updating FusionReactor from 4.0.6 or 4.0.7 to a higher version you attempt to update your 4.0.6 or 4.0.7 instances, the following is displayed.

You then follow the advice in the dialog box and view the log by navigating to the table of contents and clicking on FusionReactor and then Log. You will then be presented with the contents of the reactor.log file, scroll down and look for a stack trace that contains something similar to the text below.

2012-05-14 16:15:07.214 WARNING com.intergral.fusionreactor.install.InstanceManagerPermissionsException: 
Could not copy fusionreactor.jar to /opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/lib/fusionreactor.jar (Permission denied). 

The messages explains that the fusionreactor.jar file can not be copied over to the shared lib folder of the server. This is the symptom.

Procedure

You will need to apply this procedure to every FusionReactor 4.0.6 or 4.0.7 instance that you want to update.

1) Open a terminal and navigate to the directory that you observed in the Symptoms section of this technote, for this scenario is is /opt/coldfusion9/runtime/servers/coldfusion/SERVER-INF/lib. This directory contains the fusionreactor.jar that is owned by root user.
2) We are going to change the user and group of the fusionreactor.jar to the user and group that was chosen during the FusionReactor setup. If you can not remember the user and group you choose during the setup type the following into the terminal and hit enter, "ls -la fusionreactor_home" where "fusionreactor_home" is the directory in which FusionReactor is installed into. In Solaris the default location is /opt/fusionreactor.
After you type this in and hit enter all the files in the FusionReactor directory along with the user and group that owns them will be output to the console, every file will be owned by the same user and group, this is what you installed FusionReactor as. To change the user and group of the fusionreactor.jar file type in "sudo chown user:group fusionreactor.jar" where user is the user FusionReactor was installed as and group is the group that it was installed as.
3) Now return to the Instance Manager and update the 4.0.6 and 4.0.7 instance in which you applied this technote to.

Issue Details

Type: Technote
Issue Number: FRS-293
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 22/May/12 11:24 AM
Affects Version:
Fixed Version: 4.5.0
Server:
Platform: Solaris
Related Issues:

[frs-287] Instance Manager reports “Could not update web descriptor”


Symptoms

Customers attempting to add an instance of FusionReactor using the FusionReactor Administration Manager (FRAM) Instance Manager receive a dialog box with the following text.

Could not update web descriptor /path/to/descriptor/default-web.xml.

Clicking "Skip" or the close icon is the only available action. The instance is not added.

Analysis

We have tracked this issue to a problem when the J2EE server's runtime user is different to that of FusionReactor. This occurs usually when customers have locked down the J2EE server by changing its runtime user in Windows Services (for Windows) or by installing it as a non-root account in Linux or other Unix.

Because the web descriptor is owned by another user, FusionReactor is unable to access it to add a <filter> element. The dialogue box gives the full path to the file whose edit failed.

Resolution

We have developed a procedure to allow FusionReactor to coexist with J2EE servers with differing runtime users. It is part of FusionReactor's online user manual, and can be found at the following URL:

Installing FusionReactor in Locked Down Environments

Issue Details

Type: Technote
Issue Number: FRS-287
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 10/Jan/12 5:12 PM
Affects Version: 4.0.0, 4.0.1, 4.0.2, 4.0.3, 4.0.4, 4.0.5
Fixed Version: Pending
Server:
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista, Windows x64, Windows 2008
Related Issues:

[frs-284] FRAM doesn’t start with message “This account is currently not available.”


Symptoms

FRAM will not start and throws the message below.

This account is currently not available.

Background

On *nix, it's common to have users whose shells are restrictive, i.e. inhibit login. A common way of doing this is to have /usr/sbin/nologin as their shell.
Our FRAM service requires a shell in order to start correctly.

Default behaviour (v4.0.4 and earlier)

Our startup script /etc/init.d/framd does the following:

su -c "/opt/fusionreactor/tomcat/bin/framd-real start" nobody
  • Uses the "su" command to run a command as another user (init.d scripts are run by init as root), in this case nobody
  • The framd-real script is the real script that starts FRAM

In the fault case, framd does not start because of the restricted shell for nobody.

Resolution

Add an additional parameter to su which allows us to specify a shell:

su -s "/bin/sh" -c "/opt/fusionreactor/tomcat/bin/framd-real start" nobody

This effectively bypasses /usr/sbin/nologin for the startup of FRAMd.

Important Notes

  • In this technote, we have assumed your JEE engine (eg JRun/ColdFusion) is running as the user "nobody". If this is not the case then you should replace the "nobody" references as appropriate. Please refer to https://www.fusion-reactor.com/support/kb/FRS-270.cfm for further details
  • In some cases where a user has run the installer twice on the same server, it's possible the /etc/init.d/framd script has been corrupted. If you do not see the command
    su -c "/opt/fusionreactor/tomcat/bin/framd-real start" nobody
    

    on line 27 in the file then please contact support.

Issue Details

Type: Technote
Issue Number: FRS-284
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 10/Jan/12 3:11 PM
Affects Version: 4.0.4
Fixed Version: Pending
Server:
Platform: Linux, MacOS, Solaris, AIX
Related Issues:

[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-277] “java.io.IOException: Cannot run program “ln”: error=12, Not enough space” error when installing FusionReactor from a NAS or other file-system with “root squashing” enabled


Symptom

Installation may fail if attempting to install from an NFS share with root squash enabled.

Analysis

This is because by default, the installer extracts temporary files into the parent directory of the installer location. As this would not typically be accessible, the installation is likely to fail with a message such as "java.io.IOException: Cannot run program "ln": error=12, Not enough space".

Resolution

To resolve this, first copy the installer to a local, writeable file-system (eg /var/tmp)

Documentation links

Console Installation on Linux
Console Installation on Solaris

Issue Details

Type: Technote
Issue Number: FRS-277
Components: Installer
Environment:
Resolution: Fixed
Last Updated: 02/Nov/11 11:22 AM
Affects Version:
Fixed Version: 4.0.0
Server:
Platform: Linux, MacOS, Solaris, AIX
Related Issues:

[frs-230] FusionReactor 3.5.x Release Notes and Resolved Issues



FusionReactor Rev. 3.5.x


RELEASE NOTES

Status: 17-Feburary-2011

Welcome to FusionReactor!

We appreciate your feedback. Please use the web form or send mail to:

support@fusion-reactor.com

These Release Notes describe what is contained in this release, provide
late-breaking news, and list additional documentation for the software.

For additional information on FusionReactor, please visit our website at:

https://www.fusion-reactor.com

For known issues and further support, please see the following web pages:

https://www.fusion-reactor.com/fr/faq.cfm
https://www.fusion-reactor.com/fr/support.cfm

To check for FusionReactor updates use the update page

RESOLVED ISSUES 3.5.5

Key Issue Type Summary
FR2001 Bug License/activation data corrupted due to concurrent access of multiple FR processes

RESOLVED ISSUES 3.5.4

Key Issue Type Summary
FR1836 Bug NullPointerException from JDBC on Railo on getMetaData in some cases
FR1958 Bug In some cases small AMF content is not flushed

RESOLVED ISSUES 3.5.3

Key Issue Type Summary
FR1744 Bug XML content in Railo breaks with a SAX Parser error (org.xml.sax.SAXParseException)
FR1747 Bug FusionReactor runs thousands of samples after it dehibernates (use schedule and not scheduleAtFixedRate)

RESOLVED ISSUES 3.5.2

Key Issue Type Summary
FR1724 Improvement AMF processor should handle a Target in the same way as a serviceName and serviceMethodName

RESOLVED ISSUES 3.5.1

Key Issue Type Summary
FR1704 Bug The Request Details button on the Slow Requests page did not work in FusionReactor 3.5.0. Pressing the Request Details button now correctly calls the Request Details page for requests shown on the Slow Requests page.
FR1706 Bug After a FusionReactor trail period had expired, FusionReactor used too many files handles and did not free them. File handles are now freed correctly. This issue did NOT affect FusionReactor installations that had a valid license, only installations where the trial period had expired and no license was uploaded.

RESOLVED ISSUES 3.5.0

Key Issue Type Summary
FR1648 New Feature Support for ColdFusion 9
FR1693 New Feature Support for Railo 3.1
FR1669 New Feature Support for JBoss 5.1
FR1692 New Feature Support for Windows 2008 Server R2
FR1681 New Feature Support for Windows 7
FR1670 New Feature Support for Mac OS X 10.6 "Snow Leopard"
FR1682 Improvement Support for Flash Player 10c and Flash Player 9 update 5
FR1676 Improvement FusionReactor Setup/Installer and Updater Support for 64 bit Windows machines
FR1667 Improvement FusionReactor's Flash content appears always on top when embedded in HTML in AIR. Use WMODE to correct the problem.
FR1666 Improvement Update Installation Guide
FR1664 Improvement Enhance FRAPI Request Surrogates to include more detail (see JavaDoc)
FR1660 Improvement Update FREM Release Candidate to the 3.5 CORE
FR1658 Improvement New AMF Deserializer implementation / Support for AMF handling Externalizable Objects
FR1650 Improvement FusionReactor Licencing support for AIX on JVM 1.5
FR1691 Bug Installer should select the "coldfusion" J2EE webapp by default when installing FusionReactor into ColdFusion 9
FR1687 Bug Crash Protection Alert Emails are not sent from FusionReactor instances installed in ColdFusion 9
FR1684 Bug Sockets used by FusionReactor's web server can enter CLOSE_WAIT indefinitely when invalid HTTP requests are received
FR1680 Bug Requests sometimes show "null" instead of the server name in CF9
FR1665 Bug Enterprise Dashboard should be able to cope with server names longer than 24 characters
FR1659 Bug Uninstall should only remove FusionReactor files
FR1657 Bug HTTP Post without headers causes a Java NullPointerException; FusionReactors web server can stop working
FR1643 Bug FusionReactor JDBC Wrapper as standalone JAR. It should be possible to place the FR JDBC Wrapper JAR in the same folder as the wrapped JDBC driver to avoid having to move JDBC drivers
FR1638 Bug Deadlock (out-of-order lock acquisition) between FusionReactor's JDBC driver and Metric Probe
FR1630 Bug JDBC Metrics are not tracked when no owning request can be found (eg. in CFTHREAD JDBC request)
FR1622 Bug Illegal State Exception / Response Has Been Closed with upstream Java app on Servet Forward/Includes in JRun. FusionReactor must not wrap a forward/include request if the the source request was already wrapped by FusionReactor.
FR1694 Bug A Race condition in stream data metrics could cause a CrashProtection Request Limit Email Notification to fail under extreme load conditions

Issue Details

Type: Technote
Issue Number: FRS-230
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: 08/Aug/11 11:18 AM
Affects Version:
Fixed Version: 3.5
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
Related Issues:

FRS-214: FusionReactor 3.0.1 Release Notes and Resolved Issues

FRS-251: FusionReactor 4.0.x Release Notes

[frs-198] Problems with installing or activating a license


FusionReactor License and Activation Issues

Version Check

We recommend that you first make sure that you have the most current version of FusionReactor installed as recent updates include license and activation fixes. You can download the most current version from the FusionReactor download page.

Problems and how to fix them

Typical problems

In the following section, we list the most often reported problems with the FusionReactor license and activation process as seen from the user's perspective. The typical causes of these problems are discussed subsequently, along with the steps necessary to solve them.

  1. Restarting the server expires a trial license or activation period immediately
  2. Attempting to activate a license with an expired activation period redirects to the login page (but the license was not activated)
  3. Installing a license shows an error page saying Can not upload license: null
  4. Installing a license silently fails (you get redirected to the login page but the license was not installed)
  5. Loss of license activation after reboot on some multi-server installations of FusionReactor 3.5.1

Typical causes

  1. Insufficient privileges of the server account when trying to write to the Java System Preferences Backing Store.
  2. A Java6 VM on Linux or Solaris that has no fix for SUN JVM bug 6519088
  3. Firefox browsers occasionally corrupting the license during the upload
  4. Trying to activate a license without a connection to the Internet (bug FR1409).

How to fix it

Insufficient privileges

The runtime user of the server on which FusionReactor is installed requires read/write access to the Java System Preferences Backing Store. Depending on the operating system, the location of this data store is different. On Windows the data is stored in the registry hive HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefs, the data belonging to FusionReactor is in HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefscomintergralfusionreactor.
Page 14 of the FusionReactor Installation Guide provides you with instructions how to adjust the permissions of this store.
On Linux and Solaris the data is typically stored in the directory /etc/.java/.systemPrefs as a hierarchy of directories containing XML files. The data belonging to FusionReactor is in the directory /etc/.java/.systemPrefs/com/intergral/fusionreactor. To set the necessary permissions execute the following command as user root:

chmod -R 777 /etc/.java/.systemPrefs

Alternative locations of the System Preferences Backing Store

Some JVMs try to create the System Preferences Backing Store in the directory $JAVA_HOME/.systemPrefs as a fallback solution if the directory /etc/.java/.systemPrefs cannot be created where $JAVA_HOME denotes the directory where the JVM itself is located (e.g. /opt/coldfusionmx/runtime/jre ).

We strongly recommend you to use /etc/.java/.systemPrefs as the one and only location of the System Preferences Backing Store. In case there is already data from other applications in $JAVA_HOME/.systemPrefs you should move it to /etc/.java/.systemPrefs and delete $JAVA_HOME/.systemPrefs afterwards (after you have adjusted the permissions of /etc/.java/.systemPrefs properly).

Clear the System Preferences Backing Store

If you attempt to install a license and you get the error message mentioned before:

Can not upload license: null

or simply

null

then you should stop the application server, clear the content of the Java System Preferences Backingstore and restart the application server.

On a Windows machine run the registry editor (regedit.exe or regedt32.exe) and then delete the key

HKEY_LOCAL_MACHINESOFTWAREJavaSoftPrefscomintergralfusionreactor

On a UNIX machine as user root delete the directory

/etc/.java/.systemPrefs/com/intergral/fusionreactor

If the permissions are configured correctly uploading a license and activating it will work properly afterwards.

On MacOS the System Preferences are stored as a set of *.plist files under the /Library/Preferences folder. Once the application server has stopped delete the file /Library/Preferences/com.intergral.fusionreactor.plist to clear all Preferences belonging to FusionReactor.

SUN Java 6 VM bug 6519088

This bug has been introduced with version 6 of the Linux and Solaris SUN Java VM and unfortunately has not been fixed even in the recently released version 6.0_05. We have a technote available at https://www.fusion-reactor.com/support/kb/FRS-168.cfm which provides you with detailed instruction how to apply a fix for this bug.

Bypassing problems with Firefox

If you upload a license with Firefox and nothing seems to happen (except that you have to login again) check the reactor-0.log file for the typical error message (see also https://www.fusion-reactor.com/support/kb/FRS-45.cfm) shown below

...
javax.crypto.IllegalBlockSizeException: Input length must be multiple of 8 when
decrypting with padded cipher
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_h.b(DashoA12275)
at com.sun.crypto.provider.SunJCE_ae.b(DashoA12275)
at com.sun.crypto.provider.PBEWithMD5AndDESCipher.engineDoFinal(DashoA12275)
at javax.crypto.Cipher.doFinal(DashoA12275)
...

If multiple retries of uploading the license file again do not change this try to upload the license from a different browser and/or computer. If this does not help neither manually copy the license file to FusionReactor/license/license.lic and restart the server.

Making the manual activation process work

As mentioned in the overview of this document there is a hotfix available that fixes the bug FR1409 in the previous FusionReactor version 3.0.0 where a license can only be activated if the computer has a connection to the Internet. Download: fusionreactor-hotfix1409.zip. It comes as a ZIP file containing a new version of the FusionReactor Java library (fusionreactor.jar) together with instructions how to apply the fix. However, we recommend to upgrade to a newer version, which does not require this hotfix.

Issue Details

Type: Technote
Issue Number: FRS-198
Components: License + Activation
Environment:
Resolution: Fixed
Last Updated: 30/Jul/11 12:02 AM
Affects Version: 3.0, 3.0.1
Fixed Version: 3.0, 3.0.1, 3.5
Server: ColdFusion 6, ColdFusion 7, ColdFusion 8, ColdFusion 9, Flex Data Services, JBoss, Jetty, JRun 4, LiveCycle Data Services, Railo, ServletExec, Tomcat, WebSphere, WebLogic
Platform: Windows XP, Windows 2000, Windows 2003, Linux, MacOS, Solaris, Windows Vista
Related Issues:

FRS-45: Why can’t I upload my license file (using Firefox)?

FRS-168: FusionReactor trial expires immediately on a Java6 VM running on Linux or Solaris

FRS-204: Safari web browser fails to upload license

[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-44] Why has my FusionReactor (trial) license expired unexpectedly?


You have installed FusionReactor successfully on a standard CF7 installation running on Linux and on the FusionReactor About page you read


FusionReactor Trial Version
10 days left

However, after having restarted the server FusionReactor won't let you log in again. It says:

Your FusionReactor license has expired.

You can unlock this version at any time by purchasing
a license key and uploading it using the form below.

When you check the server logs you can see statements like the following:

Jun 21, 2006 1:25:06 PM java.util.prefs.FileSystemPreferences syncWorld
WARNING: Couldn't flush system prefs: java.util.prefs.BackingStoreException:
/etc/.java/.systemPrefs/com/intergral create failed.

When you upload a license FusionReactor gets enabled although you still see the error message appearing in the server log. However, if you remove the license.lic file from the license folder (fusionreactor/license) FusionReactor expires again when restarting the server.

This is caused by the Java Preferences API which is used by FusionReactor to store its license information. For licenses of type enterprise (which the trial version is) this information is stored in the system Preferences, which is usually only writeable for administrative users (like root or Administrator).

In the error shown above the backing store is located in /etc/.java. If the user that runs the server where FusionReactor has been installed to has not sufficient privileges this error occurs.

To fix this on Linux/Unix, make a directory (if not already exists)

/etc/.java/.systemPrefs

and make sure it is world readable, writable

chmod -R 777 /etc/.java/.systemPrefs

Restart the server on which FusionReactor is installed.

On Windows, the backing store is usually kept in the registry. If the account of the server on which FusionReactor has been installed does not have sufficient privileges to access the HKEY_LOCAL_MACHINE hive, installing the trial license fails. Adjust the privileges of the server account so that it can write to the registry hive above.

Issue Details

Type: Technote
Issue Number: FRS-44
Components: FusionReactor Settings
Environment:
Resolution: Fixed
Last Updated: 07/Jun/10 11:37 AM
Affects Version: 2.0
Fixed Version: 2.0
Server:
Platform: Linux, Solaris
Related Issues:

FRS-54: Running FusionReactor on a server that runs under a non administrative user account

FRS-103: need to run CFMX7 under a different domain account allowing CFMX to have network access rights. However, as soon as I give CFMX this user account to run under, everything breaks with Fusion Reactor?

FRS-105: I manually installed FusionReactor using the built in web server on Port 8088 & everything seemed to work. I updated some settings in the interface, followed by a CF restart. All I see now is the License Expired screen. Is my license file old?