Release Notes

On all other supported platforms, the location of the /var folder is opt/Micro Focus/DPJ.

Prior to migrating custom rules from an earlier release of Code Review the current release of DevPartner Java Edition 4.5, you must delete any custom rules that are based on obsolete PMD rules. Code will stop responding when trying to start it if there are any custom rules that are not based on rules in the PMD ruleset used by Code Review. Code Review in DevPartner Java Edition uses PMD rules current to PMD 4.2.5. A list of current PMD rules can be found on the PMD Web site.

Custom rules are defined in the custom ruleset XML file to which it belongs. Use the following procedure to delete the rule.

1. Determine the custom rule that is based on the obsolete PMD rule.
2. Find the ruleset XML file to which the rule belongs and open it in a text editor. Ruleset XML files reside in the var\rulesets folder. See "var Folder Location for Code Review" for var folder locations.
3. Use the search function in the text editor to find the name of the custom rule to be deleted.
4. Use the text editor to highlight the entire rule definition, including the <rule></rule> tag. Rule definitions in the ruleset XML are contained within the <rule></rule> tag.
5. Press Delete to delete the text containing the rule.
6. Save the ruleset XML file using the text editor.

Custom Coding Rules Built Into Code Review

A complete list of the DevPartner Java Edition custom coding rules built into Code Review, with descriptions, is available in JRulesReference.html, in the product installation folder. For information about the PMD rules available through the Custom Rules page, see the PMD Web site.

var Folder Content Not Deleted When Uninstalling DevPartner Java Edition

The var folder and files in the var folder tree are not deleted when DevPartner Java Edition is uninstalled. The DevPartner Java Edition uninstall process does not indicate this. If reinstalling DevPartner Java Edition, the var folder content is used for the new installation. This means existing configuration, session files and other var folder content can be reused if it still exists. If permanently uninstalling DevPartner Java Edition, it is safe to delete the var folder and its content.

Known Issues  back to top

Administration Utility

Code Review

Profiling: All Analysis Types

Application Servers and DevPartner Java Edition nm* Utilities

Some application servers (e.g., Oracle Application Server and WebSphere Advanced Edition) take a longer time to stop than other application servers. If your application server has not completely stopped and you attempt to profile a program using an nm* utility from the command line, an error may be generated by the JDK.

Wait until the application server has completely stopped and then repeat the process of profiling your program.

Data Not Displaying for an Active Session

After installing a new DevPartner Java Edition release, data may not display when monitoring an active session. This is because the Java plug-in may be using cached applets from the previous release of DevPartner Java Edition.

To resolve this issue, clean out the Java plug-in's cache. Clearing the cache causes the plug-in to load applets from the new interface. You may also be able to disable the plug-in's option to cache applets. See the documentation for your plug-in for further information.

JVM Exception When Profiling Large Applications

When an application is profiled, its memory requirement increases because of the DevPartner Java Edition instrumentation. If the combined requirement of DevPartner Java Edition and the application being profiled exceeds the available memory, a JVM exception occurs. Memory Analysis results show only the memory usage for the application, not the DevPartner Java Edition overhead.

If you profile an application for performance without administrator permission on the driver used for performance timings on Vista and Windows 7, it will not start and accurate timings will not be available. If this happens, the session output displays a line indicating the Quantum driver did not successfully start. As a result, timings for Thread Time, Clock Time, and Wait Time do not display in the method details for Methods Spending the Most Time Waiting.

To work around this issue, you can adjust driver permissions to allow the driver to start and stop by a non-administrator process

To allow non-administrator processes to start and stop the driver, start a command line prompt as administrator. Enter the following:

sc sdset quantum D:(A;;CCLCSWLOCRRCRPWPDT;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA) (A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;SY)

As an alternate work around, you can manually start the driver before performing your first performance collection, then manually stop the driver after the last performance collection.

To manually start the Quantum driver, start a command line prompt as administrator. Enter the following:

sc start quantum

Stop the driver after your last collection using a similar command:

sc stop quantum

When you profile the application under Performance, you should now see a line in the Session Output tab that the driver has successfully attached to the process. Method details for each method in the Performance Summary - Methods Using the Most Thread Time graph will now show accurate timings for Thread Time, Clock Time, and Wait Time.

Object Retention Use While Profiling on Application Servers

Enabling object retention while profiling on an application server may result in the application server being unable to start. JVMTI specifications indicate that enabling method entry and exit events impact performance on many platforms and is not advised for performance critical usage such as profiling. Because of this, it is recommended that object retention not be active when running applications through an application server, since object retention requires the use of the JVMTI_EVENT_METHOD_ENTRY event.

Applications With Large Heap or Number of Objects

When running a memory analysis on an application that uses large amounts of heap or that creates a very large number of objects, DevPartner Java Edition may run out of memory. If this happens, the Memory Leaks Results Summary will show that no memory leaks were found for the following categories:

• Classes with the Most Average Leaked Instance Bytes Including Children
• Objects that Refer to the Most Leaked Bytes
• Classes with the Most Leaked Bytes

Examine the Session Output window for the profiled application session for the following statements:

"DPJ: Failed to create memory analysis snapshot. Out of memory while allocating objects in heap."

DevPartner Java Edition has run out of memory while trying to process a very large Java heap. To work around this issue, reduce the size of NM_MAX_SESSION_FILE or reducing the maximum size allocated to the Java virtual machine (JVM) heap using the -Xmx parameter, and profile the application again.

"DPJ: Failed to create snapshot: Memory allocation exception while processing object dump. The space reserved for creating snapshots may be full."

Set the environment variable NM_MAX_SESSION_FILE to a number larger than 192 and try to profile the application again. This environment variable controls how much space DevPartner Java Edition dedicates for a session file. The default value is 192, indicating that a maximum of 192 megabytes is available. If DevPartner Java Edition fills this space, it will generate the error shown above.

The default 192MB is sufficient for most profiling scenarios. The default NM_MAX_SESSION_FILE, however, is increased to 384MB when:

• Launching profiling sessions using the IBM Rational Application Developer plug-in to start WebSphere Application Server.
• Launching profiling sessions using the WebSphere Portal Server Test Environment on Windows.
• Using the Administration Console to register and start WebLogic 9.x on UNIX.

In those situations, you may need to reset NM_MAX_SESSION_FILE to a higher value.

DevPartner Java Edition limits the process space that the JVM used for profiling can request from the Operating System. For 32 bit applications this limit is usually 2GB, but in Windows this value can be lower. Within that process space, the JVM and the DevPartner profiling core inserted in the JVMs native space request memory allocation from the Operating System. Memory allocations for the -Xmx value and for DevPartner Java's NM_MAX_SESSION_FILE value are requested when the JVM starts. If the -Xmx value is set to 1024m when profiling starts, the JVM attempts to allocate 1024MB for the -Xmx value, and 192MB for the NM_MAX_SESSION_FILE. Additional memory supports native JVM operations and DevPartner Java Edition operations. The NM_MAX_SESSION_FILE memory block is used as an assembly area for the session file created when taking a snapshot.

During profiling, the JVM requests additional memory allocations as needed to support JVM and DevPartner Java Edition operations. DevPartner Java Edition tracks significant amounts for information while profiling, so additional memory allocation requests expected. For example, When a heap dump is requested during memory profiling, free memory space is used to store a copy of the heap within the C++ Heap of the JVM. The copy of the heap dump is analyzed and used with the tracking information DevPartner Java Edition maintains in the JVM to process a session file. It usually generates a memory allocation large enough to processes the data as a result.

Recommended guidelines for memory profiling are:

• Limit the -Xmx value to the amount needed to run the application until a snapshot can be taken. The lower value, the lower the memory requirement to maintain profiling data, and the lower the memory required to process a snapshot.
• Limit instrumentation by using inclusions or exclusions, which will lower the amount of memory needed to track instrumented classes and their objects.

• Watch the session output after requesting a snapshot. If you encounter a JVM exception or receive a session file missing data message in several categories, it is likely that the heap dump cannot be generated, and windows is not likely honoring the request from the java process for more memory to continue. If the successful heap dump occurs and errors occur afterward focus on increasing the NM_MAX_SESSION_FILE.

Note: the syntax is NM_MAX_SESSION_FILE=192. Do not append "M" to the numeric value.

Profiling: Coverage Analysis

Class Files Compiled Without Debugging Information

Any Class files that were compiled without debugging information will not appear in Coverage analysis session results. To get Coverage information on these classes, recompile them with debugging information and profile again.

For example, classes compiled with the javac compiler should have the -g flag enabled. Classes compiled with Ant using the javac task should have the debug="yes" attribute set.

Any classes not compiled with symbols will not have line number tables, therefore DevPartner Java Edition cannot properly instrument the methods in the classes. Those classes will be ignored and will not appear within the Coverage session results.

back to Known Issues list
back to top

Administration Utility

Application Server Configuration After DevPartner Java Edition Upgrades

After an upgrade, DevPartner Java Edition may not work properly with application servers configured using a previous release. Update the application server configurations to apply any enhancements in the new release.

1. Open the DevPartner Java Edition Administration Console.
2. Select a configuration in the left pane and click Modify.
3. In the Modify Configuration dialog box, click OK. You do not need to change the configuration settings; any changes are applied automatically.

Repeat these steps for each configuration.

back to Known Issues list
back to top

Operating System: Windows

Starting Default Browser on Windows Operating Systems

When starting a profiling session, the default browser does not automatically start on Windows Vista and Windows 2008 Server operating systems. To view the Session Control page, open the DevPartner Java Edition Start page and select the Active Sessions tab.

Application Servers Installed as a Service on Windows Operating Systems

When an application server is installed as a service on supported Windows operating systems other than Windows XP and Windows 2003 Server with the Data Execution Prevention (DEP) feature enabled, attempting to start the application server through the Application Server Testing tab causes an exception error. When DevPartner Java Edition attempts to start the service, it appears to DEP as an attempt to subvert services security. DEP terminates the application, forcing a system restart.

To work around this issue, disable DEP for services and controller applications.

1. Open the Windows Control Panel.
2. Select System Properties.
3. Select the Advanced Tab.
4. Under Performance, select Settings.
5. In the Performance Options, select Data Execution Prevention.

Note: If a message at the bottom of the dialog box indicates that your system processor does not support hardware-based DEP, contact Customer Support for assistance.

6. Select the radio button Turn on DEP for all programs and services except those I select.
7. From the list of programs, select Services and Controller Apps.
8. Select OK to close this dialog box and the System Properties dialog box.

Operating System: UNIX

Write Access for UNIX userID of All Processes

The UNIX userID of all processes to be profiled must have write access to the tmp folder. Check with your system administrator to ensure that affected userIDs have write access permissions. For example, if the Oracle OC4J integrated application server runs as user oracle, the oracle userID must have write access permissions to the tmp folder; otherwise the profiling session aborts just after startup and no session file is captured.

Wait Time Values on Solaris

The wait time values on Solaris incorrectly include the amount of time that each thread in your program spends in DevPartner Java Edition code. This is an overhead value that should be subtracted from clock time.

Operating System: AIX

IBM_JAVA_OPTIONS settings for WebLogic Server 9.1 and 9.2. on AIX

See the Known Issue in the Oracle BEA WebLogic section.

back to Known Issues list
back to top

JDK/JVM: IBM

IBM_JAVA_OPTIONS Environment Variable

Overwriting the IBM_JAVA_OPTIONS environment variable may prevent DevPartner Java Edition from profiling the target application.

DevPartner Java Edition uses the IBM_JAVA_OPTIONS environment variable as its technique for passing the profiler invocation directive to the IBM JVM. Make sure scripts or other tools append to this environment variable instead of overwriting it; otherwise DevPartner Java Edition's launch points (nmshell, nmjava, Application Server Testing tab, etc.) may be unable to profile the target application. For an example, see this Known Issue in the Oracle BEA WebLogic section.

JDK/JVM: JRockit

JRockit 5.0 and Memory Analysis

An issue in JRockit 5.0 prevents memory analysis from being performed on applications running under that JVM.

WebLogic 9.x uses this release of JRockit by default. To perform Memory analysis, point the JVM to Sun in the WebLogic script (default location BEA_domain\bin\SetDomainEnv.cmd).

back to Known Issues list
back to top

Browser: All

Out of Memory Error When Viewing Session Files

If an out of memory error occurs when opening a session file during a profile test, reset -Xmx to a higher number, for example 512. Perform the following to reset -Xmx.

1. Navigate to the following location, depending on operating system.

• Windows XP, or 2003 Server — /Documents and Settings/All Users/Application Data/Micro Focus/DevPartner Java Edition/var/conf

Note: By default, the Application Data folder is hidden. To display the \var folder and its contents, type the path in the Address bar of Windows Explorer and press Enter.

• Other Supported Windows operating systems — /Program Data/Micro Focus/DevPartner Java Edition/var/conf

On Linux and Solaris platforms, the location of the /var folder is opt/Micro Focus/DPJ.

2. Open DPJServer.args in a text editor.
3. Locate the -Xmx line and change the setting to a higher number, for example 512 or higher as needed.
4. Save and close the file.
5. Stop DevPartner Java Edition from the DevPartner Java Control Service user interface.
6. Restart DevPartner Java Edition from the DevPartner Java Control Service user interface.
7. Open the DevPartner Java Edition interface.
8. Open the session file.

Browser: Internet Explorer

Viewing DevPartner Java Edition Pages With Internet Explorer 6.0

A security warning may appear when attempting to view certain DevPartner Java Edition pages with Internet Explorer 6.0. If you see a security warning, modify your security settings as follows.

1. Click Tools>Internet Options.
2. In the Internet Options dialog box, select the Security tab.
3. Select the Local intranet icon, then click Custom Level.
4. In the Security Settings dialog box, scroll to Run ActiveX Controls and plug-ins and verify that Enable is selected.
5. Click OK to close the Security Settings dialog box, then click OK to close the Internet Options dialog box.

Note: JavaScript must also be enabled.

Browser: Firefox

Using nmjava with Firefox as the Default Browser

If Mozilla Firefox is set as the default browser, starting a profiling session using the nmjava command may not automatically launch the active DevPartner Java Edition session in the Firefox browser window. Though this issue has been verified to not occur with Firefox 3.0 or later, it may occur using earlier releases of Firefox. To work around this possible issue, start DevPartner Java Edition from the Start button (Start>All Programs>Micro Focus>DevPartner Java Edition>DevPartner Java Edition), then view active processes from the Active Sessions or Application Server Testing tab.

back to Known Issues list
back to top

Application Servers: All

Application Server Seems to Stop Responding for Memory Analysis When Reattaching

If detaching from an application server after running Memory Analysis, you may encounter an error message that DevPartner Java Edition cannot perform the desired analysis when attempting to immediately reattach to the application server for another analysis type. This occurs when Ram Footprint data is viewed during the Memory Analysis session.

This issue occurs if the application server manager attempts to process the reattach before the detach process for Memory Analysis has completed. The application server manager immediately detaches when the detach message is received without verifying the session status. This allows DevPartner Java Edition to reattach, potentially before the detach process for Memory Analysis has actually completed. As a result, the Attach button in the DevPartner Java Edition Application Server Testing tab may be enabled before the detach has completed. Depending on the amount of test activity in the Memory Analysis session, the entire detach process could take several minutes to complete.

To work around this issue, wait after detaching until the application server state changes from Available Memory to Available before attempting to reattach to the application server for another analysis type. Stopping and restarting DevPartner Java Edition may also work around this issue.

Starting and Stopping Application Servers

Starting and stopping an application server before the application server is in a stable state may yield unexpected results. If you take snapshots before application server is fully started, you may see incorrect states for your application server. If you stop a server before it is fully started, either using the nmserver command or through the DevPartner Java Edition interface, when you restart it profiling may not work correctly because the stop process never completed properly.

If any of these situations occur, you may need to stop your application server manually, then stop NCSP and restart it. Execute the following from the command line to stop and restart NCSP.

sendncs -stop
sendncs -start

Always make sure your application server is fully started and ready before beginning to profile it.

Application Servers: Oracle BEA WebLogic

IBM_JAVA_OPTIONS Settings for WebLogic Server 9.1 and 9.2 on AIX

WebLogic Server for AIX ships with the following release notes statement regarding a workaround for the serial version UID mismatch problem.

"A serial version UID mismatch is encountered when using WebLogic Server 9.2 on AIX with IBM Java 5 SR2":

Serial Version UID Mismatch
A serial version UID mismatch is encountered when using WLS 9.2 with IBM Java 5 SR2.

To work around this issue, modify the file BEA_HOME/Weblogic92/common/bin/commEnv.sh to include the following command:

JAVA_OPTIONS="$JAVA_OPTIONS -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"

You can also use the following command line option:

export IBM_JAVA_OPTIONS="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"

The first approach should be compatible with DevPartner Java Edition. The alternative approach, however, prevents DevPartner Java Edition from profiling the WebLogic application server. Because DevPartner Java Edition uses the IBM_JAVA_OPTIONS environment variable as its technique for passing the profiler invocation directive to the JVM, you must be certain that existing IBM_JAVA_OPTIONS settings pass down and through your commEnv.sh or setDomainEnv.sh scripts as appropriate. If you use the alternative approach, change your environment script to use the following syntax:

IBM_JAVA_OPTIONS="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0 ${IBM_JAVA_OPTIONS}" export IBM_JAVA_OPTIONS

In particular, you must use the additional ${IBM_JAVA_OPTIONS} clause.

Note: Make certain scripts or other tools append to the IBM_JAVA_OPTIONS environment variable and do not overwrite it; otherwise DevPartner Java Edition's launch points (nmshell, nmjava, Application Server Testing tab, etc.) may be unable to profile the target application.

Memory Analysis Fails Under WebLogic 9.x.

Because of an issue in JRockit 5.0, memory analysis cannot be performed on applications running under this JVM. WebLogic 9.x uses this release of JRockit by default. To perform Memory analysis, point the JVM to Sun in the WebLogic script (default location BEA_domain\bin\SetDomainEnv.cmd).

Starting Memory Analysis with WebLogic 10.3 running under Sun JDK

When starting Memory Analysis with WebLogic 10.3 under a Sun JDK, Memory Analysis may stop responding during Stripchart analysis. This issue is due to the allocated heap size specified in the setDomainEnv script used by the WebLogic Start script, which is not enough to start WebLogic 10.3 together with DevPartner Java.

To resolve this issue, update the MEM_PERM_SIZE and MEM_MAX_PERM_SIZE settings in the SetDomainEnv script to allocate enough heap to start WebLogic 10.3 together with DevPartner Java.

Open the script in a text editor and find the MEM_PERM_SIZE and MEM_MAX_PERM_SIZE settings. Change the setting values from:

set MEM_PERM_SIZE=-XX:PermSize=48m
set MEM_MAX_PERM_SIZE=-XX:MaxPermSize=128m

to:

set MEM_PERM_SIZE=-XX:PermSize=128m
set MEM_MAX_PERM_SIZE=-XX:MaxPermSize=128m

If the issue continues after updating the setting values, consider updating the setting values higher, such as to 256m.

Application Servers: IBM WebSphere

WebSphere Application Server Security on UNIX

If enabling WebSphere Application Server security in UNIX, you must provide authentication information when stopping the WebSphere application server.

One option is to place the authentication data in a properties file that the shutdown operation reads. The default file for this data is the soap.client.props file in the properties folder for the WebSphere Application Server. If server shutdown is impeded because the DevPartner Java Edition UI waits for user authentication, then you should update the authentication information under soap.client.props.

Another option is to provide username and password values using the Authentication dialog box.

Note: The Authentication dialog box appears only if you launch NCSP from within an X Windows session and the DISPLAY variable is set, or when you are working locally within the UNIX machine's desktop.

See the help topic "Using Administrative Clients>Using command line tools" in the WebSphere 6.1 documentation for background on WebSphere 6.1 security and the technique DevPartner Java Edition uses to shut down the application server, particularly the section "Example: Security and the command line tools".

Fully Starting WebSphere Before Performing Memory Analysis

WebSphere may stop responding if data is requested before warm-up is completed. When performing Memory analysis on an application that is running in a newly started WebSphere application server, allow WebSphere to reach a steady state before clicking View Results to create a snapshot and display a session file. Otherwise, collecting data for the session file could cause WebSphere to stop responding.

Note: The warm-up period may take several minutes on some computers.

WebSphere Automatic Start When Starting the WebSphere Administration Server

The WebSphere application server may be configured so that it does not start automatically when the WebSphere Administration Server starts. If configured this way, starting WebSphere from the DevPartner Java Edition user interface causes the WebSphere application server status to report as Running, Not Available.

If you try to start one of the actual application servers (such as the Default server), DevPartner Java Edition hooks to that application server and changes the WebSphere application server status to Running Under Session. You can profile any application and data collects as expected.

Manually Starting WebSphere 7.0 Using DPJ JVM Arguments

Due to an IBM issue, if starting WebSphere 7.0 manually using the DPJ JVM arguments, you must also set the genericJVMarguments setting to -XShareclasses:none in the file server.xml. This is necessary to prevent DevPartner Java Edition from not responding and to ensure instrumentation and JRE runtime remain compatible.

Application Servers: Oracle (OC4J)

Profiling in More than One Instance of OC4J Standalone

Simultaneously running more than one instance of OC4J Standalone when profiling can yield unexpected results. Profile only a single instance. After starting one instance, all OC4J components show as "started".

back to Known Issues list
back to top

Code Review

PMD Rules Error Encounters an Error on UNIX When Closing

Stopping the Code Review Rules Designer on UNIX platforms causes a file not found exception error. To resolve this issue, create an empty file in the user profile home folder, or in the \root folder for root users. Name the file .pmd_designer.

Creating or Editing Custom Rules With Multiple Properties

The Edit view of the Custom Rules page does not support creating or editing custom rules with multiple properties. You can, however, use an XML editor to create or edit a custom rule within the ruleset's XML file; when you select the ruleset in the Custom Rules page, the custom rule will be included in profiling. The XML files containing the PMD custom rulesets are contained the following folders.

• Windows XP or 2003 Server — C:\Documents and Settings\All Users\Application Data\Micro Focus\DevPartner Java Edition\var\rulesets

Note: By default, the \Application Data folder is hidden. To display the \var folder and its contents, type the path in the Address bar of Windows Explorer and press Enter.

• Other Supported Windows operating systems — C:\Program Data\Micro Focus\DevPartner Java Edition\var\rulesets

On all UNIX platforms, the location of the /rulesets folder is /opt/Micro Focus/DPJ/var.

For more information about creating rules, refer to the PMD tutorial.

Note: Make a backup copy of the ruleset file before editing it outside the Code Review interface.

back to Known Issues list
back to top

Contacting Micro Focus Customer Care   back to top

If ever you have any problems or you would like additional technical information or advice, there are several sources. In some countries, product support from Micro Focus may be available only to customers who have maintenance agreements.

If you obtained this product directly from Micro Focus, contact us as described below. If you obtained it from another source, such as an authorized distributor, contact them for help first. If they are unable to help, contact us as described below.

However you contact us, please try to include the information below, if you have it. The more information you can give, the better Product Support can help you. But if you don't know all the answers, or you think some are irrelevant to your problem, please give whatever information you have.

• The name, release (version), and build number of the product.
• Installation information, including installed options, whether the product uses local or network databases, whether it is installed in the default folders, whether it is a standalone or network installation, and whether it is a client or server installation.
• Environment information, such as the operating system and release on which the product is installed, memory, hardware/network specifications, and the names and releases of other applications that were running.
• The location of the problem in the product software, and the actions taken before the problem occurred.
• The exact product error message, if any.
• The exact application, licensing, or operating system error messages, if any.
• Your Micro Focus client, office, or site number, if available.

Contact

Our Web site gives up-to-date details of contact numbers and addresses. The product support pages contain considerable additional information, including the WebSync service, where you can download fixes and documentation updates. To connect, enter www.microfocus.com in your browser to go to the Micro Focus home page.

If you are a Micro Focus Product Support customer, please see your Product Support Handbook for contact information. You can download it from our Web site or order it in printed form from your sales representative. Support from Micro Focus may be available only to customers who have maintenance agreements.