RTView® Enterprise Monitor - Release Notes

Version 3.4.0 Release Notes

Configuration

20690: Added an update_wars script for miscmon

In rtvapm/projects/emsample/servers, the individual servers have "update_wars" scripts that can be used to make server-specific war files. The "miscmon" server directory now has update_wars scripts as well.

Deployment

21600: Emsample central servers now support rtvquery servlets

In the emsample project, the script make_all_wars in emsample/webapps will now also make emsample_rtvquery.war.

Navigation

21399: Customization of default EM tabs now supported

EM has been enhanced to support customizing the order and visibility of the tabs in emsample either globally or per-role. By default, EM will show the following tabs in this order: SERVICE TREE, SERVICE VIEWS, COMPONENTS, ALERTS, ADMIN These tabs are followed by all user defined tabs from rtv_custom.xml. The $rtvNavTabList substitution supports a comma separated list of Tab ID's which will override the default tab list. The initial display will be set to the first item in the navtree for the first tab in the list. For example, the following property in central.properties will limit the tabs to Custom, SERVICE TREE and ADMIN, in that order: uiprocess.sl.rtview.sub=$rtvNavTabList:Custom,CMDB,Admin To specify different tabs per role, add this substitution to your roles.xml set to the list of tabs for that role. For example, the following will set the tabs for the admin role to ADMIN, SERVICE TREE, ALERTS in that order: <role> <name>admin</name> <displays> <include>ALL</include> </displays> <sub name="$rtvNavTabList" value="Admin,CMDB,Alerts"/> </role> Roles that set $rtvNavTabList to blank will get the default tabs (listed above). Roles that do not set $rtvNavTabList will get the global value set in central.properties. If no value was set in central.properties, it will get the default tabs. These are the Tab IDs for the standard EM tabs: Tab ID - Tab Label ============ CMDB - SERVICE TREE Service - SERVICE VIEWS Components - COMPONENTS Alerts - ALERTS Admin - ADMIN For user defined tabs, use the value in the TabID column of the TabTreeSelection table in rtv_custom.xml.

RTVMGR

21553: OS Version displays correctly on JVM Summary display

The upper area of the COMPONENTS, Processes > JVM Processes > SingleJVM > JVM Summary display has been enhanced to avoid the "OS Version" string from overrunning the allocated width.

RTView Core Functionality

21524: Format Table Columns function enhanced to preserve numeric column types

The Format Table Columns function supports a new argument, described below, to control its treatment of numeric columns. Format Mode - If 0 then all numeric columns are converted to strings in the result, using the local default format for any numeric columns not specified in Column Format(s). If Format Mode is nonzero, then only the numeric columns specified in Column Format(s) are formatted, all other numeric columns in the table remain numeric. The default value of Format Mode is zero, which makes the function behave as it did prior to this enhancement.

21582: Thin Client now adds scrollbars at smaller resolutions

Displays in the thin client with a minimum size and resize mode = Layout now correctly display scrollbars at smaller resolutions.

Commands

21562: Open Browser command enhanced to open the url in a new browser tab

For an Open Browser command with Browser Window = Named and Window Name = _tab, the thin client will now open the URL in a new browser tab rather than in a popup browser window. In all other cases the command behaves as in prior versions. This feature requires the browser's settings to be configured to automatically open a new tab for popup windows. That is the default setting in all browsers. But if the settings are configured to open popups in a new window, then the Open Browser command will open the URL in a new window as in prior releases.

Data Sources

20881: Version Restriction Removed for MQ Client jars

Previously the IBM MQ data adapter checked for the presence of a class that was only in a version specific set of MQ client jars. This is no longer the case. Users can now use any version of MQ client jars (greater than or equal to MQ version 6.0) in their classpath when using the IBM MQ data adapter. Note: Since the actual set of required MQ client jars varies by version of MQ, it is suggested that the set of MQ Client jars be put in a directory so that the java classpath "wildcard" mechanism can be used to refer to all the jars in a directory, rather than having to enumerate every jar file on the classpath. The RTV_USERPATH environment variable can be used to set a user defined classpath. for example: SET RTV_USERPATH=".;.\lib_7.1\*" or SET RTV_USERPATH=".;.\lib_7.5\*" Note: for later versions of MQ (8.0, 9.0) a single relocatable jar com.ibm.mq.allclient.jar is available.

21151: Provide mechanism to connect to secure Tomcat instances via JMX

A mechanism has been added to connect to secure Tomcat instances via JMX. A secure connection requires the use of the following two parameters: javax.net.ssl.trustStore javax.net.ssl.trustStorePassword Please see the User's Guide for more information.

21313: SSL Protocol field added to Splunk Connection

The Splunk data adapter has been enhanced to allow explicit management of the SSL Protocol used when communicating to the Splunk server. A new field "SSL Protocol" has been added to the Add Splunk Connection dialog. This allows you to explicitly select the SSL Protocol used when communicating to the Splunk server, by means of a drop down. The SSL protocols available are SSLv3, TLSv1, TLSv1.1 (TLSv1_1) and TLSv1.2 (TLSv1_2). TLSv1 is selected by default as "TLSv1 is available by default in every modern version of Java" SSL protocols are configured on the Splunk server using the "sslVersions" property as described in http://docs.splunk.com/Documentation/Splunk/latest/Security/SetyourSSLversion The client (Splunk data adapter) connection will, obviously, have to use a compatible SSL protocol connect. Use of explicit SLL protocol requires use of com.splunk.SSLSecurityProtocol found in the Splunk Java SDK jar (splunk-sdk-java-1.5.0.jar). A modified version of this .jar is provided with RTView. It has been modified to remove dependency on the existence of a ".splunkrc" file in the users home directory, which a client system may not have. Protocol Limitations ----------------------------- Different versions of Java have added and removed support for different SSL protocols, so users will need to choose an SSL protocol that is supported by your Java runtime. TLSv1 is used as default by RTView as "TLSv1 is available by default in every modern version of Java" SSLv3 is provided for backwards compatibility, but its use is discouraged due to the "POODLE" vulnerability as described here: http://www.splunk.com/view/SP-CAAANKE SSLv3 is disabled in recent versions of Java (1.7 + 1.8+) for this reason, and will fail with an error message of the form "java.lang.RuntimeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)" TLSv1.1 and TLSv1.2 are not available in Java 1.6 and will fail with an error message of the form java.lang.IllegalArgumentException: TLSv1.1 or java.lang.IllegalArgumentException: TLSv1.2

21596: Custom handler for IBM MQ connections

A custom handler for IBM MQ connections has been added. Note: This release note assumes you have a working knowledge of writing, compiling and deploying Java classes IBM MQ Connections created with RTView may now have a handler associated with then, which allows the programmatic setting of additional properties associated with that connection. The handler associated with a connection is specified as a fully qualified class name, in the IBM connection dialog thus: Handler Class: Fully Qualified Class Name of GmsRtViewIbmMqDsConnectionHandler subclass This is equivalent to the "handler=<fully qualified class name>" field in the ibmmq connection string. The named class is loaded at runtime using the user specified class path (RTV_USERPATH environment variable), and thus the user may specify a unique handler per connection, or share one handler between multiple connections. The handler must be a subclass of the (com.sl.gmsjibmmqds)GmsRtViewIbmMqDsConnectionHandler defined in the gmsjibmmqds.jar file in the RTV_HOME/lib directory. Your handler should override the public Hashtable getConnectionProperties(String connectionName) method and return a hashtable populated with additional properties for the named connection. Example uses might be to set user name and password on a per connection basis, or establish a secure connection to using user configured SSL. *** Example - set username / password in MQ data source *** This example will create a java class named MyMqHandler that extends the GmsRtViewIbmMqDsConnectionHandler class. In MyMqHandler.java, define the following method: public Hashtable getConnectionProperties(String connectionName) This method will be called to retrieve the additional (userID, password) properties used when RTView creates an MQ connection, where the handler field has been set to MyMqHandler Add RTV_HOME/lib/gmsjibmmqds.jar to your classpath when you compile MyMqHandler. The compiled MyMqHandler class file must be included in the RTView classpath by adding it to the definition for the RTV_USERPATH environment variable. The following source code is an example of MyMqHandler: // import com.sl.gmsjibmmqds to reference the com.sl.gmsjibmmqds.GmsRtViewIbmMqDsConnectionHandler class import com.sl.gmsjibmmqds.*; // import java.util to reference the java.util.Hashtable import java.util.*; /** * This example class MyMqHandler extends the GmsRtViewIbmMqDsConnectionHandler class * to set userID and password properties */ public class MyMqHandler extends GmsRtViewIbmMqDsConnectionHandler { /** * Subclasses should override this method (getConnectionProperties) to return * a Hashtable of connection properties suitable to pass into the * MQQueueManager constructor * as described in the IBM WebSphere MQ classes for Java API documentation. * <p> * * @param connectionName rtview ibmmqds connection name * @return populated Hashtable of connection properties */ @Override public Hashtable getConnectionProperties (String connectionName) { Hashtable connectionProperties = new Hashtable(); System.out.println("MyMqHandler: Setting connection properties for connection: " + connectionName); // Set userID and password variables String userID = "MyUserID"; String password = "MyPassword"; // Set userID and password variables, differently, based on connection name if (connectionName.equals("SomeConnection")) { userID = "MyOtherUserId"; password = "MyOtherPassword"; } // Set userID and password properties in Hastable to be returned System.out.println("MyMqHandler:[" + connectionName + "] Setting userID: " + userID); connectionProperties.put("userID" /* CMQC.USER_ID_PROPERTY */ , userID); System.out.println("MyMqHandler:[" + connectionName + "] Setting password: " + password); connectionProperties.put("password" /* CMQC.PASSWORD_PROPERTY */ , password); // return populated connection properties return connectionProperties; } } Note: users should replace "MyUserID", "MyPassword" / "MyOtherUserId", "MyOtherPassword" as appropriate, or use some approved method to fetch these values, to avoid having them exposed in plain text. Note: This example uses the literal values ("userID", "password") for properties for simplicity to avoid dependencies on the equivalent property constant values, in the relevant IBM MQ Java client libraries. The constant values could be used by adding the appropriate import statement and adding the relevant jar file to the classpath at build and run-time. *** Using SSL for MQ connections *** To use SSL with RTView you will need to create a Java class that extends the GmsRtViewIbmMqDsConnectionHandler class to provide the relevant properties to establish an SSL connection. In our example we will create a handler called MySSLMqHandler In MySSLMqHandler.java, define the following method: public Hashtable getConnectionProperties (String connectionName) This method will be called to set and return the retrieve the additional SSL properties required for a named MQ connection. In this example we assume a shared truststore / keystore to be used for multiple connections. Add RTV_HOME/lib/gmsjibmmqds.jar to your classpath when you compile MyMqHandler. The compiled MyMqHandler class file must be included in the RTView classpath by adding it to the definition for the RTV_USERPATH environment variable. The following is an example of MySSLMqHandler: // import com.sl.gmsjibmmqds to reference the com.sl.gmsjibmmqds.GmsRtViewIbmMqDsConnectionHandler class import com.sl.gmsjibmmqds.*; // import java.util to reference the java.util.Hashtable import java.util.*; /** * This example class MySSLMqHandler extends the GmsRtViewIbmMqDsConnectionHandler class * to set SSL connection properties */ public class MySSLMqHandler extends GmsRtViewIbmMqDsConnectionHandler { /** * Subclasses should override this method (getConnectionProperties) to return * a Hashtable of connection properties suitable to pass into the * MQQueueManager constructor * as described in the IBM WebSphere MQ classes for Java API documentation. * <p> * * @param connectionName rtview ibmmqds connection name * @return populated Hashtable of connection properties */ @Override public Hashtable getConnectionProperties (String connectionName) { Hashtable connectionProperties = new Hashtable(); System.out.println("MySSLMqHandler: Setting connection properties for connection: " + connectionName); // Set userID and password variables String userID = "MyUserID"; String password = "MyPassword"; // Set userID and password variables, differently, based on connection name if (connectionName.equals("SomeConnection")) { userID = "MyOtherUserId"; password = "MyOtherPassword"; } // Set userID and password properties in Hastable to be returned System.out.println("MySSLMqHandler:[" + connectionName + "] Setting userID: " + userID); connectionProperties.put("userID" /* CMQC.USER_ID_PROPERTY */ , userID); System.out.println("MySSLMqHandler:[" + connectionName + "] Setting password: " + password); connectionProperties.put("password" /* CMQC.PASSWORD_PROPERTY */ , password); // set SLL variables ( trust store, key store, cipher suite) String trustStore = "MyTrustStore.jks"; String trustStorePassword = "MyTrustStorePassword"; String keystore = "MyKeyStore.jks"; String keystorePassword = "MyKeyStorePassword"; String transport = "MQSeries Client"; String cipherSuite = "TLS_RSA_WITH_AES_256_CBC_SHA"; // Set connection SSL properties System.setProperty("javax.net.ssl.trustStore", trustStore); System.setProperty("javax.net.ssl.trustStorePassword", trustStorePassword); System.setProperty("javax.net.ssl.keyStore", keystore); System.setProperty("javax.net.ssl.keyStorePassword", keystorePassword); System.out.println("MySSLMqHandler:[" + connectionName + "] Setting trustStore: " + trustStore); connectionProperties.put("javax.net.ssl.trustStore", trustStore); System.out.println("MySSLMqHandler:[" + connectionName + "] Setting trustStorePassword: " + trustStorePassword); connectionProperties.put("javax.net.ssl.trustStorePassword", trustStorePassword); System.out.println("MySSLMqHandler:[" + connectionName + "] Setting keyStore: " + keystore); connectionProperties.put("javax.net.ssl.keyStore", keystore); System.out.println("MySSLMqHandler:[" + connectionName + "] Setting keyStorePassword: " + keystorePassword); connectionProperties.put("javax.net.ssl.keyStorePassword", keystorePassword); System.out.println("MySSLMqHandler:[" + connectionName + "] Setting transport: " + transport); connectionProperties.put("transport" /* CMQC.TRANSPORT_PROPERTY */ , transport /*CMQC.TRANSPORT_MQSERIES_CLIENT) */) ; System.out.println("MySSLMqHandler:[" + connectionName + "] Setting SSL Cipher Suite: " + cipherSuite); connectionProperties.put("SSL Cipher Suite" /* CMQC.SSL_CIPHER_SUITE_PROPERTY */ , cipherSuite); // return populated connection properties return connectionProperties; } } Note: users should replace the "My..." variable values as appropriate, or use some approved method to fetch these values, to avoid having them exposed in plain text. The Cipher suite given is an example. Supported cipher suited vary by MQ server version, JDK/JRE version and JVM configuration. Note: This example uses the literal values ("userID", "password", etc) for properties for simplicity to avoid dependencies on the equivalent property constant values, in the relevant IBM MQ Java client libraries. The constant values could be used by adding the appropriate import statement and adding the relevant jar file to the classpath at build and run-time. Note: If using the Oracle JRE/ JVM you may need to use the following JVM flags to achieve the same run time behaviour as the IBM JRE/JVM: -Dcom.ibm.mq.cfg.preferTLS=false -Dcom.ibm.mq.cfg.useIBMCipherMappings=false

21602: Enhanced error statement provided when malformed JSON encountered by DefaultJsonHandler

The DefaultJsonHandler expects well formed JSON to parse and extract GmsTabularData. If that JSON is malformed or terminates unexpectedly, Google's gson JSON parser may throw an exception. RTView has been enhanced to provide additional error information when this occurs. The additional context may help in determining the originating source and cause of the malformed JSON encountered by the JSON parser. Users will see a stack trace preceded by the following message: ERROR: Exception when parsing JSON body: .... ...and followed by the following new context information: ERROR: JSON Body parse error additonal context: ADDRESS = [<ADDRESS>], URI = [<URI>], Content-length = [<contentLength] where <ADDRESS >= address (host:port) of sender of JSON body payload <URI>=URI for HTTP post request (intended destination of posted data) <Content-length>=The length of the response body in octets (8-bit bytes)

Demos

20890: Corrected mismatch in column names in the data attachment

Some column names in the eSphere demo were not corrected when the database was changed to use HSQLDB. This has been corrected.

Display Server

21525: Added support for removing items from thin client context menu

Items can now be removed from the thin client context menu. This is done by specifying the names of the items in a property named MenuItemsToHide in rtvdisplay.properties. Multiple names are separated by commas. For example, the following will remove the "Export Table To HTML", "Export Table to Excel", "Export PDF", and "Status" items from the menu: MenuItemsToHide=PDF,ExcelTable,HtmlTable,Stat After adding the MenuItemsToHide property to rtvdisplay.properties, the corresponding .war file must be rebuilt and redeployed. Here are the names of all of the menu items, with the English label string of the menu item in quotes if it differs from the item name: Refresh Back Next Command "Execute Command" Drill "Drill Down" ExcelTable "Export Table to Excel" (Internet Explorer only) HtmlTable "Export Table to HTML" PDF "Export PDF" CopyCell "Copy Cell Value" Stat "Status" Logoff "Log Off" Use the menu item name when configuring MenuItemsToHide, not the label string.

Logging

19451: Viewer and builder now print copyright to log4j output

Previously the Display Viewer and Builder did not show the copyright banner in log files created using Log4j. This has been corrected.

Object Library

21564: New Link Path Types have been added

RTView links have been enhanced to support two new linkPathType property values: Horizontal Square - Links are drawn from the right/left side of the parent closest to the child to the right/left side of the child closest to the parent. The link is straight if the parent and child are aligned horizontally, otherwise the link line has two 90 degree angles. This linkPathType has a limitation when the right/left side of the parent and child nodes overlap. In this case, the link line will be clipped. Vertical Square - Links are drawn from the top/bottom side of the parent closest to the child to the top/bottom side of the child closest to the parent. The link is straight if the parent and child are aligned vertically, otherwise the link line has two 90 degree angles. This linkPathType has a limitation when the top/bottom side of the parent and child nodes overlap. In this case, the link line will be clipped. The links have also been enhanced with a new property, linkCrossBarSpacing, in the Link Line category. This property is only applied if the linkPathType is set to Horizontal Square or Vertical Square. If this property is set to -1, the perpendicular line between the parent and child nodes is positioned in the center of the space between the parent and child nodes. Otherwise, it is positioned the specified number of pixels from the parent node. If the value is greater than the space between the parent and child nodes, the perpendicular line will be drawn in the center of the available space. Links with these linkPathTypes have been added to the Links palette in the builder. The Horizontal Square and Orthogonal links look the same in the palette, but the linkPathType is shown in the status area to help differentiate them.

RTView Display Panel

21508: Support subtitutions in display value in panel config

The rtvDisplayPanel tag in a PANELS.ini file now supports using an application level substitution or login substitution for the display value as long as the substitution name starts with a $. For example: <?xml version="1.0" ?> <panels xmlns="www.sl.com" version="1.0"> <rtvLayout title="Example"> <rtvDisplayPanel region="north" name="title" display="$my_title"/> <rtvDisplayPanel region="center" name="main" display="$my_main"/> </rtvLayout> </panels>

TIBCO EMS Manager

21275: EMS Manager retired

The TIBCO EMS Manager application is no longer supported and has been removed from RTView Core. It has been replaced by the RTView TIBCO EMS Monitor application. TIBCO EMS Manager users should contact SL about moving over to RTView TIBCO EMS Monitor.

Transaction Message Monitor

21514: Transaction monitor end-of-life delayed

In RTView 6.5, the Transaction Monitor was updated with a warning regarding the end of life of that product. The retirement of the Transaction Monitor has been postponed and the warning has been removed.

Scripts

21337: Windows scripts no longer fail if no rtview.properties file is missing

The rtvapm run scripts (rundata, runhist, etc.) now run without error if rtview.properties are missing from the project directory.

21439: Added common scripts for making .war files

A new set of common scripts has been added for making .war files for the RTView servlets. They are: make_rtvdata_war.bat/sh make_rtvdisplay_war.bat/sh make_rtvquery_war.bat/sh make_rtvagent_war.bat/sh These scripts may be executed from any directory and will put the war files there. When you run the scripts you specify an appname (which will be used to name the war file) and you may specify a host and port. (For the display servlet you may also specify a backup port.) You may also put a copy of the servlet's properties file in the current directory and it will be used in the war. (The original properties files may be found in rtvapm/rtview/servlets/...) Note that if you put a properties file in the current directory you may still override its host or port values when you run the script. The scripts take the following arguments: -appname: -host: -port: -ha_port: -verbose -help For example: make_rtvdata_war -appname:test -host:testhost -port:9999 Only the -appname argument is required. If no other arguments are supplied, the values in the original properties file will be used. (The original file from the war, or the file in the current directory if present.) The -verbose argument will cause the script to print out the original and new values it puts in the properties file. For example: make_rtvdata_war -appname:test -host:testhost -port:9999 -verbose These scripts also support positional arguments, in the order of: appname, host, port. For example, with an appname of 'test', a host of 'testhost', and a port of '9999', the user could use the argument this way: make_rtvdisplay_war test testhost 9999

21505: Solaris systems now run all custom_setup.sh scripts without error

The following two files would fail on some Solaris systems rtvapm/wsm/src/rtfiles/custom_setup.sh rtvapm/projects/emsample/servers/miscmon/custom_setup.sh This has been corrected.

21561: Solution Packages now use common .war scripts

The update_wars.bat/sh scripts in the solution pack project directories have been updated to use the new make*war.bat/sh scripts in common/bin.

Solution Package

Docker

21447: Number of container restarts is now shown in Engine Table

The number of recent container (re)Starts is shown in the "Starts" column of the All Containers Table in the All Containers - Table Display (Container Views -> Containers Table). The number represents the number of start status events associated the given container in a "recent period" (1 hour by default). Well behaved containers will show 1 start event when they initially start, and 0 when they have been up (running) for longer than the "recent period". Containers that have restarted multiple times in the "recent period" will show a value of more than 1. Compare the start value with the Uptime, Running and Status columns for more insight. By default the recent period is 1 hour (3600 seconds) controlled by the $docEventCacheTimeRange subs value. The most recent statusEvents for a container are captured in the current table of the DockerContainerEvent cache. The container statusEvents for the most recent period are captured in the history table of the DockerContainerEvent cache. The number of container statusEvents for the history table of the DockerContainerEvent cache is limited by the docMaxNumberOfHistoryRows subs value (default: 50000) The count of container events, summed for the most recent period (history table of the DockerContainerEvent cache) are captured in the current table of the DockerContainerEventCount cache.

21546: Updated cadvisor-rtview.sh to add tagging options

A new argument has been added to the cadvisor-rtview.sh container-creation script. -v | --version <TAG> Sets the tagged version of the cadvisor-rtview image to use. Default value is 'latest'

21592: Docker 1.11 support added

Docker 1.11 is now supported The slcorp/cadvisor-rtview agent for dockermon now supports Docker 1.11

21611: Initial dockermon cache load queries from database are now time bounded

Previously the initial queries to load historical data into the Dockermon data server caches at startup were not time bounded. This is no longer the case.

IBM Websphere Application Server

21367: Server Summary button now works as intended

The Server Summary button on the WSM Single Server display now correctly links to the Server Summary display.

21396: Limited support for WebSphere 8.5 now exists

WSM Solution Package now provides limited support for WebSphere 8.5. For an heterogeneous environment with multiple versions of WebSphere AS, it is recommended that you use a sender/receiver configuration where each sender sends data from WebSphere Server Instance of the same major version. At this time, WebSphere 8.5 is only supported if the dataserver includes the following library from version 7: com.ibm.ws.admin.client_7.0.0.jar. The sample.properties file provided with the Solution Package provides the list of local jars and connection properties required to successfully connect with secured WebSphere 8.5 Application Server.

21422: All Servers Grid display in Websphere now has consistent style

The background of the composite object in the All WebSphere Servers -> All Servers Grid now displays the light style correctly.

MongoDB

21516: Collection Summary drop-down list now populates correctly

The Collection drop-down list on the Collection Summary display now correctly populates when manually changing collections.

21612: Initial mongomon cache load queries from database are now time bounded

Previously the initial queries to load historical data into the mongomon data server caches at startup were not time bounded. This is no longer the case.

Node.js

21613: Initial nodemon cache load queries from database are now time bounded

Previously the initial queries to load historical data into the nodemon data server caches at startup were not time bounded. This is no longer the case.

Oracle Database

21614: Initial oramon cache load queries from database are now time bounded

A bug that generated unbounded data base queries at startup for OraDatabaseAvailability, OraInstanceQueryExecStats, OradatabaseDiskUsage, and OraInstanceSessionStats caches has been fixed. Writing historical data to the ORA_DISK_USAGE table has been disabled.

Oracle Weblogic

21348: Optimized performance of the Cache Map by CI

A bug in the WlsJmsDestination cache configuration that forced updates of the Cache Map by CI every 15 seconds has been fixed.

Solace

20943: XML Parser enhanced to handle bad SEMP requests

A fix to account for bad SEMP requests to "show queue/topic data" has been introduced in the SOLMON XML parser. This invalid XML reply occurs when queue/topic names have odd character encoding (E.g. characters from latin character set).

21542: Drop Down menus enhanced

Drop downs for SOLMON have been improved to increase responsiveness when multiple connections, including Solace VMRs, have been defined.

21547: Partial router data now available with no defined endpoints

A bug that prevented router data from being shown when no end points were configured has been fixed. As a result of this fix, if a physical message router or a Solace VMR is being monitored without any queue or topic being configured, then the Message Router displays will contain partial information showing some metrics independent from end points.

21548: Last Data Time now anchors correctly to Interface Summary

The Last Data Time element on the Interface Summary display now anchors correctly.

21549: Colors of In/Out Msgs/sec trends have been changed

The In Msgs/sec and Out Msgs/sec trends from the VPNs->Single VPN Summary are now represented by different colors so that they are easier to differentiate.

21550: Standardized color scheme for Top VPNs display

The background color of the State text box from the VPN's -> Top VPNs Grid display now matches the rest of the display.

21588: Data quality now reflected in status colour across more displays

The state of the data being displayed for SOLMON has been revisited and improved to account with the quality of current data of the drop downs, Last Data Time background color, and the quality of the data shown in the main display area. These elements are now designed to assist users to understand the degree of confidence one can have with the data being exposed in our displays. The information from the Last Data Time refers to the time in which the main index shown in the display has been updated. When the current selection of indexes is Expired, the background of Last Data Time graphical object will now show as dark red. Otherwise it appears as green. Regarding the main display area, the confidence one can have in the data shown is associated with a boolean value indicating whether the quality (goodness of the data shown) is appropriate. Now, all displays that refer to one single Message Router present a dark red background when the information provided is considered outdated. This new behavior can be observed in: - Message Routers -> Msg Router Summary - Message Routers -> Msg Router VPN Activity - VPNs -> Single VPN Summary - Clients -> Single Client Summary - Bridges -> Single Bridge Summary - Endpoints -> Single Endpoint Summary - Capacity Analysis -> Msg Router Capacity - Capacity Analysis -> Msg Router Capacity Trends

TIBCO ActiveSpaces

21597: ActiveSpaces connections require unique member names within the same metaspace

The documentation and properties files comments have been updated to provide more clarity about connection limitations. To make new connections, memberNames within the same metaSpace must be different. If when editing a properties file, if you create a new connection by copy and paste, you must change the memberName as well as the Discovery and Listen URLs. For example if you copy a connection property such as collector.sl.rtview.tasmonds.conn=__name=Q1-Domain memberName=RTViewEM metaspaceName=Q1-Domain discovery=tcp://... listen=tcp://... ... if you remain in the same metaspace then you must change the member name, e.g. collector.sl.rtview.tasmonds.conn=__name=AS-Q1-Domain-MS memberName=RTViewEM2 metaspaceName=AS-Q1-Domain-MS discovery=tcp://... listen=tcp://...

TIBCO BusinessEvents

21460: Added optional variable to read cluster-level MBean data

When connecting to a BE4 cluster, it is possible that the version of java used by the cluster predates the "java 1.6.0_31 or later" required by tbemon. Older java versions do not support the JMX wildcard queries needed by tbemon data collection, so the cluster name cannot be auto-discovered. To read the cluster-level MBean data, you must explicitly pass the name of the cluster to the input processing chains using an optional variable ($tbe_cluster) as follows: # Inference Engines #collector.sl.rtview.cache.config=<cache_source> $tbe_conn:<engineName> $tbe_cluster:<clusterName> #collector.sl.rtview.jmx.jmxconn=<engineName> <hostname> <port> URL:- - - 'false' # Cache Engines #collector.sl.rtview.cache.config=<cache_source> $tbe_conn:<engineName> $tbe_cluster:<clusterName> #collector.sl.rtview.jmx.jmxconn=<engineName> <hostname> <port> URL:- - - 'false'

TIBCO BusinessWorks

21530: Enhanced BW Server Summary display

The BW Server Summary display has been enhanced with the following features: - Active Engines text boxes on the All Engines table now have drill down capability. - Heatmap now reflects stopped engines as gray, and expired engines as dark red. - Heatmap hover text now displays Status and Expired metrics.

21532: BW Processes Heatmap tooltips optimized

The Process Heatmap display has been optimized so that the metrics displayed in the tooltip are in the same order as the metrics selector list.

21533: Engine Status now reflected in BW Engine Summary display

The Engine Summary display has been enhanced to display a dark red background if the engine is not active.

21534: Engine Status now reflected in BW Process Summary display

The Process Summary display has been enhanced to display a dark red background if the associated engine is not active.

21535: Engine Status now reflected in BW Activity Summary display

The Activity Summary display has been enhanced to display a dark red background if the associated engine is not active.

21536: Improved heatmap aesthetics

Heatmap displays now have their objects aligned properly.

21555: Alert light indicators now correctly report number of alerts

Alert light indicators in the Single BW Server Summary display now correctly report both critical alerts and warning alerts. The color of the alert light indicators will reference the highest severity for the element and the number of alerts is the sum of the warning and critical alerts for the element.

21569: Empty displays with zero or null data no longer invisible

In BW Monitor when monitoring BW6, if for any reason the BW6 Process data is not available, some displays would be invisible, rather than visible but showing zero or null data. The displays were the Table and Heatmap views of BW6 Applications, AppNodes, AppSlices and Activities. The Summary views were not affected. This has been corrected so that the displays will show what data is available. Note that Application, AppSlice, and Activity heatmaps will not display visible cells, because (as noted in the titles) the cell sizes are controlled by process metrics.

TIBCO EMS

21567: Multiple bugs fixed with Caches

A bug that forced the initial SQL queries from EmsServerInfoExt, EmsQueuesExt, and EmsTopicsExt caches to query all available historical data has been fixed. Also, a bug that prevented correct collection of the data from EmsQueuesExt and EmsTopicsExt caches in a sender/receiver configuration has been fixed.

Version 3.3.1 Release Notes

Solution Package

TIBCO BusinessWorks

21556: Collection of BW6 appnode memory metrics

BW6 Monitor was not collecting all the data for appnodes; specifically memory and cpu metrics were missing. This has been corrected.

Version 3.3.0 Release Notes

Alerts

21515: Fixed inaccuracies of Alert Severity Indicators on Single Server Summary

The alert light indicators on the Single EMS Server Summary display have been fixed.

Configuration

21419: New displays with configuration property information

EM has been enhanced with new displays showing the properties configuration and values for all connected RTView processes. The displays are in the ADMIN tab under Property Views. All of the properties displays have the following fields at the top: - Source - Select the Source of the connection to the RTView process for which you want to see property information: - Data Server - If the RTView process is a Data Server and the thin client has a defined Data Server connection for it, choose this option and select the name of the Data Server in the Connection field. - Local JMX Connection - Select this option if the thin client has a defined JMX Connection to the RTView process. - RTVMGR JMX Connection - Select this option if the RTVMGR has a defined JMX Connection to the RTView process. - Connection - Select the connection to the RTView process for which you want to see property information. - RTVMGR - This is only visible when Source=RTVMGR JMX Connection and you have multiple RTVMGR's. Select the RTVMGR that has a defined JMX Connection to the RTView process for which you want to see property information. - Update Props - Click this button to have the RTView process specified by the selected Connection re-read all properties files and database properties. Note that most non-connection properties do NOT support updates. Use the Properties Descriptions display to see if a specific property supports updates. Property Views Displays: Properties Configuration - This display shows the properties configuration information. The Last Property Read Time lists the last time that properties were read for the RTView process specified by the selected Connection. The Property Files table shows all of the properties files that were read by the RTView process specified by the selected Connection in the order they were read. The Property Filters table shows all filters that were applied to the properties. Property Groups shows all property groups that were applied to the properties. Property Groups are only used when reading properties from a database. System Properties - This display shows the System properties for the RTView process specified by the selected Connection. Applied Properties - This display shows all of the properties that were applied to the RTView process specified by the selected Connection. There are several reasons a property specified in a properties file might not be applied to an RTView process: the filter doesn't match, it was overridden in another property file, it was specified in a file that is not used by the RTView process, it was a property that is not supported in that RTView process (ex, a builder specific property would not be applied to a data server process). You can filter the Applied Properties table using the Filter Column and Field Value fields. The Clear Filter button clears the filter. Double-click on a row in the table to drill down to the All Properties display filtered by the Property Name for that row. The double-click feature is not supported on IPad. IPad users can access the All Properties display from the navigation tree. The Applied Properties table columns: - Apply Time - The last time this property was applied. - Action - ADDED, REMOVED, CHANGED - Success - True if the action was successful. - File Name - The source of this property. It will be database for properties read from a database. - Property Name - The name of the property after the property filter has been applied. - Property Value - The value of the property. - Handler - The RTView Handler that uses this property. All Properties - This display shows all properties that were read from the properties files and database regardless of whether or not the RTView process uses them. There are several reasons a property specified in a properties file might not be applied to an RTView process: the filter doesn't match, it was overridden in another property file, it was specified in a file that is not used by the RTView process, it was a property that is not supported in that RTView process (ex, a builder specific property would not be applied to a data server process). You can filter the All Properties table using the Filter Column and Field Value fields. The Clear Filter button clears the filter. The All Properties table columns: - Order - The order in which this property was read. For properties that support a single value that are specified multiple times, the one with the highest Order value will be applied. - File Name - The source of this property. It will be database for properties read from a database. - Property Name - The name of the property after the property filter has been applied. - Property Value - The value of the property. - Original Property Name - The name of the property before the property filter was applied. This will match the literal property string in your properties file. Properties Descriptions - This display shows one row for each property that is supported for the RTView process specified by the selected Connection with the following columns: - Property - The name of the property - Multi - True if this property supports multiple values. - Updates - True if this property supports updates. - Handler - The name of the RTView Handler that uses this property. - Deprecated - True if this property is deprecated. - Depreciation Info - If the property is deprecated, this lists the currently supported property to use instead.

Data Model

21391: AlertServer cisource processing re-attempted every 5 seconds for a minute

In previous releases, the cisource property processing would fail if the ConfigServer was not available when the AlertServer started. This can happen when the AlertServer is started before the ConfigServer or when they are started at the same time but the ConfigServer is slow to startup. The AlertServer will now re-attempt the cisource processing every 5 seconds for a minute. If the ConfigServer is still unavailable at that point, the cisource property processing will fail and write an error in the log file.

21501: Fixed performance issue due to large list of subs on RtvDisplayServerDisplays cache

A performance issue from misconfigured history on the RtvDisplayServerDisplays cache has been fixed.

Deployment

21434: Linux file permission handling improved

The scripts rtvapm_init.sh and rtvapm_user_init.sh have been improved so they may be run multiple times in a terminal session without making unnecessary changes to the filesystem or the environment. Before converting a file to Unix format or setting its permissions they will now check the file, and they will now check the PATH before adding to it.

General

18310: False positive "ciListForDataServerConcatenated" errors removed from central alert server

In previous releases, the log files for the central alert server contained several of the following erroneous errors at startup: ERROR: function <ciListForDataServerConcatenated>, Invalid column name <column name list> The alert server has been fixed to no longer generate this error except in cases where the error is valid.

21486: New option to use cross-platform fonts

When the Display Server is running from a host operating system other than the operating system of the client browsers, label alignment inconsistencies can occur due to font unavailability. This is especially pronounced for a Linux server and WIndows client scenario. RTView EM now provides a rtvapm/rtview/lib/rtvfonts.jar that can be enabled in the Display Server, so that the client browser will download the fonts used by the server. To enable this option, which is recommended for linux hosts, edit rtvapm/common/conf/rtvapm.properties and uncomment the following two lines: #sl.rtview.cp=%RTV_HOME%/lib/rtvfonts.jar #sl.rtview.global=rtv_fonts.rtv

Navigation

21414: New Environment Filter for Service Tree

The navigation panel for the SERVICE TREE and ALERTS tabs has been enhanced with an Environment filter combo box. Select an Environment from the list to filter the navigation tree. In the SERVICE TREE tab, it also sets the Environment filter on the main panel. Note that changing the Environment filter on the main panel will not set the Environment filter in the navigation panel.

RTView Core Functionality

Customization

18831: Implement a platform-agnostic font solution for display server

A file named rtvfonts.jar is now included with RTView. This jar file is intended to provide consistent text size on displays that are configured on Windows but are deployed in the thin client via the display server running on Linux. On some Linux installations, there can be significant sizing and spacing differences between the Windows and Linux versions of the "generic" font types (serif, sans-serif, monospaced). This jar contains open source fonts which can be used instead, for font indexes 1 - 12. Each of the open source fonts was designed to be equivalent in sizing and spacing to the corresponding Windows font. The rtvfonts.jar should be used in the following situation: 1) RTView displays were created on Windows, but are deployed in the thin client from a display server running on Linux. 2) In the thin client, there are visible problems with text alignment and sizing that are not seen when the same display is open in the builder/viewer on Windows. If this situation occurs, then the display server should be configured as follows: 1) Add rtvfonts.jar to the display server's classpath, for example: > set RTV_USERPATH=$RTV_HOME/lib/rtvfonts.jar 2) Add rtv_fonts.xml as a global file (rtv_fonts.xml is contained in rtvfonts.jar). For example, add this line to the display server's OPTIONS.ini file: global rtv_fonts.xml The open source fonts contained in rtvfonts.jar are: Arimo (sans-serif, equivalent to Arial) Cousine (monospace, equivalent to Courier) Tinos (serif, equivalent to Times New Roman) Each font is provided in regular (plain), bold, italic, and bold italic in .ttf format (for the display server) and .woff format(for the thin client) for a total of 24 font files. The .ttf files for each font were downloaded from https://www.google.com/fonts. Each is licensed by the Apache 2 license. The font files in this jar contain only the Latin character set, to reduce their size. This means that CJK (Asian) characters will appear as boxes in text strings that are rendered by the display server (e.g. a label object with webLabelFlag = false). In text strings rendered by the browser, the expected characters will appear in a fallback font, so the style and size may not match the Latin characters in the font.

Data Historian

21455: New mechanism to 'throttle' historian deletions.

A command line argument has been provided to enable throttling of historian deletions by separating large deletions into smaller groupings. This option will help in scenarios where users see the following errors in the log: SQLException: The transaction log for database <DB Name> is full. ERROR: java.sql.SQLException: The transaction log for database <DB Name> is full. retention doing delete in SQL: [delete from <DB Table Name> where "timestamp" < 'YYYY-MM-DD HH:MM:SS'] failed. To enable multi-chunk retention start the historian with the -retentionChunkSize argument. Example of deleting in 2 day chunks: -retentionChunkSize:2d Example of deleting in 1 week chunks: -retentionChunkSize:1w This argument does not support time segments of multiple units, such as "1h 30m"

Data Sources

21299: Improved hawk error handling

The TIBCO Hawk data source error handling has been enhanced as follows: 1. Improved logging for onErrorExceptionEvent and onWarningExceptionEvent. These events occur when there is a problem with one of the connected TIBCO Hawk Transports. Also, RTView will now try reconnecting to the transport if an onErrorExceptionEvent occurs. 2. Improved logging for subscription error events. Also, RTView will cancel all subscriptions for a MicroAgent if an onTermination event occurs and attempt to recreate them.

21392: New reconnect option added to Hawk DS

The TIBCO Hawk data source has been enhanced to attempt to reconnect when the initial connection to a transport fails. By default, it will attempt to reconnect once a minute for 60 attempts. You can set the max number of reconnect attempts by command line or property. command line: -hawkmaxreconnect:3 property: sl.rtview.hawk.hawkmaxreconnect=3 Every time a reconnect is attempted, you will see this in the console: 016-03-07 13:00:50.282 re-attempt connection to transport <test_ems>: 1 of 60 016-03-07 13:00:52.911 re-attempt connection to transport <test_ems>: succeeded/failed To disable reconnection attempts, set the max reconnect to 0.

21393: New connection table added to Hawk DS

The TIBCO Hawk Data Source has been enhanced with a new method, getConnectionTable, in the RTViewDs microagent. This table shows one row for each defined connection with the following columns: - Name - the connection name - Connected - true if we are connected, false otherwise This table updates with all rows regardless of the Disable Data Caching setting.

21421: Unexpected JMX Mbean objects no longer cause exception

Unexpected JMX object types could cause a NullPointerException. This has been fixed.

21428: Fix bug preventing removal of rows from current_condensed table

A bug in the cache data source has been fixed that prevented rows in current_condensed tables from being removed by the row expiration feature. (The current_condensed table exists on caches that have the row condense feature enabled. It has one row for the most recent condense result computed for each unique index value). The properties that remove rows from the current table are rowExpirationMode, rowsToDeleteTable, and maxNumberOfCurrentRows.

21437: Corrected slow Hawk Agent discovery by Hawk Datasource

A change was introduced in RTView 6.4 that caused the Hawk Agent discovery to slow down in cases where the Hawk Agents were slow in servicing requests for MicroAgent Descriptors. This has been fixed.

Display Server

21435: Mouse wheel scrolling for tables when using Firefox 42 or newer

In prior releases, the thin client did not support scrolling of table objects using the mouse wheel, if webGridFlag = false, in Firefox version 42 or newer. This is fixed.

21436: Fixed crash with -clearsubs:true command line option

A bug has been fixed which caused the display server to throw a StackOverflowError at startup if the command-line option "-clearsubs:true" was specified. This bug was introduced in RTView 6.4. (Note: The default value of the clearsubs option is true, so there is no need to specify -clearsubs:true).

21440: New new style for tab controls

The Display Server has been enhanced to support a new style for tab controls in the thin client only. This style is flat with square edges and no highlight. To use this style, set the styleClass property for the tab object to em-nav-tabs and add this line to your OPTIONS.ini: displayserver.css rtv_tab.css

General

18198: New option to change default fonts or use additional fonts

The Extended Font feature, new in this release, allows users to extend the list of fonts available on RTView displays beyond the 12 standard fonts. Extended fonts can be used in the Builder/Viewer, or in the thin client, or in both deployments. The configuration and use of this feature requires a basic understanding of font technology and terms, described below. Two example configurations are provided in the RTV_HOME/custom/fonts directory BACKGROUND The following terms apply to font usage in RTView. - System fonts: System or platform fonts are provided by the local operating system. A web browser can make use of the system fonts from the local (client) machine. The system fonts vary between different operating systems, and between versions of the same operating system. This presents a challenge to web developers, since a font available to a browser on one system (e.g. Tahoma on Windows) may not be available to a browser running on other systems, although similar fonts (e.g. Helvetica on Mac OS) may be available. The solution is to (a) use only web-safe fonts, (b) use font families or font stacks, or (c) use web (downloaded) fonts. These are described below. - Web-safe fonts: The serif, sans-serif, and monospace fonts are known as "web-safe" or standard fonts because they are available in all browsers on all platforms. They are also available in Java on all platforms. - Font-family: A font-family is a comma separated list of font names, used in the CSS style applied to text elements on a web page. The browser will attempt to use the fonts in the order they are listed until it finds one that is available. This browser also applies this process on a per-character basis if the text element contains a character not defined in the specified font. The last font in the list should be a web-safe font. This technique is also known as a "font stack" or "fallback fonts". For example: font-family: Helvetica, Lucida Sans, Arial, sans-serif - Web fonts: A web page can identify a specific font to be downloaded from a web server, rather than using a stack of system fonts. A specific font downloaded from the web server is known as a "web font". - Font files: A file that defines a font. A common format is TrueType (.ttf). In a java application, additional fonts can be used by providing TrueType font (.ttf) files. On a web page, web fonts can be downloaded as ttf files. Other formats (.woff, .woff2) are also supported for web fonts. Font files are licensed. Many system fonts are licensed by the OS vendor (e.g. Microsoft). A large number of fonts are available under open source licenses (Apache 2.0, SIL). The Web Font example in the custom/fonts directory uses several open source fonts published on http://www.google.com/fonts. FONTS IN RTVIEW By default RTView uses only the web-safe font types: serif, sans-serif, and monospace. For each web-safe font type RTView provides a plain, bold, italic, and bold-italic style, for a total of 12 font choices. Each is assigned an index, as follows: 1: sans-serif, plain 2: monospace, bold 3: monospace, plain 4: serif, plain 5: monospace, italic 6: serif, bold 7: sans-serif, bold 8: sans-serif, italic 9: serif, bold italic 10: serif, italic 11: sans-serif, bold italic 12: monospace, bold italic The font indexes are used when configuring a font property (e.g. labelTextFont) on an object in the RTView display Builder. The Extended Font feature allows users to extend the list of fonts available on RTView displays, beyond the 12 standard fonts. Extended fonts can be used in the builder/viewer, or in the thin client, or in both deployments. For use in Java (builder/viewer, display server) an extended font must be available from a local .ttf or .otf file. In the thin client, either the font-family (stack) or the web font (downloaded) technique can be used. The font stack technique provides better performance and requires no additional font files or licensing since it uses system fonts already available on the local system. However, since different physical fonts are used, a text element that uses a font stack may have a different appearance and size when viewed in a browser on (say) Windows, vs iOS, vs Android. The web font technique provides a consistent appearance and size in all browsers regardless of the local platform, but requires additional time to download the web fonts the first time the page is opened. Fonts that contain non-latin characters (Cyrillic, Arabic, and especially CJK) can be large. Also, web fonts should be properly licensed. For use in a browser as a web font, the font must be downloadable as a .ttf, .woff, .woff2, or .otf file. Internet Explorer will complain if a .ttf file is not embeddable (most Microsoft-provided .ttf files are not embeddable). EXTENDED FONTS CONFIGURATION AND USE The extended fonts are specified in a table created by the user, with one row per font. The table has these columns: - Index (int): the font's index, an integer value between 13 and 255 (see Note 1 below) - Name (string): the name of the font as it should appear in the Builder property sheet and font selection list - Bold (Boolean): if true, a bold style font is created - Italic (Boolean): if true, an italic font style is created - CSS Font Family (string): for use by the RTView thin client (see Note 2) - URL (string): for the thin client, when using web fonts (see Note 3) - TTF Path (string): a local path to the fonts .ttf file, for use by RTView builder/viewer and display server (see Note 4) The required columns are Index, Name, Bold, and Italic. The other columns are optional depending on the deployment(s) of interest, and the type of fonts used. *** The extended font table must be made available to RTView by creating a global function named RtvExtFontTable. *** The RtvExtFontTable function must return a table that contains the required column names and types listed above. Typically, the RtvExtFontTable function would be a global Reference function with its Table argument attached to a static XML or SQL table. - Note 1: The examples in the custom/fonts directory use index values of 100 and above, as a convention. Index values of 1 - 12 can also be specified, but that will override the default RTView font assignments and is not recommended. - Note 2: The CSS Font Family string is used by the thin client to assign the CSS font style to a client-side object that uses the corresponding font. If the thin client should use a system font, then the string should specify the font family or "font stack" to be used, as a comma-separated list of fallback font names, ending with a web-safe font. For example: Trebuchet MS, Helvetica, sans-serif If instead the thin client should download a web font, then the string in the CSS Font Family column can contain a single name, for example: Roboto - Note 3: The URL column can be omitted or left blank if the thin client should use a system font. If the thin client should download a web font then the value in this column should specify the URL for the thin client to use to download the font file. For example: fonts/Roboto-Regular.ttf The above example assumes that the user has created a subdirectory named "fonts" beneath the rtvdisplay servlet's webapp directory, and it contains the indicated ttf file. The URL can also specify an address on a different web server (e.g. http://somewhere.com/fonts/xyz.woff), provided that server supports CORS (cross-domain) requests. Internet Explorer will complain if a .ttf file is not embeddable (most Microsoft-provided .ttf files are not embeddable). CHARACTER SETS The web-safe fonts support all Unicode characters. Other fonts may not. (In particular, open source fonts may not support CJK characters). If a text string contains a character that is not found in the specified font, the effect is as follows: In a browser, if a text element contains a character that is not found in the specified font, the browser will try the fonts listed in the font-family, and finally its default web-safe font, until it finds a font that supports the character. This means the thin client always displays all of the characters in a text string, but when using an extended font non-Latin characters may be displayed using a fallback or system font. In a Java application, if a text string contains a character that is not defined in the specified font, the character may appear as a "tofu" character (a box or a ?) or it may not be drawn. This means that the builder/viewer will display tofu or empty characters for non-Latin characters that are not found in an extended font. This is also the case for the thin client, for text objects that are rendered in the display server and not in the browser. The google Noto Sans CJK fonts are in .OTF format with Postscript Type 1 glyphs (.OTF w/PS Type1) which is not recognized by Java. EXAMPLES Two example configurations are provided in the RTV_HOME/custom/fonts directory. See the README.txt file in that directory for more information. The beginning of the README file contains the same sections that appear above in this note, but see the EXAMPLES section in the README for a description of each example.

21177: Update-able single value properties now update when the property is removed

In previous releases, the following update-able properties did not reset to the default value if they were removed. This has been fixed. sl.rtview.customWindowTitle sl.rtvapm.mx.mxtrace sl.rtvapm.km.kmtrace sl.rtview.sql.sqltime sl.rtview.jmx.jmx_metrics_period sl.rtview.alert.notifiertimetrace sl.rtview.alert.notifierdebug sl.rtview.hawk.hawkdstraceagentstatus

Platform Support

21076: Windows 10 and Edge Browser support

Windows 10 and the Edge Browser are now supported by RTView products.

Viewer - Applet

21366: Applet support dropped

Due to dropped support for applet technology from browsers and Oracle, RTView has discontinued support of deploying using java applets. All applet demo examples have been removed from the product

Solution Package

Host Infrastructure

21343: Components -> Hosts -> General Hosts dataserver dropdown added

In previous releases, the General Hosts display on the COMPONENTS tab did not allow you to select a Data Server when multiple Host Data Servers were available. This has been fixed.

21432: rtvHostAgent moved to hostmon\agents directory

The rtvHostAgent.zip file was moved from rtvapm\hostmon\lib to rtvapm\hostmon\agents, and the extracted rtvHostAgent directory was moved from hostmon\projects\sample to hostmon\agents. The hostmon\README.txt now contains information about dataserver configuration and running the demo, whereas the hostmon\agents\rtvHostAgent\README.txt is targeted towards the requirements for installing, configuring, and running the agent.

IBM Websphere Application Server

19694: WSM App Metric caches now use "cell" as index column

The caches of the WSM Solution Package have been updated to take into account "cell" as an index.

21381: Deprecated requests for javaVersion and javaVendor removed

A request for the deprecated attributes javaVersion and javaVersion in Application data has been fixed.

MongoDB

21444: Show replication lag for each secondary

The replication lag is now shown for SECONDARY members of replication sets.

Oracle Weblogic

21329: Fixes for WlsJmsDest* alerts

Previously the WlsJmsDestinations* alerts would not always fire correct. This has been fixed.

Solace

21357: SolMsgRouterSyslogAlert fixed under EM

A bug that prevented correct behaviour of the SolMsgRouterSyslogAlert discrete alert under RTView EM has been fixed. This alert will be executed when the Syslog event messages have a level of WARN or higher. The events with WARN level will trigger a warning alert and the events with ERROR or higher level will trigger an alarm alert. When enabled, no threshold modifications for this alert are required. This problem did not effect the standalone RTView Monitor for Solace.

21359: Drop-down lists in the Syslog Events table display do not populate under EM

Previously, when running within a full EM project, the dropdown list selectors on the Syslog Events display were blank. This has been fixed. This problem did not effect the standalone RTView Monitor for Solace.

21500: Improved navigational displays

The supplemental navigation displays that provide an optional alternative to the navtree have been enhanced to contain all available displays, and a navigation display has been added for Syslog.

TIBCO ActiveSpaces

20925: MemberName column has replaced the Member column as an index

The MemberName column has replaced the Member column as an index for the TasMembers, TasMemberStatistics, and TasSeeders caches. This change was made because the ID string identifying the ActiveSpaces cluster member can change when the member is restarted. The new ID disconnected the history for the member, and the Member Summary trend chart would no longer display any history for the member prior to the restart. The MemberName can be statically assigned by the user, or defaulted to a shorter version of the ID which appears to persist across restarts. In either case, the full history is now available on the Member Summary trends. This change requires that the following database tables for TASMON be deleted and recreated: TAS_MEMBER TAS_SPACESTATISTICS TAS_SEEDERS

21087: Navigation corrections in Members displays

Some navigation corrections have been made in the Members section of the Tasmon navtree. All Members By Space Heatmap is added to the tree, and an incorrect "heatmap" button has been removed from the all Spaces By Members Table.

TIBCO BusinessEvents

21453: TbeClusterMalformed in now triggered in the case of a brain-split

The TBEMON alert TbeClusterMalformed will now be triggered for any cluster where the member count is not equal to the expected cluster size. The "expected" cluster size is simply a count of the number of nodes that have the same cluster name, as discovered by reading the cluster mbean for each node in the connection property file. The MemberCount attribute is also read from the same cluster mbean, and is the number of nodes in the (sub)cluster which the current node has joined. The condition where these counts differ can occur if there are missing connections in the property file (ie, some nodes are unmonitored). It can also occur if, due to network anomalies, some nodes do not join the "main" cluster, but instead form a "sub-cluster" of one or more nodes. This condition is commonly referred to as "split-brain".

21454: Fixed blank CI column in the Alerts Table for TbeClusterMalformed

Previously the TbeClusterMalformed alert did not correctly display the name of the cluster it triggered for in the CI column of the alert table. This has been fixed.

21462: Clusters with only one type of node now show up in the All Clusters table

If a cluster contained only inference nodes or only cache nodes, the top level All Clusters table would not display the cluster. This has been fixed.

TIBCO BusinessWorks

19233: Engine status now indicated in Engine heatmap drop down list

BW Monitor displays have been enhanced such that the engine selector dropdown list will show if an engine is not running by appending "(X)" to the entry in the list.

20674: Add jmxconn settings for rtview servers pages

The jmx connections specified for connecting to RTView Server JVMs have been moved from rtvapm.bwmon.properties into a new file bwmon_jvm.properties, which is now called from the standalone rtvservers.dat. This will prevent an EM collector from incorrectly trying to connect to these servers.

21263: Total Engine Statistics now displayed on Engine Level

The BW All Engines Table and Heatmap have been enhanced with the addition of columns giving the total count of created, completed, and aborted processes for each engine. These columns are displayed in the table and in the mouse tooltip in the heatmap

21290: New Alerts and key metrics for correlating process activity vs. resources

BW Monitor has been enhanced with new alerts and new Key Metrics. The following new alerts have been added: Name Metric ---- ------ BwProcessAvgExecutionTimeHigh AverageExecution BwProcessAvgElapsedTimeHigh AverageElapsed BwProcessCreatedRateLow RateCreated BwProcessCreatedRateHigh RateCreated BwProcessTotalCpuPercentHigh TotalCpuPercent For EM users, the following new Key Metrics have been added to the BW-PROCESS CI Type: Name Alert ---- ----- Process Avg Elapsed Time BwProcessAvgElapsedTimeHigh Processes Created / sec BwProcessCreatedRateHigh Process Total CPU Percent BwProcessTotalCpuPercentHigh

21382: History for Tomcat metrics now disabled by default

Tomcat history has been turned off by default. To enable Tomcat history, add the following properties to your sample.properties file: collector.sl.rtview.sub=$TOMCAT_GLOBALREQUESTSTATS_TABLE:TOMCAT_GLOBALREQUESTSTATS collector.sl.rtview.sub=$TOMCAT_WEBMODULESTATS_TABLE:TOMCAT_WEBMODULESTATS collector.sl.rtview.sub=$TOMCAT_WEBMODULETOTALS_TABLE:TOMCAT_WEBMODULETOTALS

21409: Added AvgElapsedTime, AvgExecTime, and TotalCpuPercent to BwProcesses cache

The BW Process metrics Average Execution and AverageElapsed are now calculated by dividing the delta execution or elapsed time for the interval by the delta completed, or the number of process instances that completed in the interval. Previously they were calculated by dividing the total execution or elapsed time by the total number of process instanced (over all time). Users will need to update the table structure of the BW_PROCESSES historian tableby executing the following alter table SQL sentences in your selected database administrative tool: DB2: ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT; ALTER TABLE "BW_PROCESSES" ADD "AverageElapsed" BIGINT; ALTER TABLE "BW_PROCESSES" ADD "TotalCpuPercent" DOUBLE; SQL Server: ALTER TABLE [BW_PROCESSES] ADD [AverageExecution] BIGINT; ALTER TABLE [BW_PROCESSES] ADD [AverageElapsed] BIGINT; ALTER TABLE [BW_PROCESSES] ADD [TotalCpuPercent] FLOAT; MySQL: ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT; ALTER TABLE "BW_PROCESSES" ADD "AverageElapsed" BIGINT; ALTER TABLE "BW_PROCESSES" ADD "TotalCpuPercent" DOUBLE; Oracle: ALTER TABLE "BW_PROCESSES" ADD ("AverageExecution" NUMBER, "AverageElapsed" NUMBER, "TotalCpuPercent" REAL); SyBase: ALTER TABLE "BW_PROCESSES" ADD "AverageExecution" BIGINT NULL, "AverageElapsed" BIGINT NULL, "TotalCpuPercent" FLOAT NULL;

21410: Enhancements to Activity metrics on Process displays

The trends on the BW Process Summary page have been enhanced as follows: The Process Elapsed/Exec Time per Sec trends have been replaced with Average Elapsed and Execution Time trends. A Total CPU Percent trend has been added. The "All Activities Exec Count and Time" trends have been removed. The BW All Processes table has also been enhanced as follows: A Total CPU Percent column has been added, and the columns have been rearranged to put the Key Metrics among the first columns displayed.

21411: Implement filter-in and filter-out patterns for process cache

The BwProcess cache has been enhanced with the ability to filter the processes by name using regular expressions before they are added to the cache. Two filter expressions may be set by using new properties in sample.properties. Each property specifies a regular expression which will be applied to the process name. If the name matches the pattern the process will be included. To exclude processes, start the filter pattern with "^" (negation). collector.sl.rtview.sub=$bwprocessFilterPattern:'' collector.sl.rtview.sub=$bwprocessFilterPattern2:'' For example, say you have these processes: process01.process process02.process process03.process process04.process process05.process process06.process process07.process If you set the first property as follows: collector.sl.rtview.sub=$bwprocessFilterPattern:'0[3-5]' you will get: process03.process process04.process process05.process If you set the second property as follows: collector.sl.rtview.sub=$bwprocessFilterPattern:'0[^4]' you will get, finally: process03.process process05.process

21433: BWAgentPlugin moved to bwmon\agents directory

The BWAgentPlugin files have been moved from bwmon\lib to bwmon\agents\BWPluginAgent.

TIBCO EMS

19085: Expose bridge associations between related topics and queues

Two new menu options have been added to the contextual menu of the right button of the mouse in the Bridges table from the EMS Bridges, Users, Ports for Server display. The options are "Go to Source" and "Go to Target" that allow navigation between bridged destinations. In the case the end points of the bridge are unavailable destinations (e.g. dynamically created), the corresponding option is disabled. The same behaviour applies when the source destination of the bridge contains wild cards, the option "Go to Source" is disabled as well. Known Limitation: Due to the existence of two drilling down possibilities, the Drill Down option from the contextual menu of the right button of the mouse is enabled but non functional.

21333: New alerts to determine if Consumers have been idle for too long

Two new alerts, EmsQueueConsumerIdleTimeHigh and EmsTopicConsumerIdleTimeHigh, have been implemented. These alerts are attached to the newly added ConsumerIdleTime metric which is included into the EmsQueuesExt and EmsTopicsExt caches. This metric computes the time in seconds since an EMS Queue or Topic hasn't delivered any outgoing message. You should update the table structure of the EMS_QUEUESEXT and EMS_TOPICSEXT caches by executing the alter table SQL sentences provided on 21412.

21379: History for Tomcat metrics now disabled by default

Tomcat history has been turned off by default. To enable Tomcat history, add the following properties to your sample.properties file: collector.sl.rtview.sub=$TOMCAT_GLOBALREQUESTSTATS_TABLE:TOMCAT_GLOBALREQUESTSTATS collector.sl.rtview.sub=$TOMCAT_WEBMODULESTATS_TABLE:TOMCAT_WEBMODULESTATS collector.sl.rtview.sub=$TOMCAT_WEBMODULETOTALS_TABLE:TOMCAT_WEBMODULETOTALS

21389: New alerts Ems[Server|Queue|Topic]InboundDeltaHigh

Three new alerts have been added for the delta of inbound messages for EMS Server, Queues, and Topics (EmsServerInboundDeltaHigh, EmsQueueInboundDeltaHigh, and EmsTopicInboundDeltaHigh respectively), which will be triggered when the number of new inbound messages has reached the threshold.

21395: Added deltas to the trends in Server, Queue, and Topic displays

The metrics associated with the Inbound and Outbound Message Rates for EMS Server, Queue, and Topic in the corresponding Summary displays have been replaced with calculated metrics based in their counts. Additionally, a new check box, labelled "Use Rates", to toggle these trends between rates and deltas has been implemented. By default this element is checked and rates are displayed.

21412: ProviderIdleTime metric added for Queues and Topics

The ProviderIdleTime metric has been added to the EmsQueuesExt and EmsTopicsExt caches. This metric computes the time in seconds since an EMS Queue or Topic hasn't received any incoming message. The existing EmsQueueProviderIdleTimeHigh and the EmsTopicProviderIdleTimeHigh alerts are using these metrics. You should update the table structure of the EMS_QUEUESEXT and EMS_TOPICSEXT caches by executing the following alter table SQL sentences in your selected database administrative tool: DB2: ALTER TABLE "EMS_QUEUESEXT" ADD "ProviderIdleTime" DOUBLE; ALTER TABLE "EMS_QUEUESEXT" ADD "ConsumerIdleTime" DOUBLE; ALTER TABLE "EMS_QUEUESEXT" ADD "MessageLatency" DOUBLE; ALTER TABLE "EMS_TOPICSEXT" ADD "ProviderIdleTime" DOUBLE; ALTER TABLE "EMS_TOPICSEXT" ADD "ConsumerIdleTime" DOUBLE; ALTER TABLE "EMS_TOPICSEXT" ADD "MessageLatency" DOUBLE; SQL Server: ALTER TABLE [EMS_QUEUESEXT] ADD [ProviderIdleTime] FLOAT; ALTER TABLE [EMS_QUEUESEXT] ADD [ConsumerIdleTime] FLOAT; ALTER TABLE [EMS_QUEUESEXT] ADD [MessageLatency] FLOAT; ALTER TABLE [EMS_TOPICSEXT] ADD [ProviderIdleTime] FLOAT; ALTER TABLE [EMS_TOPICSEXT] ADD [ConsumerIdleTime] FLOAT; ALTER TABLE [EMS_TOPICSEXT] ADD [MessageLatency] FLOAT; MySQL: ALTER TABLE "EMS_QUEUESEXT" ADD "ProviderIdleTime" DOUBLE; ALTER TABLE "EMS_QUEUESEXT" ADD "ConsumerIdleTime" DOUBLE; ALTER TABLE "EMS_QUEUESEXT" ADD "MessageLatency" DOUBLE; ALTER TABLE "EMS_TOPICSEXT" ADD "ProviderIdleTime" DOUBLE; ALTER TABLE "EMS_TOPICSEXT" ADD "ConsumerIdleTime" DOUBLE; ALTER TABLE "EMS_TOPICSEXT" ADD "MessageLatency" DOUBLE; Oracle: ALTER TABLE "EMS_QUEUESEXT" ADD ("ProviderIdleTime" REAL, "ConsumerIdleTime" REAL, "MessageLatency" REAL); ALTER TABLE "EMS_TOPICSEXT" ADD ("ProviderIdleTime" REAL, "ConsumerIdleTime" REAL, "MessageLatency" REAL); SyBase: ALTER TABLE "EMS_QUEUESEXT" ADD "ProviderIdleTime" FLOAT NULL, "ConsumerIdleTime" FLOAT NULL, "MessageLatency" FLOAT NULL; ALTER TABLE "EMS_TOPICSEXT" ADD "ProviderIdleTime" FLOAT NULL, "ConsumerIdleTime" FLOAT NULL, "MessageLatency" FLOAT NULL;

21413: MessageLatency metric added to Queues and Topics caches

The MessageLatency metric has been added to the EmsQueuesExt and EmsTopicsExt caches. This metric computes the time in seconds since an EMS Queue or Topic hasn't received any incoming message. The existing EmsQueueMsgLatencyHigh and the EmsTopicMsgLatencyHigh alerts are using these metrics. You should update the table structure of the EMS_QUEUESEXT and EMS_TOPICSEXT caches by executing the alter table SQL sentences provided on 21412.

21451: Connections display enhanced with filtering options

New filtering options have been added to the EMS Connections for Server display. - a "Show Active Only" check box to filter on the active connections - a "Client ID FIlter" text box to filter by Client ID

21468: Improved performance when monitoring large environment

The calculation of the ProviderIdleTime and the ConsumerIdleTime for producers and consumers for destinations has been enhanced to account for large environments. This enhancement will only compute the idle time for those destinations that have been active since the starting of the EMSMON data server. The inactive destinations will have the ProviderIdleTime and the ConsumerIdleTime set to zero.

21480: Fixed incorrect data for durable pending mesages

A missing index that prevented correct storage of pending message count and pending message size in the EmsDurables cache and history has been fixed. To upgrade, you should drop the EMS_DURABLES_TABLE from your RTVHISTORY data base and recreate the table with the appropriate table creation SQL statement for your platform. These statements are available in rtvapm\emsmon\dbconfig directory.

21489: Collecting queues and topics is now turned on by default

Collection of all available EMS Queues and EMS Topics has been enabled by default. To avoid performance issues due to large amounts of destinations, the collection of each type of data has been limited per EMS Server to 2,000 rows. To modify this limit, use the following property, which is provided in sample.properties: collector.sl.rtview.jmsadm.maxMetricsRowCount=2000 Increase this limit with caution as performance issues may arise.

21493: Fixed incorrect In/Out msgs/sec in All EMS Queues/Topics for Server displays

A bug that prevented In/Out Msgs/sec below 1 msgs/sec from trending correctly in the EMS Queues/Topics ->All Queues/Topics Summary displays has been fixed.

21509: Streamlined high/low alert logic for Topics/Queues

The function chain to process EMS Queue/Topics for high and low limits alerts has been enhanced to improve performance.

TIBCO Hawk

21390: New hawk debug caches added to hawkmon

The hawkmon package (included in bwmon and amxmon) has been enhanced with new caches that will assist in debugging problems with Tibco Hawk agents. The new caches are: HawkAgentStatus - This contains one row for each Hawk agent and shows the status of that agent. HawkConnections - This contains one row for each hawkconsole property line and shows the status of that connection.

UX Monitor

21431: UX robot agent moved to uxmon\agents directory

An extracted copy of the UX Robot has been provided at uxmon\agents\UXRobot, and the UXRobot_*.zip file has been moved from uxmon to uxmon\agents.

Version 3.2.0 Release Notes

Configuration

21256: New builder option to show properties definitions under App Options

The Display Builder Application Options dialog has been enhanced as follows to better work with properties in EM: 1. The Save button in the Display Builder saves .ini configuration files which are not compatible with EM. This button is now disabled to prevent accidental saving of .ini configuration files. 2. A Show Properties button has been added which shows a dialog containing all of the non-default property values in the currently selected category. You can copy and paste these properties into your EM properties files.

General

21304: Selecting data server for components pages streamlined

The top level pages in the COMPONENTS tab that show the Select Data Server combo have been enhanced as follows: - The combo box now sets the selected data server without requiring the user to click OK. - The selected data server is validated to the first one of the correct type for the selected component type. Note that, as before, the Select Data Server combo is only visible when running EM with multiple data servers of the same type.

21325: rtv_appmon_panels.xml removed from emsample

The file emsample\servers\central\rtv_appmon_panels.xml has been removed so that the library version is used instead. This should not cause any change in user projects as the library version of rtv_appmon_panels.xml is the same as the emsample version that was removed. Upgrade Notes: Users upgrading projects from versions previous to EM 3.2 should remove the rtv_appmon_panels.xml file from their project directory if they want to use the tab framework that was introduced in EM 3.0.

Monitor

21309: Display Server status icon accuracy improved

A bug that was causing the connection status of the Display Server in the Architecture -> System Overview to sometimes be incorrect has been fixed.

21321: RTVCONFIG icon removed from Systems Overview page

The RTVCONFIG icon from the Architecture->Systems Overview display has been removed.

RTVMGR

21303: RTView Server displays now show active RTVMGR server

The Data Server, Display Server and Historian displays have been enhanced to show the currently selected RTVMGR data server.

21305: Function Stats display no longer uses direct jmx attachments

The Function Stats display, available from the Data Server Summary display, has been enhanced. Previously, it required the thin client to have a JMX connection to the selected server. Now, it uses the JMX connection from RTVMGR. If the RTVMGR does not have a JMX connection for the selected Connection, the Function Stats button is disabled.

RTView Core Functionality

18875: Support added for property groups for database properties

The properties database has been enhanced to support a new column, PROP_GROUP. This column is used as an additional optional index when the database properties are processed. Specify the property group for an application using the -propgroup:xx command line option (where xx corresponds to a value in the PROP_GROUP column of your database). If no -propgroup command line option is used, it will query for rows where PROP_GROUP is an empty string. Properties queried from the database are ordered as follows: 1. Order by PROP_GROUP according to the order of the -propgroup command line options. 2. Within each PROP_GROUP, order by PROP_FILE according to the order of the -properties command line options. 3. Within each PROP_FILE, order by PROP_FILTER according to the order of the -propfilter command line options. Note that rows with blank PROP_FILTER that match the PROP_GROUP and PROP_FILE filters are always included. If your application reads properties from a database and you are using the properties database from a previous release, run the following alter table command on your database table to add the new column: ALTER TABLE PROP_TABLE ADD PROP_GROUP VARCHAR DEFAULT ''

Builder - Editing

21221: Tab Control object no longer crashes the Builder if valueTable cannot be resolved

A bug in the tab control object (obj_c1tabs) has been fixed that caused the Builder to throw a NullPointerException, or to perform an unexpected drilldown, if a tab control's actionCommand was configured to perform a drilldown but the control's valueTable property was attached to a nonexistent data table.

Builder - Property Dialogs

21074: Substitutions listbox in Builder no longer throws ArrayIndexOutOfBoundsException

In prior releases, the Builder would sometimes throw an ArrayIndexOutOfBoundsException while updating the list of substitutions shown in the property sheet. This is fixed.

Data Sources

21273: RTView now attempts to re-subscribe to failed subscriptions

A bug was introduce in version 6.0.2 that caused RTView not to attempt to re-subscribe to failed subscriptions. This has been fixed.

Demos

19855: Demo applets updated to use signed jars

The RTView Core demo applets provided in the demo Apache Tomcat server (servers\apache-tomcat-6.0.18-sl\webapps\ROOT) have been updated to use .jar files signed with SL's certificate. At this time, SL's certificate is valid until May 2018.

Functions

21262: Dataserver no longer turns inactive (zombie process) after an "Unlock Error"

A problem in the function data source has been fixed that could cause an IllegalMonitorStateException to be thrown while updating a function.

General

21301: New stop_hsqldb script

New "stop_hsqldb" scripts for cleanly shutting down an HSQLDB instance are now available. The stop_hsqldb script requires a server.rc file in the directory you run it from that is a counterpart to your server.properties file. Example server.properties: server.port=9099 server.database.0=file:../../DATA/alertdefs server.dbname.0=alertdefs server.database.1=file:../../DATA/rtvhistory server.dbname.1=rtvhistory Example corresponding server.rc: urlid alertdefs url jdbc:hsqldb:hsql://localhost:9099/alertdefs username SA password urlid rtvhistory url jdbc:hsqldb:hsql://localhost:9099/rtvhistory username SA password All demos with HSQLDB instances have been updated to include a server.rc file.

21302: Support for enabling/disabling individual db properties

The properties database has been enhanced to support a new column, PROP_ENABLED. This column is used to enable/disable the use of the property. This allows you to temporarily disable the use of a database property without having to remove it from the database. If your application reads properties from a database and you are using the properties database from a previous release, run the following alter table command on your database table to add the new column: ALTER TABLE PROP_TABLE ADD PROP_ENABLED INTEGER DEFAULT 1

Object Library

20625: Text properties handling in html5 chart improved

The following problems have been fixed in the thin client for trend chart objects with webChartFlag enabled: 1). For obj_trendgraph02, the labelTextColor property now sets the color of the axes labels and lines, as expected. Previously in the thin client the axes lines and labels were always black. 2) For obj_trendgraph02, the labelTextFont and labelTextHeight property now set the font used for the chart's title as expected. Previously they were ignored. 3) On mouseover, the text color of legend items no longer changes to black.

21219: bgClipTextFlag property now hidden for unsupported background styles

In the Builder the bgClipTextFlag property is hidden for the indicator objects obj_ind_multi, obj_ind_limits, and obj_ind_discrete if the bgStyle is set to Circle or Diamond, since the flag is only supported for rectangular background styles. In prior releases the bgClipTextFlag property was always visible but did not work in those 2 cases.

Platform Support

20734: Deprecate Windows installers & Bundled Docs

The Windows Installers for RTView Core have been deprecated. Windows users should now use the cross-platform .zip archive. Please see the documentation for more instructions on how to install RTView. Also, the User Guide is now available as a separate downloadable PDF, rather than bundled in the product installation.

Scripts

21278: status_rtv.bat on Windows again shows Uptime, CPU, Heap

On Windows the status_rtv.bat script, while listing running dataservers, was omitting the JMX info (e.g. Uptime 000:00:00:46 CPU 00:00:24 Heap 3.6% ...) This has been fixed.

21328: Enhance stop scripts to stop HSQLDB

The stop_rtv scripts have been enhanced to stop the HSQLDB database if it is running.

Solution Package

Host Infrastructure

20896: Agent now returns actual used memory, excluding buffer/cache memory

The Host Agent has been adjusted to return actual used memory via the Sigar API mem.getActualUsed(), instead of used memory via Sigar API mem.getUsed(). The new approach excludes buffer/cache memory. Users who prefer the old method can continue to use the previous version of the Host Agent.

IBM Websphere Application Server

19895: Users can now open multiple display windows to different sets of indices

The Solution Package for IBM WebSphere has been upgraded to use shared variables instead of global variables, which allows users to drill down to different sets of indices in different displays (using the "+" icon to open displays in a seperate window).

20227: WSM server startup no longer unreliable on Windows

A bug that prevented WSM from loading properties correctly under Windows has been fixed.

IBM Websphere MQ

19896: Users can now open multiple display windows to different sets of indices

The Solution Package for IBM MQ has been upgraded to use shared variables instead of global variables, which allows users to drill down to different sets of indices in different displays (using the "+" icon to open displays in a seperate window).

Oracle Weblogic

19628: New configuration option to address JVM CPU % discrepancy

A new substitution has been added to address the discrepancy in the JVM CPU % metric from Solaris systems and other OSes. For Solaris systems, to match the JVM CPU % metric shown in the Single WebLogic Server -> WLS JVM Summary display with the value obtained with standard tools, add the following property to your properties file: collector.sl.rtview.sub=$wlsJvmCpuPercentMultiplier:N where N is the multiplier needed to match the measurements. For example, if you have a difference in the hundreds, you should add: collector.sl.rtview.sub=$wlsJvmCpuPercentMultiplier:0.01

21288: New KMs for WLS-JMS

New Key Metrics have been added for the WLS-JMS-SERVER and the WLS-JMS-DEST CI Types. The key metric associated to these CI Types is MessagesPendingCount.

Solace

21258: Syslog data acquisition now supported

Syslog data acquisition for solace message routers has been added to SOLMON. To configure the syslog connection properties, copy the following properties into your system properties file in the solmon project directory, uncomment the lines that apply, and make appropriate changes to the connection parameters: ##################################################### # SYSLOG CONNECTIONS # #For messages sent via TCP, use #collector.sl.rtview.syslogds.conn=__name=syslogTCP protocol=TCP host=[hostname] port=601 #collector.sl.rtview.cache.config=sol_syslog_cache_source.rtv $conn:syslogTCP #For messages sent via UDP, use #collector.sl.rtview.syslogds.conn=__name=syslogUDP protocol=UDP host=[hostname] port=514 #collector.sl.rtview.cache.config=sol_syslog_cache_source.rtv $conn:syslogUDP

21259: New SolMsgRouterSyslog alert for syslog event messages

Syslog events with Severity WARN or higher are now incorporated into the RTView Alert Framework through the SolMsgROuterSyslogAlert alert. To trigger syslog event alerts under RTView, go to the Administration->Alert Administration display in SOLMON or EM and enable the SolMsgRouterSyslog alert.

21276: Historical data disabled for all caches except appliance and vpns

Storage of historical metrics has been disabled on all SOLMON caches except for SolAppliances and SolVpns. To enable storage of historical data, edit the sample.properties file and comment out the line associated to the cache you want to store historical data as follows: - For SolApplianceInterfaces cache: #collector.sl.rtview.sub=$SOL_INTERFACE_TABLE:'' - For SolBridgeStats cache: #collector.sl.rtview.sub=$SOL_BRIDGE_STATS_TABLE:'' - For SolClientStats cache: #collector.sl.rtview.sub=$SOL_CLIENT_STATS_TABLE:'' - For SolEndpoints cache: #collector.sl.rtview.sub=$SOL_ENDPOINT_TABLE:'' - For SolEndpointStats cache: #collector.sl.rtview.sub=$SOL_ENDPOINT_STATS_TABLE:'' - For SolApplianceMessageSpool cache: collector.sl.rtview.sub=$SOL_MESSAGE_SPOOL_TABLE:''

TIBCO BusinessEvents

21289: Node Table button added to Cluster Summary page for ease of navigation

To improve navigation, a Node Table button has been added to the Cluster Summary display.

21327: "Up to All Clusters" button now navigates to correct display

Previously the Up button on the Node Table display did not correctly go to the All Clusters display. This has been fixed.

TIBCO BusinessWorks

20858: BW Engine name with spaces now shows in alert message

The my_alert_actions.sh script (rtvapm/common/bin) failed to process the AlertIndex field correctly if the value contained a space, and would pass "N/A" to subsequent commands. For example, a BW alert BWProcessExecutionTimeHigh is executed and the BW Engine name contains a space, "prod.com-Process Archive1". The script sends an email, and in the message the engine name appears as "N/A". This has been corrected.

21260: Source column in sender/receiver configuration corrected

Previously, when BW Monitor dataservers were deployed in sender/receiver mode, the dashboards did not show the correct Source column values. They should reflect the name of the sender dataserver as configured by sender.sl.rtview.sub=$rtvAgentName:MyMachineName but instead the column showed "localhost". This has been corrected.

TIBCO EMS

20818: Support EMSMON topology map in EM

A bug that prevented correct visualization of the All EMS Servers Topology display has been fixed.

21181: All jmsadm calls removed from displays

The performance of the RTView EMS Monitor has been improved by redirecting all JMS Admin calls through their corresponding caches.

TIBCO Hawk

21320: BwEngineCpuUsedHigh alerts now propagated to service level views

A bug that prevented BwEngineMemUsedHigh alert from being propagated to Service level displays has been fixed.

Version 3.1.0 Release Notes

Configuration

20993: Only solution pack data servers that require TIBCO data sources include TIBCO data sources

Only solution pack data servers that require TIBCO data sources include TIBCO data sources by explicitly including the -includetibco command line option. This overrides the -notibco command line option which is now added by default. Previously this was not the case.

Data Model

20888: Filter field added to CMDB Admin page

A text field has been added to the CMDB Admin page to filter the list of available CIs. The filter string can be set up as plain text or a Regex.

General

21194: Moved per-sp jar, nav and citype def properties out of central.properties to new package ref properties

EM has been enhanced to simplify the content required in emsmaple\servers\central.properties for each solution package. Several per-solution package properties have been moved out of central.properties into new properties files that are read from the solution package directories. In order to reference those solution packages, a new entry is needed in emsample\servers\rtview.properties. For each solution package, the following properties are no longer needed in central.properties: sl.rtview.cmd_line=-rtvapm_packages:pck sl.rtview.cp=%RTVAPM_HOME%/emsmon/lib/rtvapm_pck.jar # CI Type Defs ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0 rtvconfig.pck.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:pck # Navigation uiprocess.sl.rtview.xml.xmlsource=pck_navtree.xml 0 pck_navtree.xml 0 1 uiprocess.sl.rtview.xml.xmlsource=pck.navinfo.xml 0 pck.navinfo.xml 0 1 uiprocess.sl.rtview.cache.config=rtv_tabtree_cache_source_comp.rtv $package:pck For each solution package, the following property is needed in rtview.properties: rtvapm_reference=pck For example, these lines for emsmon have been removed from central.properties: sl.rtview.cmd_line=-rtvapm_packages:emsmon sl.rtview.cp=%RTVAPM_HOME%/emsmon/lib/rtvapm_emsmon.jar # CI Type Defs ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0 rtvconfig.emsmon.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:emsmon # Navigation uiprocess.sl.rtview.xml.xmlsource=emsmon_navtree.xml 0 emsmon_navtree.xml 0 1 uiprocess.sl.rtview.xml.xmlsource=emsmon.navinfo.xml 0 emsmon.navinfo.xml 0 1 uiprocess.sl.rtview.cache.config=rtv_tabtree_cache_source_comp.rtv $package:emsmon And the following property is needed in rtview.properties: rtvapm_reference=emsmon The properties removed from central.properties can now be found in RTVAPM_HOME\pck\conf\rtvapm.pck.ref.properties. UPGRADE NOTES: If you have created an EM project against a previous release: No changes are required to projects created in previous versions. However, we encourage you to modify your central.properties files to remove all of the properties listed above for all solution packages and to add an rtvapm_reference property to rtview.properties for each solution package you are using. This will make it easier for you to merge changes to central.properties in future releases. If you have created a custom solution package: No changes are required. However, we encourage you to use the new properties file shceme to make it easier to merge changes to central.properties in fugure releases. Add a new file to the conf directory in your custom solution package named rtvapm.pck.ref.properties (where pck is the name of your solution package). For example rtvapm.emsmon.ref.properties. Add the following lines to your new properties file (filling in your package name for pck). Once you have done this, upgrade your project as listed above. sl.rtview.cmd_line=-rtvapm_packages:pck sl.rtview.cp=%RTVAPM_HOME%/emsmon/lib/rtvapm_pck.jar # CI Type Defs ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0 rtvconfig.pck.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:pck # Navigation uiprocess.sl.rtview.xml.xmlsource=pck_navtree.xml 0 pck_navtree.xml 0 1 uiprocess.sl.rtview.xml.xmlsource=pck.navinfo.xml 0 pck.navinfo.xml 0 1 uiprocess.sl.rtview.cache.config=rtv_tabtree_cache_source_comp.rtv $package:pck If you are not using the standard EM run scripts: No changes are required if you did not upgrade your project as listed above. However, we encourage you to upgrade your project to make it easier to merge changes to central.properties in the future. Look at the changes in common\bin\rtvapm_common.bat/sh and apply the same changes to your custom scripts. These scripts have been enhanced to look for rtvapm_reference in rtview.properties and for all found, to add the RTVAPM_HOME\pck\conf\rtvapm.pck.ref.properties properties file to the command line.

21195: Simplified per-sp ci source lines in central.properties

EM has been enhanced to simplify the content required in emsample\servers\central.properties for each solution package. The per-solution package rtv_alerts_source.rtv, rtv_cistats_source.rtv and rtv_cimap_source.rtv properties in central.properties have a new cisource property. For example, these lines for the EMSMON solution packge in central.properties AlertAggregator.sl.rtview.cache.config=rtv_alerts_source.rtv $rtvDataServer:EMSMON-LOCAL AlertAggregator.sl.rtview.cache.config=rtv_cistats_source.rtv $rtvDataServer:EMSMON-LOCAL AlertAggregator.sl.rtview.cache.config=rtv_cimap_source.rtv $ciType:EMS-SERVER $rtvDataServer:EMSMON-LOCAL AlertAggregator.sl.rtview.cache.config=rtv_cimap_source.rtv $ciType:EMS-QUEUE $rtvDataServer:EMSMON-LOCAL AlertAggregator.sl.rtview.cache.config=rtv_cimap_source.rtv $ciType:EMS-TOPIC $rtvDataServer:EMSMON-LOCAL Have been replaced with this single property: AlertAggregator.sl.rtvapm.cisource=dataserver=EMSMON-LOCAL packages=emsmon You can only have one cisource property per data server. The cisource property supports 3 parameters: dataserver - The name of the data server connection. packages - A comma separated list of packages that are hosted on the data server. All CI Types will be mapped for each package specified. This parameter is ignored if the types parameter is specified. types - A comma separated list of CI Types that are hosted on the data server. This should be used when you do not want to map all CI Types for the packages that are hosted on the data server. This property supports updates. However, removing or editing a cisource property will not remove mapping that have previously been added to the RTView CI Stats tables. UPGRADE NOTES No changes are required to projects created in previous versions. However, we encourage you to modify your central.properties files to replace the rtv_alerts_source.rtv, rtv_cistats_source.rtv and rtv_cimap_source.rtv with the new cisource property for each solution package you are referencing . This will make it easier for you to merge changes to central.properties in future releases.

Key Metrics

20982: New CalcMode for percent values associated with low alerts

The Key Metrics feature has been enhanced to include a new CalcMode: invpct. This CalcMode is used for KM's that are percent values associated with low alerts.

Monitor

21134: The date picker no longer generates incomplete date format.

In previous releases, the date chooser dialog in the trend graph views did not set the end time correctly for servers that were not in the same time zone as the client. This has been fixed.

Navigation

21129: Custom Views now filtered from Component tab

In the previous release of EM, the Custom Views nodes were not filtered out of the Components tree. This has been fixed.

21130: Duplicate Hosts views under TIBCO ActiveMatrix removed

In the previous release, the Components tab navigation tree incorrectly contained Host Views under TIBCO Active Matrix. This was a duplicate of the items in the General Hosts section of the navigation tree. This has been fixed by removing the Host Views from the TIBCO Active Matrix section of the navigation tree.

RTVMGR

20814: Display Servers display works again

The background state of the Display Server in the Administration -> System Overview in the Admin tab has been fixed. The list of Active Displays in the RTView Display Server display in the RTView Servers section has been also fixed. To designate the Display Server that the System Overview display gives the status of, edit central.properties and modify the following substitutions with the appropriate values for your system: 1. Display Server Connection Name (by default DISPLAYSERVER): monitor.sl.rtview.sub=$rtvEmDisplayServerJmxConn:DISPLAYSERVER 2. Display Server Source (by default localhost): monitor.sl.rtview.sub=$rtvEmDisplayServerJmxSource:localhost 3. RTVMGR Data Server Name (by default RTVMGR-LOCAL): monitor.sl.rtview.sub=$rtvEmDisplayServerRtvmgr:RTVMGR-LOCAL

RTView Core Functionality

21152: Additional destination (topics/queues) metrics included from EMS Server

The following columns have been added to the EMS Topics cache: prefetch expiryOverride store The following columns have been added to the EMS queues cache: prefetch expiryOverride store deliveredMessageCount

Alerts

19820: Alert notifications no longer fail if invalid global file is specified in properties

In previous releases, if an invalid global file was specified in your properties file, alert notifications failed to execute. This has been fixed.

Builder - Palette Handling

21046: Graph palette no longer sometimes shows only one object per row

A problem has been fixed in the Builder which sometimes caused the Graphs tab of the Obejct Palette to display just one graph object per row, with extra spacing on all sides, rather than packing as many objects per row as can fit.

Data Sources

20871: New Expiry field added to connection definition

A new field, Expiry, has been added to the definition of IBM MQ connections.

20977: New destination filter for Consumers and Producers metric data attachments

The TIBCO EMS Data Adapter has been enhanced to include pattern filters in the collection of Producer and Consumer data. In the Attach To Data Dialog the Pattern field now becomes visible when the metric is Producers or Consumers (as for Topics and Queues). These patterns will be used via the Admin API to select the destinations for which Producer and Consumer data will be fetched when the data attachment is updated. This will make the operations faster and more efficient, by virtue of being more specific.

21146: Queries no longer made against inactive EMS servers configured with JSON

In version 8.1 of TIBCO EMS a change was made such that inactive EMS servers configured with JSON could no longer be queried via the admin interface. The TIBCO EMS data adapter has been enhanced to detect this condition and avoid making the queries.

Display Server

21178: Copy Cell Value menu item supported in Chrome & Firefox

The thin client now supports the "Copy Cell Value" context menu item on the table object, in Chrome 9version 43 or newer) and Firefox (version 41 or newer). This menu item allows the user to copy a table cell's text contents to the clipboard. Previously this menu item was only available in Internet Explorer.

General

20179: Support custom schedules for SQL queries

BACKGROUND: A new Update Mode named "Run Query On Schedule" is now available in the Attach to SQL Data dialog. When that mode is selected, a dropdown list labelled "Schedule Name" appears, allowing the user to select the name of a schedule. This new mode is intended to give users more control over when specific queries are run. A schedule is defined by one or more rules. A rule specifies the days of the week, hours of the day, and frequency during those hours that a query should be run. A rule can also specify days of the week or specific dates on which a query should not be run. SCHEDULE AND RULE TABLE FORMATS: The query schedules are defined in a table with these columns: # Name : the unique name for the schedule # Rules : the name(s) of the rules (see below) that define the schedule, separated by commas # Enabled : set Enabled = false to disable all queries that use the schedule # Description : a description of the schedule Schedule names should contain only letters, digits, space, underscore and dash. They should not contain newlines, or tabs, or punctuation characters such as colon, semicolon, or comma. The $ character should also not be used in a schedule name to avoid conflicts with substitutions. Each schedule is defined by one or more rules. The rules are defined in a table with these columns: # Name: the unique name for the rule # Days: a list of days of the week (e.g Mon, Wed, Fri) or specific dates (dd-MMM-yyyy) that this rule is in effect. # Start Time: the time of day that this rule goes into effect, in 24 hour HH::mm:ss format. If empty, 00:00:00 is used. # End Time: the time of day that this rule is no longer effect, in 24 hour HH:mm:ss format. If empty, 23:59:59 is used. # Exception: If false, then when this rule is in effect the query is run at the indicated interval. If true, then when this rule is in effect the query is NOT run. # Interval: the time interval between queries when this rule is in effect (e.g. 1m, 30m, 1h, etc). # Enabled : if false the rule is never in effect. # Time Zone: the name of the time zone for the rule (e.g. US/Central). A blank string indicates the local time zone. Rule names should follow the same restrictions as schedule names, described earlier. All of the column types in the rule and schedule tables are strings, except for the Enabled and Exception columns, which are boolean. EXAMPLES: Here is a Rule Table with a few Rule examples: Name Exception Days Start Time End Time Interval Time Zone Enabled Description workdays_30m false Mon,Tue,Wed,Thu,Fri 09:00:00 17:00:00 30m true weekdays 9 - 5 every 30 min weekends_9_12_15 false Sat,Sun 09:00:00 17:00:00 3h true weekends at 9am, noon, 3pm lunch_hour_ex true Mon,Tue,Wed,Thu,Fri 12:00:00 12:59:59 true no queries during lunch holidays_2016_ex true 1-Jan-2016,4-Jul-2016,25-Dec-2016 true no queries during holidays workdays30m_central false Mon,Tue,Wed,Thu,Fri 09:00:00 17:00:00 30m US/Central true weekdays 9 - 5 every 30 min in US/Central timezone The "workdays_30m" rule will run a query every 30 minutes between 9 am and 5 pm, Mon - Fri. The "weekends_9_12_15" rule will run a query on weekends at 9am, noon, and 3pm. The "lunch_hour_ex" rule is an exception rule and prevents a query from being run between 12:00 and 12:59 on weekdays. The "holidays_2016_ex" rule is an exception rule and prevents a query from being run on 3 specific dates in 2016. (Note that this rule does not specify a Start Time or End Time, so it is in effect for the entire day). The "workdays30m_central" rule is the same as the "workdays_30m" rule, except that it uses the US/Central timezone when checking the time of day against the Start/End Time. Here is a Schedule Table using some of the above rules: Name Rules Enabled Description Weekday30 9to5 workdays_30m, lunch_hour_ex, holidays_ex true weekdays @30 minutes from 9 - 5, except lunchtime & holidays AllWeek workdays_30m, weekends_9_12_15 true weekdays @30 minutes from 9 - 5, weekends @ 9 & noon & 3pm test_timezone workdays30m_central true weekdays 9 - 5, in central timezone CREATING SCHEDULES AND RULES: RTView does not provide any predefined rules or schedules nor does it provide a UI for creating rules and schedules. Instead, the user can create a rule table and schedule table in a database, an XML file, or any other table that can be retrieved using an RTView data source. The tables must contain the columns specified above. The user must make the schedule table available to RTView by creating a global function named RtvScheduleTable, using Function Type = Reference, and attaching the function's Table argument to the XML file, or SQL query, or other rtview data attachment that retrieves the schedule table. The attachment can specify a remote Data Server if necessary. Similarly, the user makes the schedule available to RTView by creating a global function named RtvScheduleRuleTable, using Function Type = Reference, and attaching the function's Table argument to the rtview data attachment that retrieves the rule table. If schedules and rules are added or modified at runtime, then the next update of the data attachment used as the input to the RtvScheduleTable and RtvScheduleRuleTable will apply those changes to all SQL queries using those schedules and rules. SCHEDULE SELECTION: Typically, when configuring a scheduled query in the Attach to SQL Data dialog, the user selects the name of a schedule from the Schedule Name dropdown list. But there are two other possibilities: (1) The user can enter a substitution string, e.g. $mySchedule or (2) the user can enter a list of rule names separated by commas, e.g. rule1,rule2,rule3. The 2nd option creates an "anonymous schedule" and is useful in the case where no schedule is defined with the desired set of rules. DIAGNOSTICS: Two columns named Schedule and Next Query Time have been added to the RTViewDS.Keys meta-table of the SQL data source. For each SQL query in the table, the Schedule column shows the name of the Schedule, if any, configured for the query. The Next Query Time shows the next time the query will be run according to its schedule or, if the query doesn't have a schedule, the next time it will be run according to its configured query interval. For Static and On Demand queries, the Next Query Time will show 1/1/1970 GMT. If the -sqltime option is specified, the console log will contain an additional message for scheduled queries, indicating the next time the query will be run: query for <schedule name>,<rule name> next due at <time>: <query string or query ID> For example: query for Weekday30 9to5,workdays_30m next due at 2015-Oct-05 16:30:00: select * from "plants" The SQL data source checks for scheduled queries that should be run on each update cycle. The default update cycle is 2 seconds. This means that a query will typically be run within a second or two of its scheduled time. For example, if the Next Query Time for a query is 16:30:00 the query may actually run between 16:30:00 and 16:30:02. OPTIONS: The accepted formats for days of the week, specific dates, and time zones in the Rule table will be printed to the console if the option -scheduler.dumpFormats:true is specified on the command line. For time zone, names that don't specify daylight savings, such as "US/Eastern", should be used. To add additional formats for specifying dates in rules, use the property sl.rtview.scheduler.dateFormat, for example: sl.rtview.scheduler.dateFormat=MMM dd, yyyy

Security

21179: Check column names in servlet URL for code injection attacks

The rtvquery servlet will now encode any < or > characters that appear in the "cols" parameter as < and > in the response, to avoid possible XSS hacks.

Scripts

19498: Fixed error in script update_wars_package.sh

The shell script rtvapm/common/bin/update_wars_package.sh used the Linux rename utility which does not exist on some versions of UNIX. This has been corrected.

20961: start_rtv.sh, status_rtv.sh and stop_rtv.sh corrected for Mac

On Macintosh systems the start_rtv.sh script would give the error "command not found" when trying to start a server. this has been fixed.

21051: RTView Processes now named in greater detail

When an Rtview process is launched it is given a Java argument of the form -DPROCESS_NAME=xxx. Previously the value "xxx" was a generic tag such as "dataserver". Now this will specifically identify the process by constructing a tag from the line in rtvservers.dat used to launch the process. The tag will be of the form {config name}_{server name}_{server JMX port}. For example, the server "AlertServer" in the config "central" will be given the tag central_AlertServer_10023. This can be seen on Unix with ps: > ps -ef | grep java m 19558 1 0 06:29 pts/2 00:00:00 java -DPROCESS_NAME=central_AlertServer_10023 -DRTV_HOME=/u/rtvdemos/rtvapm/rtview -DRTV_DEMOSERVER=/u/rtvdemos/rtvapm/rtview/servers/apache-tomcat-6.0.18-sl -Xmx256m -Xms128m -Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager . . . Or with jps (if available): > jps -vV 19558 RTViewDataServer -DPROCESS_NAME=central_AlertServer_10023 -DRTV_HOME=/u/rtvdemos/rtvapm/rtview -DRTV_DEMOSERVER=/u/rtvdemos/rtvapm/rtview/servers/apache-tomcat-6.0.18-sl -Xmx256m -Xms128m -Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager

Solution Package

Oracle Coherence

21202: Data Server Selection screen now drills down to to the Cluster Overview screen

The Oracle Coherence - Data Server Selection screen (the top level Middleware -> Oracle Coherence screen in the Components tab) now drills down to the Cluster - Overview screen (Middleware -> Oracle Coherence -> Cluster Views -> Overview) for the selected data server. For a multi-cluster data server, the first cluster in the cluster selector drop down will be selected.

Solace

20999: Optional display removed from navigation tree

The Endpoints – Single Endpoint Summary Rates display was inadvertently added to the navtree. It is an optional display and should not appear by default.

21139: "Appliance" changed to "Message Router" throughout package

The term Appliance to refer to a solace device has been replaced by Message Router in the navigation tree and the displays. Also Appliance has been changed to MsgRouter in alert names and index types, e.g. alertName="SolApplianceFailoverDetected" description="The backup appliance in a HA pair has assumed control." indexTypes="PerAppliance:Connection" ... changed to ... alertName="SolMsgRouterFailoverDetected" description="The backup message router in a HA pair has assumed control." indexTypes="PerMsgRouter:Connection"

21184: Allow 7 days of data to show in trend charts

All trends in SOLMON have been reviewed to show 7 days of data.

21206: New Msg Router Capacity Table and Summary displays

All Message Router Capacity This display allows you to view the Message Router Capacity data for all message routers in a table format. You can view client, spool usage, incoming message, outgoing message, incoming bytes, and outgoing bytes data for the message router. Clicking on a row in the table displays the selected message router data in the “Single Message Router Capacity” display. Single Message Router Capacity This display allows you to view the Message Router Capacity data for a specific message router. You can view client, spool usage, incoming message, outgoing message, incoming bytes, and outgoing bytes data for the message router.

21207: New Msg Router Capacity Trend display

This display allows you to view the Message Router Capacity data for a specific message router in a trend graph format. You can view client, spool usage, incoming message, outgoing message, incoming bytes, and outgoing bytes data for the message router.

21208: Enhancements to SolAppliances and SolApplianceMessageSpool caches

The SolAppliances and SolApplianceMessageSpool caches have been enlarged with more metrics and some have been included in history. Two new caches, related to capacity displays, have been added: SolApplianceCapacity and SolVpnCapacity. The new metrics stored in history are the following: SolAppliances cache: - total-clients-connected - total-egress-discards-per-sec - total-ingress-discards-per-sec - current-egress-byte-per-sec - current-egress-per-sec - current-ingress-byte-per-sec - current-ingress-per-sec SolApplianceMessageSpool cache: - cur-spool-usage-in-mb - active-disk-partition-usage - standby-disk-partition-usage - deliverd-unacked-msgs-util-pct - ingress-flow-count - queue-topic-subscriptions-used - message-count-util-pct - spool-files-total-used - transacted-sessions-used - transactd-session-res-util-pct

21209: New alerts related to capacity

New Message Router alerts have been added. These are the following: SolMsgRouterActiveDiskUtilHigh: The utilization of the active disk partition for the message router is excessive SolMsgRouterByteEgressUtilHigh: The egress rate (bytes/sec) utilization (current egress rate divided by max allowed) for the message router is excessive SolMsgRouterByteIngressUtilHigh: The ingress rate (bytes/sec) utilization (current ingress rate divided by max allowed) for the message router is excessive SolMsgRouterConnectionUtilHigh: The connection utilization for the message router (current number of connections divided by max allowed) is excessive SolMsgRouterDelvrdUnAckMsgUtilHigh: The delivered unacked messages as a percentage of all messages delivered for the message router is excessive SolMsgRouterIngressFlowUtilHigh: The ingress flow utilization (current flows divided by max allowed) for the message router is excessive SolMsgRouterMsgCountUtilHigh: The message count utilization for the message router is excessive SolMsgRouterMsgEgressUtilHigh: The message egress rate utilization (current message egress rate divided by max allowed) for the message router is excessive SolMsgRouterMsgIngressUtilHigh: The message ingress rate utilization (current message ingress rate divided by max allowed) for the message router is excessive SolMsgRouterStandbyDiskUtilHigh: The utilization of the standby disk partition for the message router is excessive SolMsgRouterSubscriptionUtilHigh: The subscription utilization (current number of subscriptions divided by max allowed) for the message router is excessive SolMsgRouterTranSessionCntUtilHigh: The transacted session count utilization for the message router is excessive SolMsgRouterTranSessionResUtilHigh: The transacted session resource utilization for the message router is excessive

21210: Change CIType SOLACE-APPLIANCE to SOLACE-MSGROUTER

The CI Type SOLACE-APPLIANCE has been changed to SOLACE-MSGROUTER. Central Servers and SOLMON Data Server need to be restarted for this change to take effect.

21211: New display Single Endpoint Summary Rates

This optional display, which is not visible by default, allows you to view endpoint information, message data, and a trend graph for pending messages, spool messages, incoming message rates, and outgoing message rates for a specific endpoint connected to a message router/VPN combination. Choose a message router, VPN, and an endpoint from the drop-down menus, and use the Time Range to “zoom-in” or “zoom-out” on a specific time frame in the trend graph. The “Single Endpoint Summary” display is provided by default and should be used if you do not want to collect message spool data for specific VPNs. However, if you do want to configure message spool monitoring for specific VPNs, then you should use this display instead, which is not included in the navigation tree by default. To collect message spool data for specific VPNs, disable the Single Endpoint Summary display, and enable the Single Endpoint Summary Rates display in the navigation tree, perform the following steps: 1. Uncomment and copy the following line in your sample.properties file to configure message spool monitoring for each VPN: #collector.sl.rtview.cache.config=sol_cache_source_msg_spool.rtv $solConn:UNIQUE_APPLIANCE_NAME $solVpnName:VPN_NAME 2. To edit the navigation tree, extract solmon.navtree.xml from the rtvapm\solmon\lib\rtvapm_solmon.jar file and save it in the emsample\servers\central directory. 3. In the solmon.navtree.xml file, comment out the following line: <!-- <node label="Single Endpoint Summary" display="sol_endpoint_summary"></node> --> and add/uncomment this line: <node label="Single Endpoint Summary Rates" display="sol_endpoint_summaryWithRates"></node> Once the file is edited and saved in emsample\servers\central directory, it will get picked up automatically during startup. Note: Collecting data for a large number of VPNs might impair the performance of the appliance.

TIBCO BusinessEvents

20628: Connection and Node ID fields in BE summary page adjusted

On the Inference Node Summary and Storage Node summary displays the Connection and Node ID values would sometimes overflow their corresponding text fields. Those fields will now clip the string if it is too long, and display the full string in the mouseover tooltip.

TIBCO EMS

20171: New destination (topics/queues) metrics added

Four new metrics for EMS Queues and EMS Topics have been added to the caches: prefetch, expiryOverride, store, and deliveredMessageCount. These metrics are collected by default.

20934: Better support for TIBCO EMS 8.2 and JSON configuration files

Multiple log messages coming from Fail Tolerant EMS Servers configured with JSON have been fixed. Now, the log files will have a single message informing about the inability to collect data from such servers.

21066: Query rates for EMS Server caches now configurable

A new substitution to configure the update period of EMS Server caches has been added. This substitution is called $emsServerUpdatePeriod and is set by default to 15,000 msec. To modify this default, include the following property in the sample.properties file in your project directory: collector.sl.rtview.sub=$emsServerUpdatePeriod:15000 and change the value to the appropriate update period for your system. Notice the units of this substitution are milliseconds. This same update period is used as well in the following caches:EmsAdmStats, EmsBridges, EmsDurables, EmsRoutes, EmsFTServerTable, EmsListenPorts, EmsServerRouteTable, EmsServerTable, EmsUsers, and EmsDestinations.

21067: Query update rates for queues and topics now configurable

Two new substitutions to configure the update period of EMS Queues and Topics caches have been added. These substitutions are called $emsTopicUpdatePeriod and $emsQueueUpdatePeriod and are set by default to 30,000 msec. To modify these defaults, include the following properties in the sample.properties file in your project directory: collector.sl.rtview.sub=$emsQueueUpdatePeriod:30000 collector.sl.rtview.sub=$emsTopicUpdatePeriod:30000 and change the values to the appropriate update period for your system. Notice the units of these substitutions are milliseconds.

21068: Query rate for Producer, Consumer, and Connections caches now configurable

Three new substitutions to configure the update period of EMS Producers, Consumers, and Connections caches have been added. These substitutions are called $emsProducerUpdatePeriod, $emsConsumerUpdatePeriod, and $emsConnectionUpdatePeriod and are set by default to 60,000 msec. To modify these defaults, include the following properties in the sample.properties file in your project directory: collector.sl.rtview.sub=$emsProducerUpdatePeriod:60000 collector.sl.rtview.sub=$emsConsumerUpdatePeriod:60000 collector.sl.rtview.sub=$emsConnectionUpdatePeriod:60000 and change the values to the appropriate update period for your system. Notice the units of these substitutions are milliseconds.

21228: Disabled alerting for Fault Tolerant EMS servers

Alerting for FT Standby EMS Server has been disabled. Also, EMS Active Servers that go down will automatically clear all alerts except EmsServerNotStarted if their state change to non-active.

21243: Fixed navigation bug in All Topics Table and All Queues Table displays

A bug that prevented the correct counts of EMS Queues/Topics and the proper drilling down from the All EMS Queues/Topics Table has been fixed.

UX Monitor

20743: UX Robot installers merged into one cross-platform archive

The UX Robot installation packages have been reduced to one multi-platform ZIP package named "UXRobot_VERSION.zip" that contains both run_ux_robot.sh and run_ux_robot.bat.

20994: Restored -propfilter:receiver to uxmon entry in rtvservers.dat

In the previus release of RTView EM, the file rtvservers.dat in rtvapm/projects/emsample had an incorrect entry for the uxmon dataserver. This has been corrected.

Version 3.0.0 Release Notes

Alerts

20920: RtvAlertStatsByCI MaxSeverity is sometimes incorrectly initialized as a string instead of an integer

In previous releases, the MaxSeverity column in the RtvAlertStatsByCI cache was sometimes incorrectly initialized as a String instead of an Integer which resulted in an error when storing the cache history to a database. This problem has been fixed.

Drill Down

20899: Health State Display now drills down to correct CI when multiple dataservers

In previous releases, the Service Summary Views->Service Health Heatmap sometimes did not drill down to the correct CI in the case where multiple CI's of the same type in the same services were hosted on different servers. This problem has been fixed.

General

20924: All option now supported in Services combo in service level displays

The Service Summary Views have been enhanced to support the All in the Service combo box. When All is selected, the CI's in all Services in that Group and Environment will be displayed.

20991: New icons in title area of main display

The back, up, data ok, new window, help and alert drilldown icons in the title area of all displays have been updated.

21072: EM enhanced with new navigation framework

The EM user interface has been enhanced with a new look and feel that breaks up the old navigation tree into tabs by category. Users upgrading projects or custom solution packages from previous releases of EM will need to follow the instructions in the Upgrade Notes section of the documentation in order to use the new navigation framework. The new tabs are as follows: SERVICE TREE - This tab shows your service model in the navigation panel with an alert indication showing the highest alert state for that item. Click on an Owner, Area, Group or Service to navigate to views for that item in the main panel. Each level in the tree is associated with multiple displays which you can access via the view combo box at the top left of the display. EM will remember which display you used last for each level and use that display next time you view an item at that level. Type a service into the Service Filter field and click on the magnifying glass icon to filter the tree by that service name. Note that the Service Filter is case sensitive. Enter * to show all services. SERVICE VIEWS - This tab shows the same views as the Service Tree, along with the Components Views and Metric Explorer, using the old navigation scheme. COMPONENTS - This tab shows all Solution Package views organized by Technology and Vendor. Previously, only a few nodes per Solution Package were included in the navigation tree. The Components tab includes the full stand-alone tree for each Solution Package. See the Customizing the Central Servers section of the documentation for information on adding and removing Solution Packages in the Components tab. ALERTS - This tab shows your service model in the navigation panel with an alert indication showing the highest alert state for that item and the Alert Table in the main panel. Click on an Owner, Area, Group or Service to filter the Alert Table. Type a service into the Service Filter field and click on the magnifying glass icon to filter the tree by that service name. Note that the Service Filter is case sensitive. Enter * to show all services. ADMIN - This tab shows Alert and CMDB administration views as well as Architecture views. CUSTOM - This tab is included as a location for user-defined views. Some sample views are included by default. For users with no user defined views, this tab can be removed. See the documentation for instructions on adding your custom views to this tab or removing this tab.

RTView Core Functionality

Configuration

20941: sl.rtview.dataserver and sl.rtview.cache.config properties now dynamic

The properties sl.rtview.dataserver and sl.rtview.cache.config now support updates. This allows named data server connections and cache files to be added or removed via properties at runtime.

Data Server

20910: RTVquery no longer hangs when the target data server re-boots

In previous releases, the rtvquery servlet would occasionally fail to respond to queries after its target data server was restarted. This problem is fixed

20911: REST servlet enhanced for history queries

The URL applied to the rtvquery servlet now supports a parameter named "arr". If the value of the arr parameter is 1 then, if fmt = json or jsonp, the javascript array format will be used for data rows in the response. This is intended for use with fmt=jsonp, to reduce the response size. Also, server-side paging and sorting are now applied properly to queries on cache history tables. In prior releases, the sorting and paging was applied incorrectly which could give confusing results.

Data Sources

19866: Splunk data adapter no longer generates NullPointerException message.

In previous versions under certain circumstances, the Splunk data adapter would generate a NullPointerException message. This is no longer the case.

20867: Improved performance of ConsumerDetails queries

The process of getting detail info on EMS Consumers has been optimized; customers who have previously found it necessary to disable collection of this data may find this is no longer necessary.

20967: ConsumerCount and ProducerCount added to the ServerInfo table

Two columns have been added to the jmsadm ServerInfo table: ProducerCount and ConsumerCount. These are the total counts before any filtering is applied.

20975: Enhanced to work with rvtrace version 8.2.0+.

The TIBCO Rendezvous data source has been enhanced to work with rvtrace version 8.2.0+. In 8.2.0, TIBCO modified the rvtrace output to add the SCid and R columns to the Multicast Packet Statistics source rows and to add the SCid column to the Multicast Subject Staticstics source rows. The TIBCO Rendezvous data source has added the SCid and R columns to the RTViewDs.MulticastPacketsSource table and the SCid column to the RTViewDs.MulticastSubjectsSource table. The rvmonitor demo has been updated to show these new columns. Note that versions of rvtrace older than 8.2.0 are no longer supported in the TIBCO Rendezvous data source.

Display Server

20929: New logout properly in multi-panel layout

In the thin client, clicking the Log Off item in the context menu will navigate back to the login screen, after logging off the user.

Layouts

20966: New option to hide draggable divider on panel in thin client

In an RTView panels file with resizable dividers enabled, a panel can be configured to hide its divider in the thin client by setting nodivider="true". For example, in this panels file the divider that would normally appear below the north panel is hidden: <?xml version="1.0" ?> <panels xmlns="www.sl.com" version="1.0"> <rtvLayout title="My Panels" dividers="true"> <rtvDisplayPanel region="north" display="title.rtv" nodivider="true"/> <rtvAccordionPanel region="west" width="200" height="544" navdata="navtree.xml"/> <rtvDisplayPanel region="center" name="main" display="test1"/> </rtvLayout> </panels> The nodivider attribute is only supported in the thin client, it is ignored by the viewer. It is also ignored on the center panel.

Licensing

20926: Generic PIN no longer returned on Red Hat Linux 7

The license registration process will now correctly obtain a non-generic PIN from Redhat Linux 7 servers.

Object Library

20921: Tree/accordion L&F enhancements

Several properties have been added to the tree (obj_c1tree) and accordion (obj_c1accordion) controls. In all cases, the default value of the new property matches the default behavior of the control in previous releases. bgBorderFlag : This property appears in the Background category in the Builder's property sheet, for the tree and the accordion. If bgBorderFlag is checked then a 1 pixel dark border is drawn around the control, otherwise no border is drawn. By default the flag is checked and the border is visible, as it was in all prior releases. [Note that the border color and width are not configurable, only the visibility]. accordionCollapseFlag : This property appears in the Interaction category in the Builder's property sheet, for the accordion only. If accordionCollapseFlag is checked, only one branch of the accordion is open at a time. If the user clicks a node to open another branch, then the previously open branch is automatically closed. If accordionCollapseFlag is unchecked, opening another branch has no affect on other open branches. By default the flag is checked, to match the behavior in all previous releases. nodeClosedImage/nodeOpenImage : These two properties appear in the Node category in the Builder's property sheet, for the tree only. Use these properties to specify the names of the images to be shown to the left of a closed/open parent (non-leaf) tree node, respectively. By default these properties are blank, indicating that the default closed/open images should be used, as in all previous releases. nodeSelectColor/nodeSelectTextColor : These two properties appear in the Node category in the Builder's property sheet, for the tree only. Use these properties to set the background and text colors for the selected tree node. If set to "Default", then the platform or browser default selection colors are used. In addition, two thin client problems have been fixed: (1) A problem specific to IE9 has been fixed in which a drilldown triggered from an accordion control would sometimes fail and leave the target panel in the "Loading..." state. (2) A problem that caused the navigation panel containing a tree/accordion control or occasionally other panels to have the incorrect initial size has been fixed.

20922: Padding and hovering enhancements for the tab control

Several properties have been added to the tab control(obj_c1tabs). In all cases, the default value of the new property matches the default behavior of the control in previous releases. 1. paddingVertical : Extra padding, in pixels, to add above and below the label of each tab. This can be used to make the tabs taller without increasing the font size. 2. paddingHorizontal : Extra padding, in pixels, to add to the left and right of the label of each tab. This can be used to make the tabs wider, without increasing the font size. The default value is zero. 3. webHoverTabColor: The background color for an unselected tab when the cursor is over it. The default value is the same as the normal tab background color. This property only affects the thin client, it is ignored in the builder/viewer. 4. webHoverTextColor: The text color for an unselected tab when the cursor is over it. The default value is the same as the normal tab text color. This property only affects the thin client, it is ignored in the builder/viewer.

20965: New properties to set selected tab bg and text color

The tab control (obj_c1tabs) supports new properties named selectBgColor and selectTextColor to set the background and text color of the selected tab. The default value for both is Default, meaning that the background color of the selected tab will be a brighter shade of the unselected tabs in the thin client, and a darker shade in the viewer, and the text color of the selected tab is the same as the unselected tabs.

20985: Fixes to objects with webLabelFlag enabled

Two problems involving the webLabelFlag property have been fixed. 1. If a composite object has a command or drilldown defined, and the subdisplay within the composite contains an label object with webLabelFlag = 1, then a click on that label object does not trigger the composite's command or drilldown. 2. Link lines drawn between objects with webLabelFlag = 1 may be mispositioned. Both problems are fixed.

20996: Enable copy to clipboard on multiselect Kendo grid

The text in selected row or rows of the web (kendo) grid can now be copied to the clipboard by pressing Ctrl+c when the grid has keyboard focus. Only text cells are copied. If a cell contains an image, its value is not copied to the clipboard. The grid must have keyboard focus for the Ctrl+c keystroke to have effect.

21006: New property rowSeriesTraceMode added to the bargraph object.

A property named rowSeriesTraceMode has been added to the bargraph object. This allows row-series behavior to be enabled or disabled on the traces independently of the row-series setting for the bars. The default value of rowSeriesTraceMode is "Use rowSeriesFlag". With this value, the row-series behavior is enabled or disabled on the bars and the traces by the rowSeriesFlag property, as in previous releases. To enable row-series behavior on the bars but not the traces, check the rowSeriesFlag property and set traceRowSeriesMode = Off. To enable row-series behavior on the traces but not the bars, uncheck the rowSeriesFlag property and set traceRowSeriesMode = On.

Scripts

20963: Corrected start/stop/status shell script error on Solaris 11

In the latest release of RTView EM the "start_rtv.sh" script failed on Solaris-11with this error: "shift: (null): bad number". This has been corrected.

20995: “stop_rtv.bat all” will now process all the entries in the rtvservers.dat file consistently

The command "stop_rtv all" on Windows (stop_rtv.bat) in the most recent version did not correctly process the rtvservers.dat file. Processing would terminate prematurely if it encountered uncommented configs with servers that were not started. This has been fixed.


Solution Package

Solace

20916: New Solace metrics to support capacity planning

New metrics have been added to the SolAppliances cache to support capacity planning. The following table identifies the changes, listing both the xml name from the SEMP reply, and the shortened name in the cache. New Metrics for SolAppliances cache XML name SolAppliances cache name total-clients-connected-with-compression total-clients-connected-comprsd total-clients-connected-with-ssl total-clients-connected-ssl denied-authorization-failed denied-authorization-failed denied-client-connect-acl denied-client-connect-acl denied-subscribe-topic-acl denied-subscribe-topic-acl current-ingress-rate-per-second current-ingress-per-sec current-egress-rate-per-second current-egress-per-sec average-ingress-rate-per-minute avg-ingress-per-min average-egress-rate-per-minute avg-egress-per-min current-ingress-byte-rate-per-second current-ingress-byte-per-sec current-egress-byte-rate-per-second current-egress-byte-per-sec average-ingress-byte-rate-per-minute avg-ingress-byte-per-min average-egress-byte-rate-per-minute avg-egress-byte-per-min zip-stats.ingress-compressed-bytes ingress-comp-bytes zip-stats.ingress-uncompressed-bytes ingress-uncomp-bytes zip-stats.current-ingress-compressed-rate-per-second current-ingress-comp-per-sec zip-stats.average-ingress-compressed-rate-per-minute avg-ingress-comp-per-min zip-stats.current-ingress-uncompressed-rate-per-second current-ingress-uncomp-per-sec zip-stats.average-ingress-uncompressed-rate-per-minute avg-ingress-uncomp-per-min zip-stats.egress-compressed-bytes egress-comp-bytes zip-stats.egress-uncompressed-bytes egress-uncomp-bytes zip-stats.current-egress-compressed-rate-per-second current-egress-comp-per-sec zip-stats.average-egress-compressed-rate-per-minute avg-egress-comp-per-min zip-stats.current-egress-uncompressed-rate-per-second current-egress-uncomp-per-sec zip-stats.average-egress-uncompressed-rate-per-minute avg-egress-uncomp-per-min ssl-stats.ingress-ssl-bytes ingress-ssl-bytes ssl-stats.current-ingress-ssl-rate-per-second current-ingress-ssl-per-sec ssl-stats.average-ingress-ssl-rate-per-minute avg-ingress-ssl-per-min ssl-stats.egress-ssl-bytes egress-ssl-bytes ssl-stats.current-egress-ssl-rate-per-second current-egress-ssl-per-sec ssl-stats.average-egress-ssl-rate-per-minute avg-egress-ssl-per-min New metrics have been added to the SolApplianceMessageSpool cache to support capacity planning. The following table identifies the changes, listing both the xml name from the SEMP reply, and the shortened name in the cache. New Metrics for SolApplianceMessageSpool cache XML name SolApplianceMessageSpool cache name message-count-utilization-percentage message-count-util-pct spool-files-utilization-percentage spool-files-util-pct transacted-session-count-utilization-percentage transacted-session-cnt-util-pct transacted-session-resource-utilization-percentage transacted-session-res-util-pct delivered-unacked-msgs-utilization-percentage delivered-unacked-msgs-util-pct spool-files.total-used-percent spool-files-total-used-pct spool-files.total-used spool-files-total-used message-spool-entities-used-by-dte message-spool-used-by-dte New metrics have been added to the SollVpns cache to support capacity planning. The following table identifies the changes, listing both the xml name from the SEMP reply, and the shortened name in the cache. New Metrics for SolVpns cache XML name SolVpns cache name max-subscriptions max-subscriptions max-connections max-connections stats.ingress-compressed-bytes ingress-compressed-bytes ingres-compressed-bytes-per-sec (calculated) stats.egress-compressed-bytes egress-compressed-bytes egress-compressed-bytes-per-sec (calculated) stats.average-egress-byte-rate-per-minute avg-egress-byte-per-min stats.average-egress-rate-per-minute avg-egress-per-min stats.average-ingress-byte-rate-per-minute avg-ingress-byte-per-min stats.average-ingress-rate-per-minute avg-ingress-per-min stats.current-egress-byte-rate-per-second current-egress-byte-per-sec stats.current-egress-rate-per-second current-egress-per-sec stats.current-ingress-byte-rate-per-second current-ingress-byte-per-sec stats.current-ingress-rate-per-second current-ingress-per-sec

TIBCO ActiveSpaces

21085: Button positions adjusted for consistency

The back and up button positions have been adjusted so that their position is the same on all of the displays in the Tibco ActiveSpaces monitor. This eliminates the "wiggle" effect seen when flipping thru the screens quickly.

TIBCO BusinessWorks

20764: Checkboxes to control labels added to BW Monitor heatmaps

In the BW Monitor heatmap displays for Engines, Processes, and Activities, the slider which controlled the visibility of the heatmap labels has been replaced with checkboxes, following the standard for EM displays.

TIBCO EMS

19007: EmsQueues|TopicsProducer alerts overrides can now be set

EmsQueuesProducerCountHigh, EmsQueuesProducerCountLow, EmsTopicsProducerCountHigh, and EmsTopicsProducerCountLow have been fixed to set properly overrides.

20104: Fixed errors in emsmon dataserver.log: alertConsumerStalled

An error in the dataserver log file about alertConsumerStalled has been fixed.

20655: High Availability configuration finalized

An ommission that prevented out-of-the-box configuration of High Availability for EMSMON has been fixed.

20730: EmsConsumerStalled description enhanced to include min. uptime server sub

The description of the EmsConsumerStalled alert has been improved to include description of the minimum startup time (default 5 minutes), during which this alert will not be triggered.

20821: EMS Summary consumers and producer count now more accurate

The EMS Single Server Summary display has been modified so that the Producer and Consumer count fields are taken directly from the EMS server data. This has two implications: 1. The values will be non-zero if collection of consumer and producer data is disabled. 2. If collection of consumer and producer data is enabled, the counts shown will differ from the row counts of the corresponding tables, because the tables as displayed are filtered to remove irrelevant rows (system, temporary, etc.)

20970: Corrected discrepancy between queue counts across displays

Queue counts from the EMS Server Summary are now consistent with the value displayed at the EMS Queues->All Queues for Server display. The total and the filtered counts as well as the regex patterns being used are provided also in the associated help button.

20971: Corrected discrepancy between topic counts across displays

Topic counts from the EMS Server Summary are now consistent with the value displayed at the EMS Topics->All Topics for Server display. The total and the filtered counts as well as the regex patterns being used are provided also in the associated help button.

20972: Corrected discrepancy between connection counts across displays

Connection count from the EMS Server Summary is now consistent with the value displayed at the EMS Clients->Connection display. The total and the filtered counts as well as the regex patterns being used are provided also in the associated help button.

Version 2.3.0 Release Notes

Key Metrics

20799: Service level heatmaps sometime show no node borders

In previous releases, if you navigated to one of the Key Metrics Views before viewing any of the heatmap displays under All Management Areas, Multi-Area Service Views or Service Summary views, the heatmap node borders were lost. This has been fixed.

Monitor

20875: New combo box to toggle between the Current and History alert views

The RTView Alerts Table and Alert History Table have been enhanced to support a navigation combo box. This combo box allows you to toggle between the Current and History alert views.

Navigation

20766: Drilldown navigation now defaults to last viewed display in display group

The EM navigation for the following sections in the navigation tree has been enhanced to re-use the last viewed display per section: All Management Areas Multi Area Service Views Single Area Service Views Service Summary Views Key Metrics Views In previous releases, when navigating from within a display to a display in a different section of the navigation tree, the drill down display was hardcoded. Now the displays use the last viewed display as follows: 1. The displays under All Management Areas drill down to the last viewed display in the Multi-Area Service Views. 2. The displays under Multi Area Service Views drill down to the last viewed display in the Service Summary Views or KM Metrics Views. The up button on the Multi Area Service Views drill up to the last viewed display in All Management Areas. 3. The displays under Single Area Service Views drill down to the last viewed display in the Service Summary Views or KM Metrics Views. The up button on the Single Area Service Views drill up to the last viewed display in All Management Areas. Note that the Single Area Service Views are commented out of the emsample navigation tree by default. 4. The displays under Service Summary Views and Key Metrics Views drill up to the last viewed display in Multi-Area Service Views. For example, you drill down on an All Management Areas display which navigates to Multi-Area Service Views->Group / Service Heatmap. In that display, you select By Region from the navigation combo box. The next time you drill down on an All Management Areas display, it will navigate to Multi-Area Service Views->Region/ Service Heatmap since that was the last display viewed in the Multi-Area Service Views section. A few additional changes have also been made: 1. By CI Type and History have been added to the navigation combo box on the Multi-Area Service Views. 2. The navigation combo box on the Component Views has been standardized across all views to contain Tree, CMDB, Heatmap, Table which corresponds to the 4 displays in the Component Views section of the navigation tree. 3. Support for the following substitutions has been removed: $rtvNavServiceHeatmapDisplayName $rtvNavServiceTableDisplayName $rtvNavServiceHeatmapDisplayName $rtvNavServiceTableDisplayName $rtvNavAppDisplayName

RTView Core Functionality

Alerts

18023: Alert ds no longer crashes if if indexTypes syntax is incorrect

In previous releases, the alert data source threw a NullPointerException if there was a syntax error in the indexTypes property. This has been fixed.

Builder

20693: Builder no longer fails on Mac with JDK 1.7 or greater

The RTView Builder no longer fails on Mac with JDK 1.7 or greater.

Commands

17078: Data attachments in multi-commands now work in thin client

In prior releases, data attachments used in commands within a multiple command did not work in a display server deployment. This is fixed.

Data Historian

19992: New Smooth Compaction configuration options

New arguments have been added to customize how compaction smoothing is performed. -smoothingonly Run smoothing only without data being provided -smoothcompaction:table1,table2 Restrict the tables being smoothed to those specified

Data Sources

18403: Fixed cache bug with maxNumberOfCurrentRows and blank timestampColumnName

The cache data source no longer throws a NullPointerException if a cache has maxNumberOfCurrentRows > 0 and a blank timestampColumnName.

20692: Fixed bogus timeout of sql query

A problem has been fixed in the SQL datasource which would sometimes cause a query to fail with a bogus timeout error showing a very large and incorrect timeout value.

20767: xml parser no longer throws exception if token >= 8192 chars

In previous releases, the JMS and XML data sources would throw an ArrayIndexOutOfBoundsException if an XML string token contained 8192 or more characters and none of those characters was a space. This is fixed.

20895: Time range no longer ignored in cache history attachment if multi-column filter value = *

The following bug in the cache data source has been fixed: If an attachment to a cache history table specifies a time range, and also specifies a filter on multiple columns but the filter value for each of those columns is * then the time range is ignored and all rows from the history table are returned.

Display Server

19512: Support audio and threshold command in thin client

The thin client now supports the Play Audio File command and threshold commands. In addition, a new property named valueCommandResetTrigger has been added to the display objects that support threshold commands. ------------------- Play Audio File command: The thin client now supports the Play Audio File command. The support for audio file formats varies by platform, as follows. - The Play Audio File command is not supported in Internet Explorer version 8 and older. - In a desktop browser (Internet Explorer 9 or newer, Firefox, Chrome) .wav and .mp3 files are supported. However, Internet Explorer uses the Windows Media Player to play .wav files, which may require user confirmation or may fail due to security settings. - In mobile browsers (e.g. Safari on iOS) only .mp3 files are supported, and the user must click on the "Enable Audio" button that appears in a display the first time an audio command is executed. - The "Beep" command is still not supported in the thin client. Note that in the builder/viewer, only .wav files are supported by the Play Audio File command. This has always been the case and has not changed in this release. --------------------- Threshold command: There are four objects that support threshold commands: obj_circ2d_ilvx_ra4, obj_rect_ilvx_ra4, obj_circ2d_ilvx_da3, and obj_rect_ilvx_da3. A threshold command can be defined using any of the properties named value*Command on those objects. In this release, if the webChartFlag property is checked on an object with a threshold command, the threshold command will be executed in a thin client deployment when appropriate. In prior releases, threshold commands were ignored in a thin client deployment. If the threshold command is a supported client-side command it will be executed in the browser. The client-side commands are: Play Audio File, Drilldown/Set substitution, Execute Custom Command (if the custom command has a javascript implementation), Open Browser. All other commands are executed by the display server or (for a data source command) in the data server. A new property named valueCommandResetTrigger was added to the objects that support threshold commands. Typically, once a threshold command has been executed by one of those objects because the value exceeds or equals a limit, the command will not execute again until the value exceeds another limit. But now, if the value of valueCommandResetTrigger property is changed, then the object's threshold command will be executed again even if the value property has not changed. Changing the value of valueCommandResetTrigger when the object's value is not at or above a limit has no effect.

19979: Added Sessions table to display server mbean

The Display Server's JMX Manager mbean supports a new tabular attribute named Sessions. The Sessions table contains one row for each active client session. Typically, there will be one client session for each browser instance that is currently viewing a thin client display. The Sessions table contains the following columns. - Session ID: unique ID for client session - Client Address: the IP address of the client. - Duration: elapsed time since this client session was created. - Last Reference Time: elapsed time since this client opened or refreshed a display. - User: the login user name - Role: the login user role Notes on each column: The Session ID is also a column in the mbean's DisplayData table, which contains one row for each display that is currently open in a thin client. The Session ID is a unique string assigned to a session by RTView and is not the same value as the session identifier assigned by the webapp mananger (tomcat). The Client Address will be in IPv4 (e.g. x.x.x.x) or IPv6 (x:x:x:x:x:x:x:x) notation, depending on which protocol the client browser used to connect to the rtvdisplay servlet. For example, if the client is on localhost then the client address could be shown as 127.0.0.1 for IPv4, or 0:0:0:0:0:0:0:1 for IPv6. The Duration column and the Last Reference Time column show elapsed time as "d hh:mm:ss" where d = days, hh = hours, mm = minutes, and ss = seconds. By default, a session expires and is removed from the table after about 10 or 11 minutes of inactivity (that is, when the elapsed time shown in the Last Ref Time column is "0 00:11:00" or more). If the display server's display_timeout property has been set, then the session expiration is 10 times the display_timeout value. (The default display_timeout is 60 seconds). The User and Role columns will be blank if the login feature of the rtvdisplay servlet is disabled.

20679: Table row selection in AW grid no longer unreliable in IE >= 10

In previous releases, when using the thin client in IE 10 and 11, after performing a drilldown from a table object subsequent row clicks in the same table may be ignored. This is fixed.

Functions

20846: New function Execute Java Method

Introduction The Execute Java Method function allows the user to write code for a Java method that will be executed when the function is updated. The method can take zero or more arguments of type String, Integer, Double, or GmsTabularData, and it can return an object of any of those same types. The Java code is saved with the display (.rtv) file that contains the function. On the first update, the function compiles the given java code. Then, on all updates, the function applies the given arguments to the compiled method and executes it. The Execute Java Method function is intended for implementing a 'one-of-a-kind' java method that is useful on a single RTView display, in cases where the Evaluate Expression functions are not adequate or perform poorly, and the reusability of a custom function implementation is not required or is inconvenient. Requirements - The Java Development Kit (JDK) must be installed on systems which will be used to configure or run the Execute Java Method function. The Java Runtime Kit (JRE) is not sufficient since it does not include the java compiler tools. - The person configuring the Execute Java Method function must be familiar with Java. - The person configuring the Execute Java Method function should be familiar with the com.sl.gmsjrt.GmsTabularData class, as described in the RTView customization document, if the function will deal with tabular data. - The Code argument of the function must be a valid code string for a Java method named eval with this signature: public Object eval() - The method can take zero or more arguments of type String, Integer, Double, or GmsTabularData. - The method's return type must be Object, and the returned Object must be a String, Integer, Double, or GmsTabularData instance. - The heap usage of the RTView application increases by about 6 to 10 MB to support the compiler. Recommended usage: The Execute Java Method function is a useful feature but it should be use when appropriate, to avoid maintenance and performance problems. - The Execute Java Method function is intended for implementing a 'one-of-a-kind' java method that is useful on a single RTView display, since its result can only be used on the same display (.rtv file) in which it is defined. If a method is needed on multiple RTView displays then it should be implemented in an RTView custom function handler class, instead. - The display containing the Execute Java Method function must only be deployed on systems with the JDK installed, otherwise the function's java code will not be compiled. Configuration: The internal name of the function is EVALJ. Its external name is "Execute Java Method". It appears just after "Evaluate Expression as String" in the dropdown list in the Builder's Edit Function dialog. The function takes one predefined string argument named Code, plus any number of user-defined arguments as described later. The Code string must be a java method named eval with this signature: public Object eval(args) For each new instance of the function, the Edit Function dialog will set the Code string to a "skeleton" implementation of the eval method as shown below: public Object eval() { return ""; } The eval method can take zero or more arguments of type String, Integer, Double, or GmsTabularData. The method's return type must be declared as Object, but it can return a String, Integer, Double, or GmsTabularData object. The arguments declared for the eval() method become arguments to the rtview function instance, just like the %x, %y tokens in an Evaluate Expression function. For example, here is a simple eval method that concatenates two String args named s1 and s2: public Object eval(String s1, String s2) { return s1 + ":" + s2; } In the Edit Function dialog, s1 and s2 will appear as argument fields so their values can be assigned to constants or attached to data: Here is a more complex example that takes a GmsTabularData argument. The input table is assumed to have an integer column named Value, and the function returns a copy of the input table with all rows removed where the Value column item is < 25 or > 75. The method makes use of utility methods named cloneInputTable and printErrorMessage, which are defined in the base class named com.sl.gmsjrtview.GmsJavaCodeExecutor: public Object eval(GmsTabularData t) { if (t == null) return t; int valCol = t.getColumnIndex("Value"); if (valCol < 0) { printErrorMessage("no Value column in table"); return t; } ArrayList<Integer> rowsToRemove = new ArrayList<Integer>(); for (int row = 0; row < t.getNumRows(); ++row) { int val = t.getIntCellValue(row, valCol); if (val < 25 || val > 75) { rowsToRemove.add(row); } } if (rowsToRemove.size() > 0) { // don't modify input table, clone it t = cloneInputTable(t); t.removeRows(rowsToRemove); } return t; } For documentation on the GmsTabularData and GmsJavaCodeExecutor classes, refer to the javadoc pages in the customization section of the RTView documentation. Compilation: The java code entered as the value of the Code argument for a function named F101 is used to generate the source code for a subclass of com.sl.gmsjrtview.GmsJavaCodeExecutor, as follows: package rtvfuncs; import com.sl.gmsjrt.GmsTabularData; import com.sl.gmsjrtview.*; import java.util.*; public class F101_Cnn extends com.sl.gmsjrtview.GmsJavaCodeExecutor { // begin user-defined code public Object eval() { return ""; } // end user-defined code } The suffix _Cnn on the generated class name is not significant and will vary. The source code for the class will be generated and compiled the first time the function is updated after the .rtv file is loaded. In the Builder, source code for the class will also be generated and compiled each time the user changes the code for the eval method and clicks OK or Apply. The compiler will use the same classpath as the RTView application. No external .java or .class files are produced for an Execute Java Method function. All source generation, compilation, and class loader operations are performed using memory buffers. The user-defined java code for the eval method is saved with the function in the .rtv file. As shown above, the generated source code imports com.sl.gmsjrtview.*, com.sl.gmsjrt.GmsTabularData, and java.util.*. If additional imports are needed they can be defined on lines above the eval() method in the Code argument, or globally with a property named sl.rtview.function.compiler_import. For example, these lines could be added to an rtview .properties file to import java.sql.* and java.math.* for all function instances: sl.rtview.function.compiler_import=java.sql.*; sl.rtview.function.compiler_import=java.math.*; Compiler errors are logged to the console. The complete generated source code, as described above, is shown before the compiler error so that the user can make sense of the line numbers in the error message. Examples: The following eval() implementation returns a table with 2 columns, "Name" and "Value", where the Name column contains "this is row N" and the Value column contains a random integer between 0 and 100. The number of rows in the table is determined by the numRows argument. The "trigger" argument could be attached to the result of a "Date Now" function, to trigger the function periodically. Otherwise it will only update once. public Object eval(int numRows, String trigger) { GmsTabularData t = new GmsTabularData(); t.addColumn("Name", GmsTabularData.STRING); t.addColumn("Value", GmsTabularData.INTEGER); for (int row = 0; row < numRows; ++ row) { String name = "this is row " + row; int val = (int) (Math.random() * 100); t.addRow(""); t.setCellValue(name, row, 0); t.setCellValue(val, row, 1); } return t; } This eval method takes a table as an argument. The input table is assumed to have an integer column named Value (e.g. the table returned from the previous example), and the function returns a copy of the input table with all rows removed where the Value column item is < 25 or > 75: public Object eval(GmsTabularData t) { if (t == null) return t; int valCol = t.getColumnIndex("Value"); if (valCol < 0) return t; ArrayList<Integer> rowsToRemove = new ArrayList<Integer>(); for (int row = 0; row < t.getNumRows(); ++row) { int val = t.getIntCellValue(row, valCol); if (val < 25 || val > 75) { rowsToRemove.add(row); } } if (rowsToRemove.size() > 0) { // don't modify input table, clone it t = cloneInputTable(t); t.removeRows(rowsToRemove); } return t; } This eval method implements a simple counter function. It declares an integer member variable named "count" and increments it on each update and returns the new count. The "trigger" argument could be attached to the result of a "Date Now" function, to trigger the function periodically. Otherwise it will only update once. private int count = 0; public Object eval(String trigger) { return ++count; } This eval method implements a counter function, similar to the previous example, but it demonstrates the use of the skipUpdate() method to prevent updating the function result in certain cases: private int count = 0; public Object eval(String trigger) { ++count; if (count % 5 == 0) { // don't update result for multiples of 5 System.out.println("skip counter update: " + count); skipUpdate(); } return count; } This eval method takes a table as an argument. The input table is assumed to have an string column named Status (e.g. production_table in update.xml produced by the RTView xml data simulator). The function returns a copy of the input table with the string in the Status column truncated to the length specified by the second argument, numCharsForStatusCol: public Object eval(GmsTabularData prodTable, int numCharsForStatusCol) { if (prodTable == null || prodTable.getNumRows() < 1) return prodTable; prodTable = cloneInputTable(prodTable); int statusCol = prodTable.getColumnIndex("Status"); if (statusCol < 0) { printErrorMessage("no Status column"); return prodTable; } for (int row = 0; row < prodTable.getNumRows(); ++row) { String sts = prodTable.getCellValue(row, statusCol); if (sts != null && sts.length() > numCharsForStatusCol) { sts = sts.substring(0, numCharsForStatusCol); prodTable.setCellValue(sts, row, statusCol); } } return prodTable; }

General

20326: New -version flag that prints version information without starting the app

Each of the RTView applications now supports a -version option on the command line which will cause the app to print the RTView version information and then exit immediately. For example: run_dataserver -version

20815: Fixed array index exception thrown when client receives bad table delta

A bug has been fixed that in certain conditions caused an ArrayIndexOutOfBoundsException to be thrown by a client when it received an update from a data server. This was most likely to occur if the update was for the current table of a cache which recently had multiple rows removed via its rowsToDeleteTable property.

Logging

19543: Alert notification script output error when using log4j

Alert notifications from an RTView now go to a log4j output as desired.

Object Library

19936: Added support for data quality to obj_statushistory

The status history chart (obj_statushistory) has been enhanced to indicate data quality. Two new properties have been added, named valueQualityColumnName and valueQualityBadValuesList. These properties can be used to set a color and pattern to be plotted when on a bar when the data quality is bad. The valueQualityColumnName property can be set to the name of the table column that contains a value indicating the data quality for each row. The column can contain string, integer, or boolean values. The valueQualityBadValuesList property can be set to a string containing value,label pairs with each pair separated by semicolons. This is used to assign a label to a numeric bad quality value, for example "-1,no data;0,stale data" The default value for valueQualityColumnName is blank, which means that the new feature is disabled. In this mode the color and pattern for each bar is determined by getting the value for that row from the column specified by valueColumnName, and looking up that value in the chart's barProperties. (This is the behavior in all prior releases). If valueQualityColumnName non-blank, then for each row R the row's value to be plotted is determined as follows: - let Q = value of quality column for row R, and V = value of value column for row R - if Q is blank, then the quality is considered good and V is used at the row value, as normal. - else if the valueQualityBadValuesList property is blank, then Q is used as the row value. - else if valueQualityBadValuesList contains an entry "Q,X" then X is used as the row value - else the quality is considered good (since no match was found in valueQualityBadValuesList) and V is used at the row value Then the row value is looked up in barProperties, as usual, to determine the color and fill pattern. That value is also shown in the mouseover text as usual. For example, consider the following data table: Plant Status Quality ----- ------ ------- A online 1 B offline 1 C online -1 D offline 0 ... where 1 = data OK, -1 = no data, and 0 = stale data. Next, consider a status history chart with these properties: indexColumnNames = Plant valueColumnName = Status valueQualityColumnName = Quality valueQualityBadValuesList = -1,no Data;0,stale data barProperties = online : green offline : blue no data : red stale data : orange Note that valueQualityBadValuesList has no entry for quality = 1, because that is the "good" quality value. With that configuration, when the data table shown above is applied to the chart, it will plot a segment for each Plant as follows: A green (since Status = online and Quality = 1 / OK) B blue (since Status = online and Quality = 1 / OK) C red (since Quality = -1 / no data) D orange (since Quality = 0 / stale data)

20710: Enhanced text controls to only execute actions if text changed

A new property named executeOnlyIfChangedFlag has been added to the text control objects (obj_c1text*). If executeOnlyIfChangedFlag is true, and if the text control's varToset and its valueString or value property are attached to the same local variable, then the control's command will be executed only if the text in the control is changed. By default executeOnlyIfChangedFlag is false, in which case the control's command is executed whenever the control loses focus (if executeOnFocusLostFlag = true or if the control is a text area) or whenever the user presses the Enter key in the control (if the control is not a text area), regardless of whether the text in the control was changed. This matches the text control behavior in all previous releases.

20771: New Tab Control object

A tab control object is now supported in RTView. The name of the object is obj_c1tabs. It appears on the Controls tab of the Builder's object palette. The tab control has two "fake" tabs labelled A and B when it is drawn on the palette, and also when the user places an instance on a display. The fake tabs are replaced with the actual tabs by attaching the tab control's valueTable property to a data table containing one row for each tab. The size given to the control in the Builder determines the space available for tabs. The tabs are drawn horizontally with the first tab at the left edge of the control. If the control is not wide enough to show all of the tabs, the tabs will wrap vertically. If the control is not tall enough to show all of the tabs, some of the tabs may be clipped or invisible. Changing the control's labelTextSize property will change the size of the tab label text, which will also affect the size of the tabs. The tab control is populated from a data table attached to its valueTable property, with one tab created for each row in the table. The following tab control properties are used to map the columns of the data table to each tab: labelColumnName - the value from this column is used as the tab label. If labelColumnName does not specify a column in the valueTable or if it contains an empty string, then the tab for row N in the valueTable will be labelled "Tab N". The labelColumnName property appears in the Label category. valueColumnName - the value from this column is assigned to the variable (if any) attached to the tab control's varToSet property when the corresponding tab is selected by the user. If valueColumnName does not specify a column in the valueTable, then the tab's index (0 through N - 1, for a table with N rows) is used as the tab value. The valueColumnName property appears in the Data category. imageColumnName - the value from this column is used to load an icon image, shown to the left of the tab's label . If imageColumnName does not specify a column in the valueTable, or if the column is empty, or if the image can't be found, the tab will not contain an icon. An icon will affect the size of the tab. The imageColumnName property appears in the Image category. mouseOverColumnName - the value from this column is used as the tooltip for each tab. If mouseOverColumnName does not specify a column in the valueTable, or if the column is empty, the tab will not display a tooltip. The mouseOverColumnName property appears in the Interaction category. The tab control supports the drillDownColumnSubs property, which can be useful in cases where the tab's command is a drilldown. As with other objects that support drillDownColumnSubs, it can be used to set the values for substitutions and local variables from columns in the row of the valueTable that corresponds to the selected tab. As usual, the control's visFlag property can be used to toggle the control's visibility. Unlike the other control objects, the tab control does not support the enabledFlag property so it is always enabled. As on other control objects, the predefined substitution named $value can be used in the control's command. The value of the selected tab will be substituted for $value when the command is executed. (See the valueColumnName property for a description of how a tab's value is determined). If a tab control has a command defined and the commandConfirm property is checked, the user will be asked to confirm the command when a tab is clicked, but the clicked tab will become the selected tab regardless of the user's response. Limitations / Differences: - In the thin client, the tab control is not supported in IE version 8 or older and will not appear in displays opened in those versions. - The tab sizes and appearance may differ somewhat when viewed in the Builder/Viewer vs. thin client. - In the thin client, the background color of the selected tab is brighter than the unselected tabs, while in the builder/viewer the selected tab is darker than the other tabs. (This difference is intentional, to conform with the standard appearance of tabs in Swing vs. a browser.)

20790: New Google Map object

Introduction: ------------- A new display object for embedding a Google Map in an RTView display is now supported. The new object is named obj_gmap and is located on the Graphs tab in the Builder's object palette. In the builder, an obj_gmap instance appears as a gray "placeholder" rectangle which is used to set the size and position of the map on the display, and to allow configuration of the latitude, longitude, zoom level and other map properties via the Builder's property sheet. The Google Map is only rendered when the display is opened in the thin client. In the Builder and Viewer, and obj_gmap instance will always appear as an empty gray rectangle. Using the map properties and RTView data attachments, the map can be populated with marker objects at specific lat/long positions, and also links between the markers. RTView drilldown and command operations can be triggered by clicks on the map, or on the markers or links on the map. Double click and right click actions, and drillDownColumn subs are supported, as on other RTView table-driven objects. Map operations such as zoom, pan, and marker selection can be tied to rtview variables. Requirements: ------------- The thin client must have internet access in order to download the Google Maps javascript API and map data. The thin client supports Google Maps in Internet Explorer version 9 or newer, and any other RTView-supported browsers (Firefox, Chrome, iOS Safari). The Viewer does not support the map object. The thin client loads the Google Maps Javascript API to render and manipulate the map. In most cases a key or license must be obtained from Google for business use of the Google Maps Javascript API. See the "Licensing" section later in this document. Map Object Properties and Features: ----------------------------------- A Google Map is added to an RTView display by creating an instance of the obj_gmap display object, found on the Graphs tab of the Builder's object palette. In the builder, an obj_gmap instance appears as a gray "placeholder" rectangle which is used to set the size and position of the map on the display, and to allow configuration of the latitude, longitude, zoom level and other map properties via the Builder's property sheet. The Google Map is only rendered when the display is opened in the thin client. The following properties are supported by obj_gmap: ("Data" category): + valueTable: This property can be used to place markers (icons) on the map, at specific locations. The property should be attached to a table that contains one row for each marker, with the columns shown below. The column names are unimportant, but the column order and type must be as follows. The first 3 columns are required, the others are optional. column 1 (string): name column 2 (number): latitude column 3 (number): longitude column 4 (string): icon name/path column 5 (integer): icon height in pixels The marker name is used is drilldowns to indicate the selected (clicked) marker, and can also be used to select a marker, so it should be unique. If column 4 (icon name) is omitted or is empty, the default Google Maps marker will be used. If column 5 (icon height) exists and its value is > 0, the value is used to center the icon on the marker's lat/long position, otherwise the 0,0 pixel of the icon will be placed on the marker's lat/long position. + valueTableForLinks: This property can be used to draw links between markers on the map. The property should be attached to a table that contains one row for each link, with the columns shown below. The column names are unimportant, but the column order and type must be as follows. The first 2 columns are required, the others are optional. column 1 (string): name of marker at start of link column 2 (string): name of marker at end of link column 3 (string): link line color, as a css color name or #rrggbb hex value. column 4 (integer): link line width column 5 (integer): arrow mode The first two columns specify the names of the markers at the start and end of the link. These must correspond to the names of markers in the valueTable. If column 3 is omitted the link color is black. If column 4 is omitted the link width is 2 pixels. The arrow mode values are 1 (one arrow, pointing to start marker), 2 (one arrow, pointing to end marker) and 3 (two markers, at each end of link). If column 5 is omitted the default mode of 3 is used. ("Interaction" category): + command: the command to invoke when the user clicks on the map, a marker, or a link + drillDownColumnSubs: this property is treated the same as for other table-driven objects. If a marker is clicked, the drillDownColumnSubs are set using values from the valueTable row that corresponds to that marker. If a link is clicked, the drillDownColumnSubs are set using values from the valueTableForLinks row that corresponds to that link. In addition, the following predefined substitutions are also set when a drilldown is executed: $mapSelLat : the latitude of the map location or marker clicked $mapSelLng : the longitude of the map location or marker clicked $mapLat : the latitude of the map's current center location $mapLng : the longitude of the map's current center location $mapZoom : the current zoom level of the map, a value between 0 and 21 + drillDownSelectMode: This property can be set to the following values: Anywhere: a click anywhere on the map will trigger the object's command or drilldown. Markers: only a click on a marker will trigger the command or drilldown. Links: only a click on a link will trigger the command or drilldown. Markers & Links only a click on a marker or a link will trigger the command or drilldown. + menuItemGroup: As with other objects (table, heatmap, tree) this property is used to add custom items to the context menu, when a map marker is right-clicked. + label: The label string for the map placeholder object. This is visible only in the Builder. ("Map" category): + labelsZoomThreshold: If this property is set to a value > 0 a label balloon will appear next to each marker when the zoom level is greater than or equal to that value. The label text in the balloon is the name assigned to the marker, by the first column in the valueTable. A label can be closed by clicking its "x" button. The label will reappear if the display is closed and reopened or if the zoom threshold is crossed again later. The default value of labelsZoomThreshold is zero which disables the labels. + latitude: the latitude of the point on which the map is to be centered + longitude: the longitude of the point on which the map is to be centered * selectedMarker: the name of the marker to select + zoom: the zoom level of the map, between 0 and 21. The other properties supported by the map object but not listed here are common to all display objects, and have the same purpose and behavior as on the other display objects. Licensing: ---------- Business use of the Google Maps Javascript API typically requires a key or license from Google. For more information, see the following: https://developers.google.com/maps/licensing SL does not provide a key or license for the Google Maps Javascript API. However, the thin client can be configured to download the API using a custom URL that contains specific key or license information obtained from Google. The custom URL is defined by modifying the rtv_custom.js file contained in rtvdisplay.war. (Refer to the customization section of the RTView documentation for details on modifying rtvdisplay.war) To specify a custom URL to download the Google Maps Javascript API, add the following line to rtv_custom.js: rtv.customGoogleMapsApiBaseURL = 'url'; For example, to specify a URL containing a Google API key: rtv.customGoogleMapsApiBaseURL = "https://maps.googleapis.com/maps/api/js?key=YOUR_GOOGLE_API_KEY"; Or, to specify a "Google Maps API for Work" client ID and release version 3.20: rtv.customGoogleMapsApiBaseURL = "https://maps.googleapis.com/maps/api/js?client=YOUR_GOOGLE_CLIENT_ID&v=3.20"; If no rtv.customGoogleMapsApiBaseURL value is specified, the thin client will use the following public URL to download the latest "experimental" version of the API with no key or license information: https://maps.googleapis.com/maps/api/js

20828: New bgClipTextFlag property added to obj_rect* label objects

The following objects support a new property named bgClipTextFlag: obj_rect_il obj_rect_ilv obj_rect_ilvs obj_rect_ilvx_da3 obj_rect_ilvx_ra4 obj_ind_discrete If the object's bgClipTextFlag is checked and its bgVisFlag is checked then its label and/or its valueString (whichever string is drawn within the background rectangle) will be clipped by the object's background rectangle. That is, the object's label will be clipped by the background rectangle if labelTextPosX is Inside Left, Center, or Inside Right AND labelTextPosY is Inside Top, Center, or Inside Bottom . The object's value or valueString (if any) will be clipped by the background rectangle if valueTextPosX is Inside Left, Center, or Inside Right AND valueTextPosY is Inside Top, Center, or Inside Bottom. In the Builder, the bgClipTextFlag property appears in the Background category on the property sheet. By default, bgClipTextFlag is unchecked. The property is not visible if bgVisFlag is unchecked. Only the visible text can be copied to the clipboard, in the thin client.

20877: New property selectedValueColumnName to enhanced tree node selection

A property named selectedValueColumnName has been added to the tree/accordion controls. The property can be used to specify the name of the column in the valueTable to which the selectedValue should be compared, for selecting a node in the tree/accordion. This can be useful in cases where the value from one column (specified by valueColumnName) in the valueTable should be used to set the $value substitution when a tree node is clicked by the user, but a value in a different column (specified by selectedValueColumnName) should be used to highlight a tree node via the selectedValue property, If the selectedValueColumnName property is not set, then the existing valueColumnName property value will be used instead as in prior versions when highlighting the tree node that matches selectedValue.

Platform Support

19925: Support Java 1.8

Java 1.8 is now officially supported. NOTES: As noted in the release notes for 19927 and 19928, the JdbcOdbc driver is no longer supported by Oracle beginning in Java 1.8. Version v4.14.137 of IBM DB2's db2jcc.jar driver is required to work with Java 1.8

Security

20794: Fixed XSS Security Issue in Thin Client Deployment

A cross-site scripting (XSS) vulnerability in the thin client has been fixed.

Transaction Message Monitor

20672: Transaction monitor end of life announced

The Transaction Monitor application will be end of life in RTView version 6.7. A warning about this has been added to the console and the tmdisplays demo has been removed from the RTView demos directory. In previous releases, the Transaction Monitor threw an exception at startup. This has been fixed.

Scripts

19395: start/stop/status scripts argument handling enhanced and new verbose option

The RTView start/stop/status scripts have been enhanced as follows: 1. Improved argument handling for start_rtv The new start_rtv command line is as follows: start_rtv config or 'all' [server or 'all'] [-verbose] [-console] [-args...] Note the following: a) it is no longer necessary to specify 'all' for server. If the server argument is omitted (and the next argument starts with "-") then 'all' will be assumed. In other words, these commands are equivalent: start_rtv default all -properties:xxx start_rtv default -properties:xxx b) The flags -verbose, -console must appear before any other optional args. Note also they may be abbreviated to their first letter (-v, -c). 2. Improvements in stop_rtv a) The script now runs kill_dataserver using its verbose mode and examines the output for errors or exceptions. If found it displays something like this: >> stop_rtv central ConfigServer ConfigServer: Stopping PID 6432 via JMX port 10013 ... ConfigServer: Error report from kill_dataserver: java.lang.NoClassDefFoundError: invokeJmxOperation Caused by: java.lang.ClassNotFoundException: invokeJmxOperation ConfigServer: was not stopped. b) The script now verifies that the process was killed by re-running the netstat command to see if its ports were freed. It will say either XXXServer: ... stopped. ...or... XXXServer: ... was not stopped. c) The script now takes an optional argument "-dump": stop_rtv config or 'all' [server or 'all'] [-verbose] [-dump] [-args...] This will cause the script to take three stack dumps 30 seconds apart before attempting the kill. (This assumes jstack is in your path.) Note also the argument may be abbreviated to its first letter (-d). 3. Addition of verbose mode All the scripts now take an optional argument "-verbose". Annotated examples of the output follow. a) start_rtv emsmon dataserver -verbose --------------------------------------- Start emsmon: [ echo args, echo dir/server/command from rtvservers.dat ] ...start_rtv.bat: emsmon dataserver: ./emsmon dataserver rundata [ output from rtvapm_common ] ...rtvapm_ports.bat calling rtvapm_common.bat dataserver java version "1.6.0_38" Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) Client VM (build 20.13-b02, mixed mode, sharing) ... using RTVAPM packages: emsmon Setting standard package properties: -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon ***** OPTIONS=-rtvapm_packages:emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm \emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver -propfilter:collector [ output from rtvpropreader ] [ note: disregard error re. emcommon.properties ] [ note: CMD block has complete command line ] ...calling rtvpropreader.bat dataserver dataserver ERROR: Cannot load properties file: emcommon.properties JVM: -Xmx256m -Xms128m -Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sl.rtview.useLog4j=true -Dcom.sl.rtvie w.RTVLog4jLevel=info -Dcom.sl.rtview.showLogCategory=true -Xmx768m -Xms128m -Dlog4jFile=logs/dataserver.log -Xmx1024m -X ms256m -Dcom.sun.management.jmxremote.port=3168 JMX:3168 DATA:3178 CMD:-log4jprops:C:\rtvdemos\rtvapm/common/conf/sl.log4j.properties -daemon -proctag:RTVAPM.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 -jmsadmdsdebug -proctag:EMSMON.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 dataserver -rtvapm_packages: emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver -propfilter:collector -properties:emcommon -propfilter:ConfigClient [ results from rtvpropreader ] ...got datport=3178, jmxport=3168 [ output from netstat command ] ...data port 3178: netstat -anop tcp finds: ...jmx port 3168: netstat -anop tcp finds: [ results from netstat command] ...got datpid=, jmxpid= [ not running, okay to start ] dataserver: Executing rundata -bg b) stop_rtv emsmon dataserver -verbose -------------------------------------- Stop emsmon: [ output from rtvapm_common ] ...rtvapm_ports.bat calling rtvapm_common.bat dataserver java version "1.6.0_38" Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) Client VM (build 20.13-b02, mixed mode, sharing) ... using RTVAPM packages: emsmon Setting standard package properties: -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon ***** OPTIONS=-rtvapm_packages:emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver -propfilter:collector [ output from rtvpropreader ] ...calling rtvpropreader.bat dataserver dataserver ERROR: Cannot load properties file: emcommon.properties JVM: -Xmx256m -Xms128m -Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sl.rtview.useLog4j=true -Dcom.sl.rtview.RTVLog4jLevel=info -Dcom.sl.rtview.showLogCategory=true -Xmx768m -Xms128m -Dlog4jFile=logs/dataserver.log -Xmx1024m -Xms256m -Dcom.sun.management.jmxremote.port=3168 JMX:3168 DATA:3178 CMD:-log4jprops:C:\rtvdemos\rtvapm/common/conf/sl.log4j.properties -daemon -proctag:RTVAPM.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 -jmsadmdsdebug -proctag:EMSMON.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 dataserver -rtvapm_packages:emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver -propfilter:collector -properties:emcommon -propfilter:ConfigClient [ results from rtvpropreader ] ...got datport=3178, jmxport=3168 [ output from netstat command ] ...data port 3178: netstat -anop tcp finds: TCP 0.0.0.0:3178 0.0.0.0:0 LISTENING 3016 ...jmx port 3168: netstat -anop tcp finds: TCP 0.0.0.0:3168 0.0.0.0:0 LISTENING 3016 TCP 127.0.0.1:1570 127.0.0.1:3168 ESTABLISHED 3016 TCP 127.0.0.1:3168 127.0.0.1:1570 ESTABLISHED 3016 [ results from netstat command ] ...got datpid=3016, jmxpid=3016 [ running, okay to stop ] dataserver: Stopping PID 3016 via JMX port 3168 ... [ output from kill_dataserver (-verbose) ] [ note: disregard UnmarshalException ] ...calling kill_dataserver -port:3168 Trying to connect to [service:jmx:rmi:///jndi/rmi://localhost:3168/jmxrmi] ... Finding mBean [RTViewHistorian:name=Manager] ... Locating operation: [killHistorian] ... Invoking operation: [killHistorian] ... InvokeJmxOperation: an UnmarshalException occurred. Success: the operation was successfully invoked. The Data Server has been shut down. [ repeat call to rtvapm_ports to verify kill ] ...verifying kill ... ...rtvapm_ports.bat calling rtvapm_common.bat dataserver [ output from rtvapm_common ] java version "1.6.0_38" Java(TM) SE Runtime Environment (build 1.6.0_38-b05) Java HotSpot(TM) Client VM (build 20.13-b02, mixed mode, sharing) ... using RTVAPM packages: emsmon Setting standard package properties: -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon ***** OPTIONS=-rtvapm_packages:emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver -propfilter:collector [ output from rtvpropreader ] ...calling rtvpropreader.bat dataserver dataserver ERROR: Cannot load properties file: emcommon.properties JVM: -Xmx256m -Xms128m -Dcom.sl.rtview.customRtvAppManagerClassName=com.sl.gmsjrtvutils.RtvApmAppManager -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sl.rtview.useLog4j=true -Dcom.sl.rtview.RTVLog4jLevel=info -Dcom.sl.rtview.showLogCategory=true -Xmx768m -Xms128m -Dlog4jFile=logs/dataserver.log -Xmx1024m -Xms256m -Dcom.sun.management.jmxremote.port=3168 JMX:3168 DATA:3178 CMD:-log4jprops:C:\rtvdemos\rtvapm/common/conf/sl.log4j.properties -daemon -proctag:RTVAPM.RtvDataServer -sub:$domainNam e:SL-EMSDEMOS-1 -jmsadmdsdebug -proctag:EMSMON.RtvDataServer -sub:$domainName:SL-EMSDEMOS-1 dataserver -rtvapm_packages: emsmon+ -properties:C:\rtvdemos\rtvapm\common\conf\rtvapm -properties:C:\rtvdemos\rtvapm\emsmon\conf\rtvapm.emsmon -properties:rtview -propfilter:dataserver -propfilter:collector -properties:emcommon -propfilter:ConfigClient [ results from rtvpropreader ] ...got datport=3178, jmxport=3168 [ output from netstat command ] ...data port 3178: netstat -anop tcp finds: ...jmx port 3168: netstat -anop tcp finds: ...got datpid=, jmxpid= [ kill verified ] dataserver: ...stopped.

20789: RTV_USERPATH no longer incorrectly set when project directory changes

Previously it was not possible to reuse a command window to start different RTView EM projects. This has been fixed.

20869: TIBCO RV datasource disabled when launching central and non-tibco components

The rtvservers.dat file in emsample/servers has been edited so that the argument -notibco is specified for any dataserver that does not require TIBCO data. This allows for more efficient startup and shutdown.

Service Model

19984: Increased CIName column size for CMDB database

The size of the CIName column has been increased from 50 to 255 characters to account for large CI Names being included in the CMDB database table. To update your existing tables, follow the alter table sql sentence to apply to each of our supported DB platforms. DB2: ALTER TABLE "RTVCMDB" ALTER COLUMN "CIName" SET DATA TYPE VARCHAR(255); Oracle: ALTER TABLE "RTVCMDB" MODIFY "CIName" VARCHAR2(255) NOT NULL; SQL Server: ALTER TABLE [RTVCMDB] ALTER COLUMN [CIName] VARCHAR(255) MySQL: ALTER TABLE "RTVCMDB" MODIFY "CIName" VARCHAR(255); SyBase: ALTER TABLE "RTVCMDB" MODIFY "CIName" VARCHAR(255) NOT NULL

Solution Package

Amazon CloudWatch

20629: ACWMON enhanced to provide instance IP address and name

The previous versions of the Amazon CloudWatch solution package used an "instance" identifier assigned by ACW as the index for the AwsEc2InstanceStats cache. No other host data was available that could be used to relate host data in this cache with host data collected by other solution packages. For this release, the public IP address of the instance has been added to the AwsEc2InstanceStats cache, and additional information about the instance is available in a new AwsEc2Instances cache.

GlassFish Application Server

20900: Decommission Glassfish

The Solution Package for Glassfish has been removed from RTView Enterprise Monitor.

IBM Websphere Application Server

20095: WSM historian entry in rtvservers.dat corrected

The rtvservers.dat file in emsample/servers contained an incorrect entry for "wsm historian". This has been corrected. The rtvservers-ha.dat file in emsample/servers contained incorrect entries for "wsm historian" and "uxmon historian". These have been corrected.

IBM Websphere MQ

20845: New substitution to filter MQ queries

A new substitution has been defined to limit the Channels that are being queried from MQ. This is useful when the user does not have access to all Channels, to prevent permission errors. The substitution can be set with the following line in the properties files: sl.rtview.sub=$mqChannelFilter:*

20887: Improved configuration of sample MQMON project

The sample MQMON project has been enhanced to specify an example connection in the sample.properties file instead of the IBMMQOPTIONS.ini file.

JBoss

20685: JBoss Solution Package

JBOSSMON is released supporting the following versions: - JBoss EAP 6.1 - JBoss EAP 6.3. - JBoss AS 7.1.1 - WildFly 9 The current Solution Package collects information about key performance metrics from JBoss Servers and Web Applications. JBOSSMON is integrated by default under RTView EM in the miscmon directory. The JBOSSMON Solution package contains five displays: - All Servers Heatmap, - All Servers Table, - Server Summary, - Applications Heatmap, and - Applications Summary. The All Servers Heatmap|Table and the Server Summary displays provide metrics about Alert Level, JVM monitoring information like Process CPU %, Memory Utilization as well as Session information (Created, Active, Rejected Expired). For Web Applications, the Heatmap and Summary displays provide information about Requests, Processing Time, and Average Response Time being calculated as the ratio between the former two metrics. The Average Response Time is a relevant metric to evaluate Web Applications performance. The number of Active Sessions, the rate of Sessions Created, the rate of Requests, and the Average Response Time are kept in history and trended in the Applications Summary. The Alerts that have been implemented are the following: - JbossServerSystemCpuLoadHigh, - JbossServerSwapUsedHigh, - JbossServerProcessCpuLoadHigh, - JbossServerMemoryUsedPercentHigh, - JbossServerActiveSessionsHigh, - JbossAppWithDuplicateIds, and - JbossAppActiveSessionsHigh. These alerts are implemented under the RTView Self-Service Alerts Framework and operate equivalently to the alerts under RTView EM. JBOSSMON displays provide light indicators to inform when alerts or warnings have been raised. To establish connection, you need to reference the jars from your JBoss installation in the properties file. There is one example on that under rtvapm\jbossmon\projects\sample\sample.properties and also under EM in rtvapm\projects\emsample\miscmon\sample.properties. You should copy the connection and the cache config source files and provide an appropriate name to each of your connections. This name should be the same in the $jbsConnString substitution. Example of connection to WildFly 9: collector.sl.rtview.cp=C:/WILDFLY/wildfly-9.0.0.CR1/bin/client/jboss-cli-client.jar collector.sl.rtview.jmx.jmxconn=MyWildFlyInstance - - URL:service:jmx:http-remoting-jmx://yourIPAddress:port myUser myPassword false collector.sl.rtview.cache.config=jboss_server_cache_source.rtv $jbsConnString:'MyWildFlyInstance' collector.sl.rtview.cache.config=jboss_deployment_cache_source_wildfly.rtv $jbsConnString:'MyWildFlyInstance' Example of connection to JBoss EAP 6.3: collector.sl.rtview.cp=C:/JBOSS/jboss-eap-6.3/bin/client/jboss-cli-client.jar collector.sl.rtview.jmx.jmxconn=MyJBOSS6.3 - - URL:service:jmx:remoting-jmx://yourIPAddress:port myUser myPassword false collector.sl.rtview.cache.config=jboss_server_cache_source.rtv $jbsConnString:'MyJBOSS6.3' collector.sl.rtview.cache.config=jboss_deployment_cache_source.rtv $jbsConnString:'MyJBOSS6.3' The connectivity required for monitoring JBoss in standalone or domain launching modes is identical. You can switch between launching modes without further changes in the connection to the server unless you use a different JBoss Server to manage the domain.

Oracle Coherence

19009: Optimized JMX data retrieval option using custom MBeans (JMX Tables)

An option is available to speed up retrieval of Coherence MBean information (over JMX) by providing the aggregated MBean data in tabular form by using custom MBeans. This option is useful when monitoring large clusters (clusters with a large number of nodes, caches and or services) using JMX, where the volume of data retrieved can effect the time taken to retrieve all the data, and thus limit the sampling rate for monitoring data. By using custom MBeans the data is aggregated within the cluster, and transmitted in the form of tabular data, rather than as individual attributes, reducing the time taken to query the data. Enabling this requires (unlike default JMX monitoring) that the custom MBeans (contained in a jar) are deployed and registered on all nodes in the cluster, and the monitoring is configured to query the custom MBeans. The Oracle Coherence Documentation describes registering custom mbeans in a declarative manner in detail https://docs.oracle.com/cd/E18686_01/coh.37/e18682/custom_mbeans.htm#COHMG4712 The key points are: * The Custom MBeans must be found at run time. Make sure to place the library that contains the MBeans in the classpath of the coherence nodes/members including the JMX management-enabled member. * The Custom MBeans are specified using a MBean Configuration Override File The Custom MBeans (CacheTable, ServiceTable, StorageManagerTable) are contained in the jar ocjmxtables.jar. The jar ocjmxtables.jar is located in the rtvapm/ocmon/lib directory of the ocmon installation. This jar file must added to the classpath of the Coherence members to be monitored. This may require that the jar be copied to a location that is visible to all the coherence members. This may vary based on your deployment. It may prove convenient to copy it to where the coherence jars are deployed, so they can use the same classpath root. The tangosol.coherence.mbeans system property specifies an MBean configuration override file to be used instead of the default custom-mbeans.xml override file. The MBean configuration file to be used is called sl-custom-mbeans.xml and is contained at the root of the ocjmxtables.jar. Thus when the ocjmxtables.jar is added to the Coherence members classpath, it can be specified by setting the tangosol.coherence.mbeans system property for the Coherence cluster members to reference it thus -Dtangosol.coherence.mbeans=/sl-custom-mbeans.xml The above should be applied to all Coherence cluster members so that the tangosol.coherence.mbeans system property is set to /sl-custom-mbeans.xml If you have configured your coherence cluster correctly, you should be able to connect to the cluster using JConsole, and see in addition to the previous Cache, Service, and StorageManager MBeans the new custom CacheTable, ServiceTable, and StorageManagerTable MBeans. To configure the ocm monitoring system to use the Custom MBeans, you should configure your monitoring system to use JMX as normal, and then uncomment the (rtview.properties) line below # JMX TABLES # # Uncomment the line below to use the JMX tables custom mbeans #maincollector.sl.rtview.cmd_line=-ocjmxtables so that the -ocjmxtables command line argument is passed to the maincollector program (typically this is the dataserver) If this is done, then the log file will contain the following text at startup ... using OC JMX Tabular Data And at runtime, the previous JMX queries ( as seen in the JMX Metrics Administration display in the MBean Query Key column of the RTView JMX Query Statistics table ) * Coherence:type=Cache,* 0 * -1 *- * Coherence:type=Cluster 0 * -1 *- * Coherence:type=Service,* 0 * -1 *- Will now be * Coherence:type=CacheTable,* 0 CacheTable -1 *- * Coherence:type=ServiceTable,* 0 ServiceTable -1 *- * Coherence:type=StorageManagerTable,* 0 StorageManagerTable -1 *- And should have a reduced execution time leading to a reduced total (Jmx Query) Execution time. In Summary * Add the ocjmxtables.jar to the classpath of the cluster members * Set -Dtangosol.coherence.mbeans=/sl-custom-mbeans.xml for the cluster members JVM's * Use the maincollector.sl.rtview.cmd_line=-ocjmxtables property for the OCM monitoring system.

20641: New Top Level Cluster Selection Screen

A new top level cluster selection screen has been added. The new top level screen consists of a single table where each row represents a coherence cluster that is being monitored. Selecting a row in the Cluster Selector table will navigate to the Cluster - Overview screen for that cluster. Data will come from the selected dataserver, and the named connection will be selected cluster drop down selector on the cluster overview screen. Each row in the table has summary overview data for the monitored (coherence) cluster. The Columns in the table are described as follows. Connection: The name of the used defined connection used to connect to the monitored coherence cluster. Alert Severity: A "traffic light" icon representing the max alert severity of alerts on that cluster. * Red - Alerts have triggered for the given cluster. * Amber - Warning Alerts have triggered for the given cluster. * Green - No Alerts have triggered for the given cluster. Alert Count: The number of Alerts for the given cluster. Cluster Size: The total number of nodes for the given cluster. Caches: The total number of caches for the given cluster. Objects: The total number of objects stored in the given cluster. Data Sever:The name of the Data Server (connection) used to monitor the given cluster For Standalone OCM Systems where there is only one (default) dataserver - the dataserver is named __default. In systems where there are multiple dataservers used to monitor coherence clusters, each dataserver is named using the named dataserver connection used to connect to that dataserver. In this way the table contains all the (declared) dataservers used to monitor coherence clusters. In the case of dataservers monitoring multiple coherence clusters via multi cluster monitoring, there will be one row for each connection on that cluster. Selecting that row in the table will navigate to the Cluster - Overview screen for that cluster. Data will come from the selected dataserver, and the named connection will be selected cluster drop down selector on the cluster overview screen.

20761: Add background colors for new StatusHA Values

Background colors have been added for the new StatusHA Values RACK-SAFE and SITE-SAFE, where the StatusHA value is displayed in existing displays. A contrasting text color is used

20763: New Alert OcHATargetFailed

A new alert OcHATargetFailedhas been added. This alert triggers when the (distributed service) target status (HATarget) has not been met. The HA Target value is determined using the PartitionAssignment MBean in Coherence Versions 12 and above. In prior versions of coherence, the default value of MACHINE-SAFE is used. The default value can be overridden by setting the substitution variable $ocmDefaultHATarget to the desired value.

20854: New CPU Metric in Cache, UI and Alert

A new metric is available to monitor average CPU use across a cluster by storage class, and alert if it is excessive. A new Metric AvgCpuPercent has been added to the OcNodeTotals cache. This metric is the average CPU usage of all the nodes of a given storage class in a cluster. The storage class is represented by the StorageEnabled index column, which can be true or false. Thus metrics for storage enabled nodes in a cluster are aggregated into a cache row where StorageEnabled = true, and non storage enabled nodes in a cluster are aggregated into a cache row where StorageEnabled = false. This metric is displayed as trace on the Cluster - Memory/Network Health display. The Metric has the legend "Avg. CPU %" and is displayed (for storage enabled nodes) in the Storage Nodes trend grouping and (for non storage enabled nodes) in the Process Nodes trend grouping. A new alert - OcClusterNodesCPUHigh has been added. This alert will trigger when the average CPU usage for the cluster / storage class goes above the specified threshold for the specified duration. This alert has a per cluster and a per (cluster) storage class override. This alert appears in the "Other" Category when triggered.

20865: New Cluster Nodes Alerts

New Alerts are available to monitor memory use and network health across a cluster by storage class, and alert if it is excessive. The metrics are averaged across all of the nodes of a given storage class in a cluster. The storage class is represented by the StorageEnabled index column, which can be true or false. Thus metrics for storage enabled nodes in a cluster are aggreagated into a cache row where StorageEnabled = true, and non storage enabled nodes in a cluster are aggreagated into a cache row where StorageEnabled = false. A new alert - OcClusterNodesMemHigh has been added. This alert will trigger when the average memory usage for the cluster / storage class goes above the specified threshold for the specified duration. This alert has a per cluster and a per (cluster) storage class override. This alert appears in the "Memory" Category when triggered. A new alert - OcClusterNodesSentFailureRateHigh has been added. This alert will trigger when the average (network/packet) sent failure rate for the cluster / storage class goes above the specified threshold for the specified duration. This alert has a per cluster and a per (cluster) storage class override. This alert appears in the "Memory" Category when triggered. A new alert - OcClusterNodesRcvdFailureRateHigh has been added. This alert will trigger when the average (network/packet) received failure rate for the cluster / storage class goes above the specified threshold for the specified duration. This alert has a per cluster and a per (cluster) storage class override. This alert appears in the "Network" Category when triggered.

20866: New Cache Activity Alerts

New alerts are available to monitor cache activity across cache tiers and alert if it is excessive. The metrics represent rate of various activities against a given tier of a given cache for a given service in a given (coherence) cluster. The tier can be front, where appropriate, or back. Caches and services are named, and (coherence) clusters are represented by their named monitoring connection. A new alert - OcCacheRateTotalPutsHigh has been added. This alert will trigger when the rate of cache puts goes above the specified threshold for the specified duration. This alert has per cluster, per (cache) service, per cache and per (cache) tier overrides. This alert appears in the "Other" Category when triggered. A new alert - OcCacheRateTotalGetsHigh has been added. This alert will trigger when the rate of cache gets goes above the specified threshold for the specified duration. This alert has per cluster, per (cache) service, per cache and per (cache) tier overrides. This alert appears in the "Other" Category when triggered. A new alert - OcCacheRateCacheMissesHigh has been added. This alert will trigger when the rate of cache misses goes above the specified threshold for the specified duration. This alert has per cluster, per (cache) service, per cache and per (cache) tier overrides. This alert appears in the "Other" Category when triggered. A new alert - OcCacheRateStoreReadsHigh has been added. This alert will trigger when the rate of cache store reads (load operations) goes above the specified threshold for the specified duration. This alert has per cluster, per (cache) service, per cache and per (cache) tier overrides. This alert appears in the "Other" Category when triggered. A new alert - OcCacheRateStoreWritesHigh has been added. This alert will trigger when the rate of store writes (store and erase operations) goes above the specified threshold for the specified duration. This alert has per cluster, per (cache) service, per cache and per (cache) tier overrides. This alert appears in the "Other" Category when triggered. These alerts are disabled by default as appropriate threshold values will vary by installation an will need to be set accordingly.

20878: Cache activity Alerts enabled as EM key metrics

New Cache Activity Alerts are available as Key Metrics to monitor cluster health based on excessive cache activity. The new Alerts are of CI-TYPE OC-CACHE, and monitor cache activity. CI-TYPE OC-CACHE has indices that represent (coherence) Cluster, (Cache) Service, Cache (Name) and Tier (front or back as appropriate). The Top Level (Level 0) Cache Key Metric Alerts are as follows The OcCacheRateTotalPutsHigh Alert sets the threshold for the (Cache) Rate Cache Puts metric. The OcCacheRateTotalGetsHigh Alert sets the threshold for the (Cache) Rate Cache Gets metric. The OcCacheRateStoreReadsHigh Alert sets the threshold for the (Cache) Rate Cache Misses metric. The Top Level 1 Cache Key Metric Alerts are as follows The OcCacheRateStoreReadsHigh Alert sets the threshold for the (Cache) Rate Store Reads metric. The OcCacheRateStoreWritesHigh Alert sets the threshold for the (Cache) Rate Store Writes metric. These alerts are disabled by default as appropriate threshold values will vary by installation and will need to be set accordingly.

Solace

20791: Kendo grid enabled for SOLMON tables

Support for the "web grid" has been added to all tabular displays in the Solace solution package. For the details on this new capability, see the release note for MTL 20185.

TIBCO ActiveSpaces

20583: New columns that enable correlation of AS Usage with JVM and Host metrics

Additional columns (HostAddress, HostPort, ProcessID, and ProcessName) have been added to the TasMembers cache and All Members tabular display. This data allows this cache to be "joined" with the HostProcesses and HostNetwork caches, or the VmwVm* caches in order to correlate host and process data with ActiveSpaces members.

20723: TASMON alerts no longer show wrong metaspace information.

When monitoring multiple ActiveSpaces metaspaces, the TASMON data adapter mistakenly associated each cluster member with all monitored metaspaces, causing the TasMembers cache to contain #metaspaces * #members rows, and erroneous rows in the "All Members" tabular display. Another consequence was invalid CI-Type indexes in alerts (ie, an alert that indicated member x in metaspace y, when x was clearly not a member of y). The TASMON datasource now correctly manages member data by metaspace.

20752: Collect additional metrics for space (space status, whether member is a manager

A new data element, "spaceState", has been added to the TasSpaceStatistics cache, "All Spaces Table", and "Space Summary" displays. Valid values of space are "INITIAL", "INVALID", "LOADING", "READY", "RECOVER", and "SUSPENDED". A new data element, "ManagementRole", has been added to the TasMembers cache, "All Members Table", and "Member Summary" displays. Valid values are "MANAGER", "MEMBER", and "NO_ROLE".

20775: New data adapter for ActiveSpaces

Previous versions of the Tibco ActiveSpaces solution package (tasmon) used the admin API to collect metrics. The results returned by this API are identical to the admin command-line interface, and consists of text blobs that must be parsed by the RTView adapter. The adapter has been re-written to more efficiently collect data by connecting to the metaspace as a client and browsing the system spaces. This approach has an additional benefit in that the adapter is more robust, since it is not affected by format changes in the admin text blobs that randomly occur with each release of ActiveSpaces.

20795: New Use Rates checkbox added to summary displays

A "Use Rates" control has been added to each summary display. This control switches the displayed trends from deltas (ie, counts of gets, puts, etc, per interval) to rates (ie, gets per second, puts per second, etc.).

20797: CapacityPerSeeder support

This enhancement provides support for monitoring the memory utilization of each space by seeder. CapacityPerSeeder has been added to the metrics collected for spaces (see the TasSpaceStatistics cache). A corresponding alert (TasMemberSeederCapacity) can be raised when then number of entries in a space exceeds the % utilization set for each seeder (ie, # entries for member divided by CapacityPerSeeder times 100). However, CapacityPerSeeder must be set when the space is defined (see ActiveSpaces documentation). If not set, CapacityPerSeeder defaults to -1 (not available) and the alert cannot be used. This Detailed statistics collected from ActiveSpaces results in (#members * #spaces) rows of data in the TasMemberStatistics cache. In some customer deployments, this data volume can easily scale to levels exceeding the ability of EM to maintain this data in cache and the history database. Hence, beginning in EM 2.3, history has been disabled for the TasMemberStatistics cache, and a new TasSeeders cache has been introduced with structure identical to TasMemberStatistics. This makes it possible to store history at a reduced level for space seeders only. History for seeders can be enabled by setting the $TAS_SEEDERS_TABLE substitution in tasmon\conf\rtvapm.tasmon.properties. Be certain that you really need this level of detail and have available database capacity before enabling this feature. The TAS-MEMBERBYSPACE CI-TYPE is disabled for the default EM project configuration. This type is useful in the Key Metrics module when the volume of data (~ (#members * #spaces)) is manageable. This capability can be enabled by uncommenting the definition in central.properties.

20798: New Alert to indicate space is not READY

A new alert (TasSpaceState) is now available to indicate when a space is not in the "READY" state.

20852: LD_LIBRARY_PATH added to miscmon's custom_setup.sh

For linux systems, the Tibco ActiveSpaces client API used by the tasmon datasource requires that LD_LIBRARY_PATH be defined in the environment. If this variable is undefined, an RTView dataserver will throw exceptions when it attempts to load the necessary ActiveSpaces libraries. Hence, LD_LIBRARY_PATH is now included in the custom_setup.sh script for the miscmon dataserver. This script must be edited to set the correct path as part of the RTView EM installation procedure.

TIBCO BusinessEvents

19884: Deleted stylesheet override for buttons

The button styles on the Inference Summary and Node Summary displays were updated for consistency with other displays.

20782: Enhanced TBEMON to work for cases where no backing store is used

For BusinessEvents configurations that do not use a backing store, no mbean is created by the BE engines for backing store statistics. As a consequence, the TbeBackingStore cache will not contain any rows for the cluster, which ultimately results in no summary data for the cluster (ie, a missing row in the top level display for "TIBCO BE Clusters"). TBEMON now properly handles the case where the backing store mbean is missing.

TIBCO EMS

19283: sample.properties now includes reference to jms-2.0.jar (for EMS 8)

The new jar jms-2.0.jar needed to connect on EMS 8 has been included in the sample.properties file. This addition will allow users to automatically connect with EMS 8 seamlessly.

20547: Overrides can now be set for Server alerts on inactive servers

A bug that prevented setting alert overrides on inactive servers has been fixed. The alerts affected were the following: EmsServerConnectionCountHigh, EmsServerOutMsgRateHigh, EmsServerPendingMsgsHigh, EmsServerRouteState, EmsServerMemUsedHigh, EmsServerInMsgRateHigh, EmsServerConnectionCountHigh, and EmsServerStaleData.

20555: Overrides can now be set for Queue and Topic alerts on inactive servers

It is now possible to set overrides on EMS Queues and EMS Topics coming from inactive EMS Servers. The alerts that have been fixed are the following: - EmsQueueProviderIdleTimeHigh - EmsQueuesConsumerCountLow - EmsQueuesInMsgRateHigh - EmsQueuesOutMsgRateHigh - EmsQueuesPendingMsgsHigh - EmsQueuesProducerCountHigh - EmsQueuesProducerCountLow - EmsTopicProviderIdleTimeHigh - EmsTopicsConsumerCountLow - EmsTopicsInMsgRateHigh - EmsTopicsOutMsgRateHigh - EmsTopicsPendingMsgsHigh - EmsTopicsProducerCountHigh - EmsTopicsSubscriberCountHigh

20729: EmsServerAsyncDBSizeHigh alert description improved

The description of the EmsServerAsyncDBSizeHigh alert has been updated to explicitly declare the units of the metric associated to the alert.

20737: Up arrows now go to correct display from all queues|topics.

On the EMS Monitor All Topics Heatmap and All Queues Heatmap displays, the up-arrow control now goes correctly to All Servers Heatmap.

20784: Added caches for in/outbound message counts and bytes

Three new optional caches have been added to EMSMON: EmsServerInfoExt, EmsQueuesExt, and EmsTopicsExt, which collect and store into history the inbound / outbound message counts and bytes. By default, these caches are not storing data into history. To enable these caches from store data into the RTV_HISTORY database, add the following lines to sample.properties: collector.sl.rtview.sub=$EMS_SERVERINFOEXT_TABLE:EMS_SERVERINFOEXT collector.sl.rtview.sub=$EMS_QUEUESEXT_TABLE:EMS_QUEUESEXT collector.sl.rtview.sub=$EMS_TOPICSEXT_TABLE:EMS_TOPICSEXT

20787: Enhanced navigation of queue and topic displays

The navigation of EMS Destinations have been improved by unfolding EMS Queues and EMS Topics into two new menu sections. Each section contains the following five displays: 1. All Queues|Topics Heatmap The heatmap can be filtered by EMS Queue|Topic pattern across all EMS Servers. Also Topic Count and Queue Count have been split into Filtered Count / Total Count. 2. All Queues|Topics Table The table of all EMS Servers or just one EMS Server from the former All Queues|Topics for Server with Topic Count and Queue Count as previous display. 3. All Queues|Topics Summary Provides current metrics about Inbound, Outbound, and Pending Message rates and totals as well as historical trend graphs for all topics in the selected EMS Server for Pending Message Count and Inbound|Outbound Message Rate. 4. Single Queue|Topic Summary This display is the former EMS Destinations->Single Queue|Topic Summary. It now has enhanced navigation through the ByServer button to the Single Queue|Topic By Server display. 5. Single Queue|Topic By Server This display is the former EMS Destinations->Queue|Topic Detail By Server. It now has enhanced navigation through the Summary button to the Single Queue|Topic Summary display.

20822: Metrics asyncDBSize and syncDBSize have been added as 2nd Level Key

The metrics asyncDBSize and syncDBSize have been added as 2nd Level Key Metrics for EMS Servers. These metrics are associated to the EmsServerAsyncDBSizeHigh and EmsServerSyncDBSizeHigh alerts respectively.

20868: Fixed bug in EmsServerAsyncDBSizeHigh alert

A bug that prevented EmsServerAsyncDBSizeHigh alert from being executed when the EMS Server State was not Active has been fixed. Also, the unit of this alert alert has changed to bytes to conform the requirements of usage as a RTView EM Key Metric alert.

TIBCO Hawk

19488: WAR files created for hawkmon

HAWKMON was updated to include war files, as per solution package standards.

VMWare vSphere

20857: VMWMON now able to return more than first 100 virtual machines

The vSphere 5.5 API now enforces paging for query results. The previous vmwmon data adapter expected all objects to be returned in a single batch, so it considered the query complete when the first page of (100) results was retrieved. The adapter now loops to retrieve all of the pages in a query.

Version 2.2.0 Release Notes

Alerts

20639: Restrict number of chars user can enter for comments

EM has been enhanced with a new property, sl.rtview.alert.commentlimit, to limit the number of characters it will store in the Comments field of the Alert table. In previous releases, new comments were appended to the existing contents of the Comments field with no limit on the amount of text. This caused problems for alert persistence and alert history if the Comment field became longer than corresponding database field could handle. For this enhancement, the order of the comments has been reversed so that new comments are added before existing contents in the Comments field. If the sl.rtview.alert.commentlimit is greater than 0 and a new comment is added to an alert, the content of the Comments field will be trimmed by removing characters from the end of the contents if necessary to stay under the limit. By default, this feature is disabled and the Comments field will grow unbounded as new comments are added. To enable the limit, set the sl.rtview.alert.commentlimit property in conf\emcommon.properties under your project directory to a value greater than 0. This property should be set to the same value for all servers. This limit is enforced in the Set Owner and Comments dialog which is accessible from the Annotate button on the Alert Table. Note that the UI limits the user to 100 characters less than the sl.rtview.alert.commentlimit value to allow for the timestamp and user name that is added to the comment. This character limit includes non-visible characters such as returns and spaces. Persisted alerts with comments from a previous versions will have mixed order on the Comments contents. It will be oldest->newest for persisted comments, then newest->oldest for new comments added in this and later releases. Persisted comments from previous versions that have been persisted and are longer than the specified sl.rtview.alert.commentlimit value will be trimmed on startup.

Configuration

19202: CMDB Admin doesn't check for duplicates

The CMDB Admin display now prevents the addition of CI's multiple times to the same Service via the addition of an index. Existing users should use the following SQL to add the new index to their product database: CREATE UNIQUE INDEX "RTVCMDB_UNIQUE_INDEX" ON RTVCMDB("Owner","Area","ServiceGroup","ServiceName","CIType","CIName");

20545: Removed hostbase comments from miscmon\sample.properties

Some misleading (commented out) properties for configuring host collection were removed from sample.properties in hostbase. This file was concatenated with other sample properties from other solution packages that are by default hosted in a miscmon dataserver. Hence, the miscmon dataserver property file is now correct.

20564: RTVMGR rtview.properties simplified

The rtview.properties file under rtvapm\projects\emsample\servers\rtvmgr has been simplified.

20573: Improved startup responsiveness of viewer and thin client during startup

An unnecessary property filter (-propfilter:monitor) has been removed from the viewer, builder, and display server scripts, to improve response time at startup.

General

19897: Service Health Heatmap now filters correctly

In previous releases, the Service Summary Views->Service Health Heatmap didn't filter correctly based on the Owner/Area/Group/Service combo box values. It only filtered correctly based on drilldown. This has been fixed.

20667: Selected row now highlighted in RTView Cache Table to enable scrolling

The RTView Cache Tables display has been enhanced so that when a cell is selected in either table, the whole row is highlighted instead of just the cell.

Monitor

20158: Enhanced mouse over in History Table Statistics display

The RTView History Table Statistics display has been enhanced so that the light indicator of each row in the table is more self-explanatory. The mouse over now provides the string "Time since last update" to indicate the meaning of the value provided and the units in which it's defined (minutes).

20659: Fixed sorting on area and group/service tables

In previous releases, All Management Areas->Area Table and Multi Area Service Views->Group / Service Table were not sorted correctly. This has been fixed.

Platform Support

20536: Support added for Red Hat Linux 7

RHEL 7 is now a supported platform for RTView.


RTVMGR

18882: RTVMGR RTView Servers Data Server and Display Server displays do not populate selection lists

In previous releases, the Source and Connection combo boxes in the following displays were not populated correctly unless you navigated to one of the JVM pages first: RTView Servers->Data Servers RTView Servers->Display Servers This has been fixed.

19472: New Version Info display added to rtvmgr

The RTVMGR has been enhanced with a new RtvServerVersions cache and Version Info page. The information in this cache and display is useful when reporting problems to SL Technical Support as it contains very detailed information about the version of each jar used in each connected RTView application. The Version Info display is accessible from the navigation tree under RTView Servers->Version Info or from the About display. The table contains one row for each RTView jar in each RTView application for which the RTVMGR has a jmx connection defined. This display combines the values for all connected RTVMGR data servers. The table contains the following columns: Source: The name of the RTVMGR source. Connection: The name of the jmx connection to the RTView application. ApplicationName - The name of the application. Ex.RTView Data Server. ApplicationConfiguration - The configuration string for the application. This string contains the main application version that corresponds to the version information that is printed to the console at startup. JarName - The name of the jar. JarConfiguration- The configuration string for the jar. JarVersionNumber - The version number for the jar. JarVersionDate - The version name for the jar. JarReleaseType - The release type for the jar. JarMicroVersion - The micro version for the jar. Expired - True if the row in the RtvServerVersions cache has expired. The expiration is set by the $jvmRowExpirationTime substitution. time_stamp - The timestamp when this information was last received. This data is queried once a minute. DataServerName - The name of the RTVMGR data server connection. Rows where the JarConfiguration does not match the ApplicationConfiguration are highlighted in teal. RTView applications running versions previous to this enhancement will only have one row in the table and will say "version info not support in this version" in the ApplicationConfiguration column. Filter the table using the controls at the top of the display: Source: Select a value to filter on the Source column Connection: Select a value to filter on the Connection column Filter Field: Select an additional column to filter on Filter Value: Enter a value to filter on in the Filter Field column Use RegEx: Set to true to use the Filter Value as a regular expression when filtering Not Equals: Set to true to show rows where the Filter Field value does not match the Filter Value. This is only available if Use RegEx is selected. Clear: Clears the Filter Field, Filter Value and Not Equals.

20574: Fixed "tomcatManagerStats77DeltaRate" function error

Previously the message "ERROR: function <tomcatManagerStats77DeltaRate>, Invalid (non-numeric) data column" would appear when Tomcat connections were not present. This has been fixed

RTView Core Functionality

20643: New option to restrict number of characters in alert comments in the alert ds

The Alert data source has been enhanced with a new Maximum Characters Allowed in Comments Field property to limit the number of characters it will store in the Comments field. In previous releases, new comments were appended to the existing contents of the Comments field with no limit on the amount of text. This caused problems for alert persistence and alert history if the Comment field became longer than corresponding database field could handle. For this enhancement, the order of the comments has been reversed so that new comments are added before existing contents in the Comments field. If the Maximum Characters Allowed in Comments Field is greater than 0 and a new comment is added to an alert, the content of the Comments field will be trimmed by removing characters from the end of the contents if necessary to stay under the limit. By default, this feature is disabled and the Comments field will grow unbounded as new comments are added. To enable the limit, set the Maximum Characters Allowed in Comments Field in the Alerts tab of the Application Options dialog to a value greater than 0. You can set it using the following property: sl.rtview.alert.commentlimit This comment limit is be available via a data attachment to alert-commentlimit to facilitate building a UI that will prevent users to enter comments longer than this limit. Note that the UI text entry limit should be set to 100 characters less than the comment limit in order to account for the time stamp, user name and hard returns between comments. Persisted alerts with comments from a previous versions will have mixed order on the Comments contents. It will be oldest->newest for persisted comments, then newest->oldest for new comments added in this and later releases. Persisted comments from previous versions that have been persisted and are longer than the specified Maximum Characters Allowed in Comments Field will be trimmed on startup.

Alerts

20664: New option to exit if alert persistence is enabled but database table is unavailable

The Alert data source has been enhanced with a new property: sl.rtview.alert.exitOnPersistInitFailed This property controls what happens when alert persistence is enabled but cannot be initialized due to a database problem or configuration issue. When exitOnPersistInitFailed is set to false (default), RTView will initialize the alerts with persistence disabled. This is the behavior in previous releases. When exitOnPersistInitFailed is set to true, RTView will exit after the persistence initialization has failed without initializing the alerts.

Commands

19854: Email command no longer garbles Japanese chars in name of attached file

The Send Email command no longer garbles Japanese and other non-ascii characters in the names of files attached to an email.

Data Sources

19563: -sqltryodbc:false is now the default RTView behavior

By default, the SQL data source will no longer attempt to make an ODBC connection to XYZ if an sql query or command is executed that references a database XYZ but there is no definition of XYZ in OPTIONS.ini. Instead the following error message will appear in the console: Undefined SQL database XYZ To force the SQL data source to attempt an ODBC connection when an undefined database is referenced as in prior releases, specify the following command-line options: -sqltryodbc:true The option can also be specified in OPTIONS.ini: sqltryodbc true or in a properties file: sl.rtview.sql.sqltryodbc=true Note that RTView will still make an ODBC connection to database XYZ if it appears in OPTIONS.ini with the odbc driver specified, regardless of the -sqltrodbc option. However, note that the ODBC driver is not supported in Java 1.8 or newer. If an ODBC connection is attempted in java 1.8 or newer, the following error messages will appear in the console: ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver (ODBC driver is not available in Java 1.8 or newer) Unable to connect to database <XYZ>: No suitable driver found for jdbc:odbc:XYZ

19928: ODBC option removed from Builder and Historian GUI

The checkbox labeled "Use ODBC Driver" has been removed from the SQL Add Database dialog in the Builder and also from the Database Options panel of the Historian UI. This change was made because the JdbcOdbc driver is no longer supported by Oracle beginning in Java 1.8 and in earlier releases it was not intended for production use. If an existing OPTIONS.ini or HISTORY.ini file contains a database connection that was saved with the "Use ODBC Driver" box checked, those connections will still work in this release if run with java < 1.8. In the new UI, such entries will now show: JDBC Driver Class Name : sun.jdbc.odbc.JdbcOdbcDriver JDBC Database URL : jdbc:odbc:<dbname> ... rather than showing the checked "Use ODBC Driver" box. But, if run with java 1.8 or newer, the following error will appear in the console for each database that is configured to use ODBC: ClassNotFoundException: sun.jdbc.odbc.JdbcOdbcDriver (ODBC driver is not available in Java 1.8 or newer)

19993: JMX handler now provides context information for operations

The API "public String getTarget()" was added to GmsRtViewJmxDataObject for use by JMX custom data handlers.

Demos

19927: ODBC connections in demos replaced with JDBC connections

The use of ODBC for the dstutorial and esphere demos has been deprecated. These demos now use JDBC HSQLDB databases.

20130: Remove Windows start menu demo launchers

The Windows Installer now produces a much smaller set of Start Menu shortcuts. The remaining shortcuts are: About Documentation Registration RTView Command Prompt Uninstaller

20644: Restricted the number of characters for alert comment in self service alerts

Set Owner and Comments dialog in the Self Service Alerts demo has been enhanced to respect the new Maximum Characters Allowed in Comments Field property on the Alert data source. If the Maximum Characters Allowed in Comments Field has been set, the field for entering comments enforces a limit of 100 characters less that the Maximum Characters Allowed in Comments Field. This is to allow for the timestamp and user name to be added to the comment. If the character limit is exceeded, an error message is displayed and the Add Comment button is disabled.

Display Server

18024: Fixed ArrayIndexOutOfBounds on Grid containing more than 1 icon type

In prior releases, the display server threw an ArrayIndexOutOfBounds exception if a display was opened containing an object grid configured with more than one icon per item, and the display was not rendered in the thin client. This is fixed.

20621: Fixed: obj_rect_il may not draw in comp grid if webLabelFlag=1

A bug in the thin client has been fixed that sometimes caused objects with the webLabelFlag property checked to not to be drawn if the objects were in a composite display inside an object grid instance.

General

19466: Version info now available via RTView Manager MBean

The RTView Manager MBean has been enhanced to support a new method, VersionInfoDetails, which returns detailed version information about the RTView application. The table will contain one row for each RTView jar in the application and contains the following columns: ApplicationName - The name of the application. Ex.RTView Data Server. ApplicationConfiguration - The configuration string for the application. This string contains the main application version that corresponds to the version information that is printed to the console at startup. JarName - The name of the jar. JarConfiguration- The configuration string for the jar. JarVersionNumber - The version number for the jar. JarVersionDate - The version date for the jar. JarReleaseType - The release type for the jar. JarMicroVersion - The micro version for the jar. This table is useful when reporting problems to SL Technical Support as it contains very detailed information about the version of each jar used in an RTView application.

RtvCacheDoc

18909: rtvcachedoc no longer generates incorrect "Expired" column

In previous releases, rtvcachedoc incorrectly included the column specified in the rowExpiredColumnName property in the generated db schemas. This only happened for caches with a blank value for the historyColumnNames property. This has been fixed.

Scripts

19835: projects\emsample\make_all_wars.bat no longer breaks the 2nd time it is run

The "make_all_wars" scripts in rtvapm/projects/emsample/webapps would give errors if run twice in succession. This has been fixed.

19952: Solaris 10 Script change not always executed

On Solaris 10 systems the rtvapm_init.sh script modifies other scripts in common/bin to use the bash shell. Under certain conditions this operation was not executed. This has been fixed.

Service Model

19251: All Service Status History graph time range fix

In previous releases, the All Service Status History graph included the current time regardless of the Time Range and End Time selected. This has been fixed.

Solution Package

20592: Fixed SQL schemas for UXMON & GFMON

The database schema files (dbconfig\*sql) for two Solution Packages, UXMON and GFMON, were previously broken due to an incorrect 'Expired' column. This column has been removed. The GFMON Sybase schemas were also updated to explicitly set columns to NULL where appropriate. Users who have successfully worked around these bugs in the schemas and have been storing data should not need to make any changes to their existing tables.

Oracle Database

20055: New alert for tablespace utilization

OraDatabaseTablespaceUsedHigh alert has been added to the Oracle database monitoring package. When enabled, an alert will be generated when the tablespace utilization exceeds a specified threshold.

Oracle Weblogic

20617: Removed duplicated custom function ScaleAndFormatBytes

A duplicate custom function to format up to the highest unit memory values has been removed.

20654: Single Server directory page now navigates to correct JVM Summary display

The "JVM Summary" drilldown from the Single Server parent node now loads the correct display.

TIBCO ActiveMatrix

20006: "Process CPU Percent" column removed from "All Nodes Table" and "Node Summary" views

Process % CPU was available in ActiveMatrix 2.3, but this data was removed from the internal metrics data for ActiveMatrix 3.x. Hence, the "Process CPU Percent" column has been removed from the "All Nodes Table" and "Node Summary" views. Process CPU is still available in the caches and is accurate for version 2.3, but is zero for ActiveMatrix 3.x installations.

20010: Corrected stats for count of events in 5 minute interval

Previously the Service Summary and Service Node Summary displays for Tibco ActiveMatrix displayed counts per collection interval rather than counts per last 5 minutes when the "Statistics for Last" selector was set to the 5 minute scale. This has been changed to display the actual number of hits and faults in the last 5 minutes (rolling average updated each collection interval).

TIBCO ActiveSpaces

20633: Support ActiveSpaces 2.1.5

The Tibco ActiveSpaces monitor has been tested and validated for use with ActiveSpaces version 2.1.5.

TIBCO BusinessEvents

19372: Add All Nodes Heatmap

An "All Nodes Heatmap" has been added to the Tibco Business Events Monitor solution. Either all nodes or the inference or cache nodes can be displayed for a selected cluster or all clusters. The following features may be of particular interest. 1. For clusters with a large number of inference nodes, either "Total Rules Fired" or "Received Events Rate" as the selected color metric can show that the load is balanced across the cluster. 2. When the Color Metric is "Alert Severity" and the TbeClusterMalformed alert is enabled, problems with cluster formation are easily seen.

19435: Sender/receiver capability implemented

Remote collectors and data aggregators (senders and receivers) are now supported by the Business Events solution. Multiple dataservers can be configured to monitor BE clusters and forward their current caches to a central dataserver that manages history and display functions. For RTView EM users: Out of the box, RTView EM provides a simple demonstration of this functionality, as shown by the following commands: cd projects\emsample rtvapm_user_init.bat cd servers Set up a sl.properties file in the miscmon folder. at a minimum it must have the connection properties to a demo BE cluster; For example, collector.sl.rtview.jmx.jmxconn=new51Cache 192.168.2.14 58700 URL:- - - 'false' collector.sl.rtview.cache.config=tbe_cache_source_be5.1_cacheagent.rtv $tbe_conn:new51Cache collector.sl.rtview.jmx.jmxconn=new51Inf 192.168.2.14 58701 URL:- - - 'false' collector.sl.rtview.cache.config=tbe_cache_source_be5.1_inferenceagent.rtv $tbe_conn:new51Inf Launch the EM processes as follows: start_rtv central start_rtv miscmon dataserver -receiver start_rtv miscmon dataserver -properties:sl -propfilter:sender This example starts a single receiving dataserver and a single collector/sender on the same host. If additional senders are deployed on remote hosts, override the following settings in rtvapm.miscmon.properties to specify the host where the receiver resides ($rtvAgentTarget). Set $rtvAgentName to identify the source of data seen in the receiver's caches (ie, the name of the host where the sender is deployed). sender.sl.rtview.sub=$rtvAgentTarget:'localhost:3972' sender.sl.rtview.sub=$rtvAgentName:MyMachineName

20011: High availability option configured

Missing files to configure High Availability for TBEMON have been added.

TIBCO BusinessWorks

19293: Cleaned up incorrect symbols appear in Heatmap mouseover

NaN special-character symbols have been replaced in the mouse over of All Engines Heatmap display with a 0 value.

19961: BW Engine heatmap box size adjusted to accomodate outliers

In previous versions, the heatmap on the "BW Engine Summary" screen would fail to show a box for each process in certain cases. The box size was proportional to the number of process instances that had been created for a given process. Hence, boxes would be missing when either a) one process creation count was so large that it crowded out the other process creation values, or b) one or more processes had a zero creation count. The box size is now proportional to the log(+1) of the creation count, so a box should now be visible in all cases to support visualization and drill-down.

20020: Prevent Hawkmon from filtering out blank Processor fields

Under some conditions Hawkmon would fail to correctly identify Hawk agents, which could then affect other parts of the product such as Servers in BWmon. This occurred if the Hawk data contained a blank value for the getCpuInfo Processor field . This has been corrected.

20052: Tibco Spotfire reports added for Engine Metrics

An example Tibco Spotfire dashboard is available to run for both MySQL and Oracle SQL databases. The dashboard can report on historical data for BW Engine Metrics and can be run using Tibco Spotfire Desktop version 7.0. The dashboards and associated SQL custom query text files are located in the rtvapm/bwmon/projects/reports/Spotfire directory. They include: bw_engines_mysql.dxp (for MySQL) bw_engines_mysql.txt bw_engines_sql.dsp (for Oracle SQL) bw_engines_sql.txt For more information, please refer to the User Guide.

20425: BW Process Alerts now associated with BW-PROCESS CI Type

BW Process and BW Activity alerts have been associated to the BW-PROCESS CI Type.

20616: Odd square shape drawn atop center ListBoxes of "Single BW Activity Summary"

Under some circumstances the BW Monitor Activity Summary display would show some extraneous objects when displayed in the thin client. These objects are small rectangles (about 4 X 2 pixels) drawn on top of the selector combo boxes. This has been fixed.

20702: BW6 Support

The BW solution has been enhanced with the ability to monitor TIBCO ActiveMatrix BusinessWorks 6 Applications and AppNodes. The BW6 solution displays show current and historical resource usage and error states across BW Applications and down to the level of BW Processes and Activities. RTView Alerts are implemented on key metrics at the Application, AppNode, and Process levels and are incorporated into the displays. The following displays are added to the navigation tree of the standalone solution: BW6 Applications All Applications Heatmap All Applications Table Single Application Summary BW6 AppNodes All AppNodes Heatmap All AppNodes Table Single AppNode Summary BW6 AppSlices All AppSlices Heatmap All AppSlices Table Single AppSlice Summary BW6 Processes All Processes Heatmap All Processes Table Single Process Summary BW6 Hosts All Hosts Heatmap All Hosts Table The layout of the displays follows RTView standards and is similar to BW(5)mon. In each section of the tree the table view shows all the data, allowing for filtering, and the heatmap allows you to select the metric for the color scale. The summary views show current and historical metrics for a single instance. Process and Activity metrics are essentially unchanged from BW(5) and AppNode metrics are similar to BW(5) Engine metrics. BW6mon adds the viewpoint of Application and AppSpace. Process metrics, including such things as creation and completion, exec and elapsed times, are summarized for the application and also for each slice of the application on multiple appnodes. Specifically: BW6 Applications Shows Applications and AppSpaces across BW6 Domains with Process metrics totaled by Application. The summary display also shows the AppNodes of the deployment and Process metrics totaled by AppNode. This is useful to see the deployment and load balancing of the Application in current and historical time. BW6 AppNodes Shows ApppNodes and their resource usage in terms of internal JVM memory and host CPU. This is useful because the AppNode performance is dependent on both internal and external factors and sometimes they interact. BW6 AppSlices The AppSlice is the part of an Application running on a specific AppNode when the Application is deployed to multiple AppNodes. These displays show process metrics totaled by Application and AppNode. this is useful to see how the application is distributed and how each part of it is peforming. BW6 Processes Very similar to the BW(5) Process metrics, including the addition of Delta and Rate columns for many metrics. These displays are useful for a closer look at the performance and resource usage of specific Processes in the Application. BW6 Hosts These displays show the health and history of the host systems running the AppNodes. BW6mon can be installed along with BW(5)mon and an RTView data server can include one or the other or both according to the user's configuration. The configuration is similar to BW(5)mon, using Hawk for data collection. =========================== Limitations in this release: =========================== TIBCO ActiveMatrix BusinessWorks 6.2.1 has issues with the Hawk microagent that impose the following limitations on BW Monitor. (1) Activity statistics are not completely implemented in Hawk. Activity-level metrics and displays are not available in this release of BW Monitor. (2) Process statistics are not completely implemented in Hawk. Min/Max/Average Elapsed Time will be zero. (3) Some statistics are not implemented in Hawk on Windows. This release of BW6mon does not support TIBCO ActiveMatrix BusinessWorks 6 on Windows. (4) The bwadmin command "enablestats" command does not enable statistics in the Hawk microagent. You must enable process statistics for your BW6 applications via hawk, e.g. using the Hawk Display tool.

20759: Removed “Invalid column name” startup errors

When BW Monitor would start up the following messages would appear one time in the log. <bwProcessDefinitionDataUnix41>, Invalid column name <bwProcessDefinitionDataWin41>, Invalid column name This did not indicate a problem and the messages have been removed.

TIBCO EMS

19618: Fixed errors with ASync/Sync DB metrics

The EMS Server Summary display has been enhanced to provide the Message Memory Pooled metric. Several labels have been improved for accuracy; - AsynDB Size now reads Async Storage - SyncDB Size now reads Sync Storage - Used % has been formatted to 2 decimal points - Added Message Memory Pooled

TIBCO Hawk

20581: Adjusted margins for tables in Hawk displays

Cosmetics (margins around tables and fields) have been adjusted for the Hawk Agent Table and Hawk Alert Table for the sake of consistency with other displays. No functional changes were made to these displays.

20624: Added buffer to HawkAgents cache to prevent missed updates

In previous versions where multiple sender dataservers forwarded copies of their HawkAgents cache to a single receiving dataserver (ie, remote collectors with a central aggregator), it was possible that the receiver could drop updates. This has been corrected by adding row buffering to the receiver.

20646: Expiration removed from the HawkAgent cache

Rows in the HawkAgents cache only update when asynchronous events like hawk alerts or onAgentAlive/onAgentExpired are received, so it is normal for rows to not update for lengthy periods. Hence, the Expired column has been removed from the HawkAgents cache and associated tabular display.

UX Monitor

20684: Packaging and documentation reorganization

The UXMON solution packaging has been changed to reduce confusion. - The UX Robot installers (.zip/.gz) are now included inside the rtvapm_uxmon_X.zip. - The "UX Robot Read Me.doc" has been removed, as this information was duplicated in the User Guide - The README.txt now refers you to the User Guide.

Version 2.1.0 Release Notes

20181: Support Tomcat 8 and TC-Server

Tomcat 8 and TC Server are now supported in RTView EM, RTVMGR Tomcat displays. To start monitoring your Tomcat 8 / TC Server instances, follow these steps: 1. Enable JMX access and set the monitoring port by following the Tomcat 8 / TC Server installation documentation. 2. Add to your sample.properties file the JMX connection information of your instances. To do so, add the following property for each instance: collector.sl.rtview.jmx.jmxconn=MY_CONNECTION <IPAddress> <Port> URL:- <user> <password> false where you should replace: - MY_CONNECTION with the name of your connection, - <IPAddress> with the IP address of the machine hosting your Tomcat instance - <Port> with the monitoring port you enabled in the previous step If JMX authentication is used replace - <user> with the username to connect to your Tomcat instance - <password> with the password to connect to your Tomcat instance Otherwise, replace <user> and <password> with a single - (dash)

Alerts

19545: Fixed error "cannot find $alertSourceList" in viewer and thin client logs

In previous releases, the viewer and thin client log files contained this error after a user navigated to the RTView Alert Table view: ERROR: GmsRtViewXmlDs -- $alertSourceList not found. This error has been fixed.

Monitor

20537: New properties to limit Display Server table cells

The Monitor has been enhanced to support 3 new properties to limit the amount of data that is passed from the Display Server to the browser for tables. The following properties have been added to common\conf\rtvapm.properties: cellsperpage - This limits the number of cells (columns*rows) that will be displayed in a table object. This avoids the sluggish performance, timeouts, and out-of-memory exceptions that might otherwise occur from processing and transmitting all of the rows at once Table objects with more than the specified number of cells are paged. This means that the Display Server only sends the rows that are visible plus a few rows before and after the visible rows. As the user scrolls, the new rows are requested from the Display Server. This results in a small delay between the scroll action and the data showing up in the table. The default is 20000. cellsperexport - This limits the number of cells (columns*rows) that will be exported for the Export to Excel and Export to HTML operations. The default is 40000. cellsperreport - This limits the number of cells (columns*rows) that will be exported for the Export to PDF operation. The default is 20000. For all of the new properties, a value of less than 1000 will disable the property. Values larger than the defaults may result in slower performance, timeouts and/or out-of-memory exceptions when interacting with tables in displays in the thin client.

RTView Core Functionality

Data Historian

20637: New option to limit length of strings from cache table stored in db

The historian has been enhanced to support a limit on the length of a string from a cache table column that it will store in the database. If a string is longer than the specified limit, it will be truncated to the limit before it is stored in the database table. This can avoid SQL exceptions encountered when the length of a string exceeds the capacity of the column's data type (for example, 4000 characters in an VARCHAR2 column in Oracle). The limit is specified by a new property named stringColMaxLen. This can be specified in HISTORY.ini as follows: stringColMaxLen 3500 It can also be specified on the command line or a properties file. By default the property has no value, so no limit is enforced.

Data Server

20596: Fixed duplication in connection error messages

A bug has been fixed which caused duplication of log messages when a client lost its connection to a data server.

Data Sources

20589: Improved timezone support

The Round Robin Database (RRD) data source now handles variations of start/stop times in different time zones.

Display Server

20582: Enable mouse cursor to change appearance when hovering over composites

If a composite object has its drilldownTarget set, then in the thin client the "hand" cursor will appear when the mouse is over the composite. This is consistent with the behavior of other objects that have a drilldownTarget.

20623: Table no longer fails to populate when cellsperpage is smaller than visible cells

A bug in the display server has been fixed which sometimes caused table cells in the thin client to always contain "..." if the cellsperpage property was set. Typically this occurred if the cellsperpage value was small (in the range of 1000 to 2000) and a table with many columns was opened. It was unlikely to occur with a typical cellsperpage value of 10000 or more. The problem is fixed for all cellsperpage values. As before, a value less than 1000 is ignored.

Object Library

20638: New property to limit text entered into text area control

The text area control (obj_c1textarea) has been enhanced to enforce an optional maximum character limit. (The text field control, obj_c1textedit, has supported this feature for several releases). The text area control has one new property in the Data category: maxCharacters - The maximum number of characters that will be submitted to the command associated with the text area. If no value is specified there will be no limit on the maximum number of characters. By default, there is no limit. Note that the limit does not restrict the length of the text in the control, only the length of the text that is sent to the control's command. See below. The limit is checked whenever the control executes. If the executeOnFocusLostFlag is selected, the control executes whenever the control loses focus. If the executeOnKeyStrokeFlag is selected, the control also executes whenever a key is pressed while the control has focus. If the limit is exceeded, the control's actionCommand is not executed. The text area control has two new properties in the Interaction category: inputValidVarToSet - Attach to a local variable. This variable will be updated when the control executes with a value of 1 if the maxCharacters limit is blank or the text is less than or equal to the maxCharacters limit, or updated with a value of 0 if the text length exceeds the maxCharacters limit. invalidInputMsgVarToSet - Attach to a local variable. This variable will be updated when the control executes with an error message if the text length exceeds the maxCharacters limit, or updated with an empty string if the text length is less than or equal to the maxCharacters limit.

Solution Package

IBM DB2 Database

20593: Corrected Sybase SQL schema definitions for datetime columns

The SyBase sql schema has been updated to account for the non-index date fields that can be set to null.

TIBCO ActiveSpaces

20598: TAS-METASPACE CI-Type change

A change was made to a configuration file to support proper indexing of TAS-METASPACE CI-Types. The previous configuration yielded similar results when browsing CMDB screens, so no obvious changes in behavior will be evident.

20599: CMDB screens now drill down to table display instead of summary display

The drill-downs from CMDB screens have been changed to the summary screens for Active Spaces CI-Types, which is consistent with drill-downs to other packages. Previously, the drill-downs for ActiveSpaces CI-Types took you to the corresponding tabular display.

TIBCO EMS

19162: Dataserver selection problem fixed

A bug that prevented the correct selection of the EMSMON dataserver under RTView EM on some displays has been fixed. The displays are: - "Admin Metrics" (ems_admin_metrics.rtv) - "All Routes Table" (ems_allroutes_table.rtv) - "All Other Info Server" (ems_otherinfo_forserver.rtv) - "Server Route Table" (ems_server_route_table.rtv) - "All Servers Topology" (ems_server_topology.rtv)

19495: Removed receiver count from All Topics Heatmap drop-down

Receiver count has been removed from the drop down in the All Topics Heatmap display.

19496: Consumers added to the mouseover of All Queues Heatmap

Consumers count has been added to the mouse over in the All Queues Heatmap display.

19546: Fixed "serverActivity3WithSeverity" function error

The error at startup: ERROR: function <serverActivity3WithSeverity>, Invalid left column name(s) <URL> has been fixed.

19558: All Servers Grid display readability improved

The visibility of the EMS Server state in the All Servers Grid display has been improved. Previously it was hard to read against the background color.

20050: Tibco Spotfire reports added for Server/Queue Message Metrics

With this release of EMSMON, Tibco Spotfire reports are available for both the Server Message Metrics and the Queue Message Metrics. This initial set of reports can be generated against historic data stored in either Oracle SQL or MySQL databases. The reports can be run using Tibco Spotfire Desktop version 7.0. The dashboards and associated SQL custom query text files are located in the rtvapm/emsmon/projects/reports/Spotfire directory. They include: Server Message Metrics: ems_serverinfo_mysql.dxp (for MySQL) ems_serverinfo_mysql.txt ems_serverinfo_sql.dsp (for Oracle SQL) ems_serverinfo_sql.txt Queue Message Metrics: ems_queues_mysql.dxp (for MySQL) ems_queues_mysql.txt ems_queues_sql.dxp (for Oracle SQL) ems_queues_sql.txt For more information, please refer to the User Guide.

20054: Expired bridges removed from "Bridges, Users, Ports" display

Expired bridges are being differentiated from unexpired by highlighting the expired rows and displaying its Expiration flag. As prevously, expired bridges will be deleted from the cache after 1h.

20081: New alerts for message latency

New two alerts, EmsQueueMsgLatencyHigh and EmsTopicMsgLatencyHigh, have been created. These alerts are executed when the time to process the pending messages based on current outbound message rate for a EMS Queue or Topic have reached their maximum. The units of these alerts are seconds. The default thresholds for both alerts for warning and alert are 60 and 80, respectively.

20134: New alert for async DB size

The alert EmsServerAsyncDBSizeHigh has been added to EMS Monitor. It will trigger when an EMS server's async DB size exceeds the warning or alarm thresholds. The default thresholds are 50 MB and 100 MB respectively.

20135: EmsConsumerStalled alertdef override now useable

The EmsConsumerStalled alert has been fixed to enable alert overrides.

20141: New alert for pending message count

A new alert, EmsServerPendingMsgSizeHigh, has been created. This alert is triggered when the size of the pending messages stored on the EMS Server has reached its maximum. The unit of this alert is KB and the default thresholds for warning and alert are 60 and 80, respectively.

20233: Fixed typos in Consumers display

Typos in Ems Consumers for Server have been fixed.

20585: Corrected units in EMS Server Summary

Memory units have been fixed to show KB instead of kB.

TIBCO Hawk

20566: Hawk Alert time now mapped to the alert event's time

In previous releases, the HawkAlerts cache Time was not mapped to the Hawk alert event time, but instead used the time that RTView received the Hawk alert event. This has been fixed so that the Hawk alert event time is used instead. Note that the Time on the HawkAlerts cache is also used as the Last Update Time on the HawkAlert alert so that has been fixed by this change as well. In previous releases, the HawkAlerts cache often missed alert updates, especially at startup. This has been fixed for most cases. There are 2 cases where the HawkAlerts cache sill may not be in sync with the Hawk Alerts on an agent (these are noted in the PAL for task 20568: 1. If RTView does not receive any updates for a HawkAlert for the amount of time specified in $rtvHawkAlertClearTime + $rtvHawkAlertDeleteTime (defaults to 10 days + 1 hour), it is removed from the HawkAlerts cache. 2. When using a sender to update the HawkAlerts cache, any events that occur when the sender is running but the receiver is not will be missed. To fix this, restart the sender after any restart of the receiver.

20567: Added expiration to avoid orphaned alerts

In previous releases, it was possible to get in a state where a HawkAlert alert would be active with no corresponding row in the HawkAlerts cache. These orphaned alerts would never clear. This has been fixed. Now, HawkAlert alerts are cleared due to expiration after they have not received updates for 10 days. This matches the time when a row that has not received updates will be removed from the HawkAlerts cache. This time period can be configured using the following property, which controls both the alert expire time and the cache row delete time: sl.rtview.sub=$rtvHawkAlertDeleteTime:864000

20579: Hawk Alert row expiration time configurable

The HawkAlerts cache has been enhanced to make the row expiration time configuration. In previous releases, a row would be deleted from this cache if it did not receive an update for 10 days. This time period still defaults to 10 days but is now configurable using the following property: # Default time to remove expired Hawk Alerts from the cache sl.rtview.sub=$rtvHawkAlertDeleteTime:864000

20605: Filters added to HawkAlerts cache

Previous releases of EM's Hawk Monitor did not handle high-frequency Hawk alerts gracefully. Properties (substitution variables) have been added to control the manner in which Hawk alerts are applied to the HawkAlerts cache. This change reduces the rate at which high frequency alert data is displayed in the "Hawk Alerts Table". The cases addressed by this change include the following: 1. Alert text changes continuously - for example, it contains the value of some metric (eg, cpu%). In this case, you would want to specify to just ignore updates. 2. Alert text includes a repeating set of discrete values - for example duplicate serial number errors where the alert text contains host urls. We don't want the alert cache entries to stop updating altogether or they will expire, so a parameter is needed to allow occasional updates through. The rows going into the HawkAlerts cache are now pre-processed to ignore or append text updates according to these new subs: $rtvHawkAlertTextToIgnore - set to a regex value that will match AlertText to ignore. This will cause all updates to the alert text for those alerts to be ignored until the amount of time specified in the $rtvHawkAlertTextUpdateTime sub $rtvHawkAlertTextToAppend - set to a regex value that will match the AlertText content that you want to append. This will cause all unique updates to the alert text to be appended to the previous alert text value. All unique alert texts will be appended until the value specified for the $rtvHawkAlertTextToAppendMax sub is met. Then a ... will be added to the end of the alert text to indicate that other alert text values were not appended. The delimiter between AlertTexts is |\n ad can be changed with the $rtvHawkAlertTextToAppendSep sub. $rtvHawkAlertTextToAppendMax - defaults to 0 which means an unlimited number of AlertTexts will be appended. By default, the string "|\n" is used as the separator between alert text values. Change this using the $rtvHawkAlertTextToAppendSep sub. The $rtvHawkAlertTextUpdateTime also applies to this case. $rtvHawkAlertTextUpdateTime - set to an amount of time to ignore updates for matches of the above 2 subs, 3600 default. Note that the $rtvHawkAlertTextUpdateTime sub should not be set to 0 - you want it to update occasionally so the alert won't expire. Examples: collector.sl.rtview.sub=$rtvHawkAlertTextToIgnore:<some string> collector.sl.rtview.sub=$rtvHawkAlertTextToAppend:<some string> collector.sl.rtview.sub=$rtvHawkAlertTextToAppendMax:5 #collector.sl.rtview.sub=$rtvHawkAlertTextToAppendSep:--> collector.sl.rtview.sub=$rtvHawkAlertTextUpdateTime:120 The recommended place to add these properties is the connection properties file for the applicable dataserver(s).

Version 2.0.0 Release Notes

Alerts

20198: Error messages and failure of custom alert filters with some configs

In previous releases, the Custom Alert Filter did not work when EM was configured to access the ALERTDEFS database via the Config Server instead of directly in the Central Alert Server. Even if no Custom Alert Filters were defined, the Central Alert Server log would contain errors about the ALERTDEFS database connection when running in this configuration. This has been fixed by using a substitution for the dataserver running ALERTDEFS database. If the Central Alert Server is configured to connect to the ALERTDEFS database directly, no changes are needed to take advantage of this fix. If the Central Alert Server is configured to access the ALERTDEFS database via the Config Server, uncomment the following line in conf\emcommon.properties: #AlertClient.sl.rtview.sub=$rtvAlertFilterDataServer:CONFIG_SERVER


20199: Alert cache history storage settings changed

The history settings for the RtvAlertTable cache in the Central Alert Server have been enhanced. In previous releases, 2 weeks of history were kept in-memory and 2 days were kept in the database. It now keeps 2 weeks in the database and 1 hour in memory. These settings can be changed using the following properties: # Sets the in-memory limit to the number of seconds specified (30 minutes in this example) AlertServer.sl.rtview.sub=$rtvAlertHistoryTimeSpan:1800 # Sets the database limit to the time period specified (1 hour in this example) AlertServer.sl.rtview.sub=$rtvAlertCompactionRules='1h -'


20228: Row count and enhanced filter added to Alert History display

The Alerts History Table display has been enhanced with a new row count field and better filtering. To filter the table, select a table column from the Field Filter combo box. In the Search Text field, enter the (case-sensitive) string to search for in the selected Field Filter. Press <enter> to apply the filter. The Clear button clears the Field Filter and Search Text fields. The Regex button behaves as it did before: it toggles the Seach Text field to use Regular Expressions for filtering. The Count label shows 2 values: the filtered row count before the "/" and the unfiltered row count after the "/".


20538: Alert history display limit changed to 20k rows

The Alerts History Table has been enhanced to set the maximum number of rows to 20,000. Previously, the display queried up to 50,000 rows from the cache, but only displayed 10,000 of those rows in the display. Now, it limits both the cache query and the table rows to 20,000.


20543: Fixed column type mismatch errors in central alert server log

In previous release, the central alert server log file occassionally contained multiple instances of the following error message: GmsTabularData.insertData(): column type mismatch This error did not indicate a real problem, but cluttered the log file. It has been fixed.


Configuration

20189: Naming convention cleanup for alert and config server connections

The JMX Connection name and the data server name for the Alert Data Server and the Config Data Server have been made consistent with other naming practices. Enforcing the match of both parameters reduces the level of indirections needed to associate JVM data with monitoring data from Data Servers.


Customization

20182: Fixed historian configuration bug in custom example

A bug that prevented history being displayed properly in the Summary display of the custom example has been fixed. Also, the validation for Connection and Bird have been fixed to allow all data sources to be validated properly.


20204: Cleanup of the custom solution package

Minor improvements have been made to the custom solution package example to improve consistency with the documentation.


General

20197: Cleanup of properties files to improve performance

Previously, several highly used properties file defined global substitutions unnecessarily. This had the effect of reducing performance in the Display Server due to excessive substitutions being included in the URL of RTView Servlets. This has been fixed.


JVM metrics

20229: JVM Memory data no longer gaps in trends received from sender

A bug that prevented correct visualization of Memory in the JVM Summary display has been fixed.


Key Metrics

20016: Key metrics added for RTVMGR

The rtvmgr solution package has been enhanced to support Key Metrics. The following Key Metrics are supported for the JVM CI Type: CPU % Memory % The following Key Metrics are supported for the TOMCAT and TOMCAT-APP CI Types: Active Sessions Accesses / sec


20023: Key metrics implemented for RTVRULES CI Types

The RTVRULES solution package has been enhanced to support Key Metrics. The following Key Metric is supported for the EM-SERVICE CI Type: Alert Impact


20025: Key metrics implemented for IBM DB2 CI Types

Key Metrics have been added to the db2mon solution package. The following Key Metrics are supported: Response Time


20027: Key metrics implemented for Host CI Types

Key Metrics have been added to the hostbase solution package. The following Key Metrics are supported: % CPU Utilization % Memory Used


20028: Key metrics implemented for IBM MQ CI Types

Key Metrics have been added to the MQMON solution package. The following Key Metrics are supported: MQ-BROKER Queue depth MQ-QUEUE Queue depth


20030: Key metrics implemented for Oracle Coherence CI Types

Key Metrics have been added to the ocmon solution package. The following Key Metrics are supported: OC-CLUSTER: Packet Loss OC-CACHE: Queue Size


20031: Key metrics implemented for Oracle Database CI Types

Key Metrics have been added to the oramon solution package. The following Key Metrics are supported: Response Time


20033: Key metrics implemented for Solace CI Types

Key Metrics have been added to the Solace solution package. The following Key Metrics are supported: SOLACE-APPLIANCE # Msgs Spooled SOLACE-VPN Connections


20035: Key metrics implemented for TIBCO ActiveSpaces CI Types

Key Metrics have been added to the TIBCO Active Spaces solution package. The following Key Metrics are supported: Gets/sec Puts/sec


20037: Key metrics implemented for User Experience CI Types

Key Metrics have been added to the uxmon solution package. The following Key Metrics are supported: Response Time


20038: Key metrics implemented for VMWare CI Types

Key Metrics have been added to the vmwmon solution package. The following Key Metrics are supported: VMWARE-VM Host CPU Usage Host Memory Usage VMWARE-HOST VM CPU Usage VM Memory Usage


20039: Key metrics implemented for WebLogic CI Types

Key Metrics have been added for WebLogic CI Types. The following metrics are supported: WLS: JVM CPU % JVM Memory % Open Sockets WLS-APP: Open Sessions


20040: Key metrics implemented for WebSphere CI Types

Key metrics for WebSphere have been added. The Websphere Server (WAS CI Type) has: Live Session Count WAS CPU % Memory Used % WebSphere Applications (WAS-APP CI Type) has: Response Time Requests / sec.


20041: Added navigation from Service Summary Views to Key Metrics

The Service Summary Views have been enhanced to allow navigation to the Key Metrics views from the navigation combo box.


20131: Key Metrics added

RTView EM has been enhanced with a new Key Metrics feature. The Key Metrics (KM) feature is an entirely new way of looking at and interpreting application health and performance data. In contrast to the traditional Alert Impact view showing your ACTIVE alerts and their impact on the overall application or service, the Key Metrics view shows how close a metric is approaching its threshold over a period of time – both before and after the alert threshold is reached. This allows you to both proactively anticipate performance problems BEFORE the alert threshold is crossed as well analyze the circumstances that led up to error conditions AFTER you got an alert. Armed with this knowledge, you an avert disasters before they happen and resolve problems faster after they happen. RTView does this by correlating the most valuable key metrics over multiple components within a service and displaying them in context with both real-time and historical data. This is valuable because health problems in one component may be caused by performance problems in another and only by viewing each of these metrics in context with one another over a period of time are you able to visually link the relationship between troubled components. It is important to note that your Alert Impact heatmaps may look very different from your Key Metrics heatmaps given that KM will indicate potential threats BEFORE they show up as alerts. There are 4 views under the new Key Metrics Views item in the navigation tree: - Service KM Heatmap - shows the current Key Metrics values in a heatmap - Service KM Table - shows the current Key Metrics values in a table - Service KM History - shows historical Key Metrics values in a status history graph - Service KM History (Alt) - shows historical Key Metrics values in a heatmap There is also a new view under Architecture, RTView KM Defs. This view shows the Key Metrics definitions for each CI. See the documentation for more information on the new Key Metrics displays. Upgrade Notes When upgrading from previous releases, perform the following steps to add KM to your project: 1. Add the following to the rtview.properties file in your central directory (In emsample, servers\central\rtview.properties): # Include km package rtvapm_package=km 2. Add the following to your navigation tree (in emsample, servers\central\ rtv_appmon_navtree.xml): <node label="Key Metrics Views" mode="" display="rtv_dir_km"> <node label="Service KM Heatmap" mode="" display="rtv_km_current_heatmap"/> <node label="Service KM Table" mode="" display="rtv_km_current_table"/> <node label="Service KM History" mode="" display="rtv_km_history_heatmap_sh"/> <node label="Service KM History (Alt)" mode="" display="rtv_km_history_heatmap"/> </node> Dependencies The KM package is dependent on the Metric Explorer package. Both must be included in your project in order for KM to work. If you are upgrading from a version previous to 1.5.0 and have not added Metric Explorer to your project, refer to the EM User Guide Upgrade Notes section for information on including it.


20163: Key metrics implemented for Amazon Cloudwatch CI Types

Key Metrics have been implemented for the acwmon solution package. The following Key Metrics are supported: Instance CPU Usage


20165: Key metrics implemented for Glassfish CI Types

Key Metrics have been added to the GFMON solution package. The following Key Metrics are supported: Service Time Request Count


20166: Detail-level key metrics implemented for TIBCO EMS CI Types

Second level metrics for the EMS Servers, Queues, and Topics have been added. These metrics are: EMS-SERVERS Msg Mem % Connections EMS-TOPICS Consumers Subscribers EMS-QUEUES Consumers


20167: Detail-level key metrics implemented for WebLogic CI Types

Detail level metrics for the WebLogic Servers have been added. These metrics are: Open Sockets Thread Total Count


20168: Detail-level key metric added for JVM CI Type

ThreadCount has been included as a Key Metric Detail for the JVM CI Type.


20176: Key metrics example added to Custom example

An example of Key Metrics has been added to the Custom Solution Package.


Navigation

20169: Service Summary View navigation cleanup

The Service Summary Views have been enhanced as follows: 1. The Service Browser display has been removed from the navigation tree and from the navigation combo box in the other Service Summary Views. This display was removed because the CI / Service Tree View under the Component Views section provides the same functionality. 2. The MX (Metric Explorer) button was moved to the right of the navigation combo box in the Service By CI Type and Service Summary Views. The functionality of this button has not changed, just the position.


Platform Support

20071: Properties now loaded from all solution packages defined

In previous releases, solution package specific properties were only loaded for one solution package even if multiple solution packages defined properties. This has been fixed.


RTVMGR

20108: New alerts TomcatActiveSessionsHigh and TomcatAppActiveSessionsHigh

Two new Tomcat alerts, TomcatActiveSessionsHigh and TomcatAppActiveSessionsHigh, have been added to alert when the number of active sessions of a Tomcat Server and a Tomcat Application reach their thresholds.


20183: JVM Operating System Cache no longer shows PhysicalMemory = 0

A bug that prevented the JvmOperatingSystem cache from correctly collecting the TotalPhysicalMemory metric has been fixed.


20190: New Jvm Thread Count High alert

A new alert, JvmThreadCountHigh, has been added. This alert fires when the number of threads exceeds the established thresholds.


20214: Process Name and PID added to Data Server display

The RTView Data Server metrics display has been enhanced to include Process Name and PID columns in the Data Server Clients table. The value that appears in the Process Name column depends on the type of client. If the client is an RTView application, then the Process Name shows the value of the PROCESS_NAME property when the app was started. If the client process was started with a standard RTView script (e.g. run_viewer, run_displayserver, etc) then the Process Name will be viewer, builder, dataserver, displayserver, or historian. For a server, a "d" at the end of the process name indicates it was started with the -daemon option. If the PROCESS_NAME property was undefined when the client process was started, then the Process Name will be RTView (the viewer), RTView Display Builder, Display Server, Data Server, or Historian, or the OEM names assigned to those applications. If the client is the viewer applet, then "applet" is appended to the name. If the client is the rtvdata or rtvquery servlet, the Process Name will be RTVDataServlet and rtvquery, respectively, or the custom servlet name that has been configured for the deployed servlet instance. The PID column shows the PID (process ID) of the client process. Typically the PID column value will appear as nnnn@hostname, where nnnn is the PID from the client's host system (as reported by jps, top, or tasklist) and hostname is the name of the client's host. If the client is the rtvdata or rtvquery servlet, then the PID will correspond to the app server (e.g. tomcat) process on the client host. The PID column may be blank if the client is unable to obtain its PID from the local operating system. The @hostname portion may be omitted if it cannot be obtained from the local operating system. The PID and Process Name columns will both be blank if the client process is running an older version of RTView that does not have this enhancement.


RTView Core Functionality

Builder

20330: Support aligning and distributing objects against objects from include files

The Builder has been enhanced to support Aligning and Distributing objects in the local .rtv file against objects in an included .rtv file. When the selection contains both objects in the local file and objects in an include file, ony the objects in the local file will move. Objects in include files can still only be edited directly in the include file.


Builder - Editing

20091: Display Data option enabled for read-only data attachments

The Builder has been enhanced so that the Display Data option is now available for read-only data attachments.


Data Historian

20019: Compaction smoothing no longer sets incorrect "run after" date

Previously, the smooth compaction option caused an an incorrect "run after" date to be set for further compaction. This could result in a small portion of data not being compacted. This has been fixed.


20067: Data retention (purging) now correctly performed after compaction/smoothing

Previously, database retention logic was incorrectly postponed after smoothing/compaction had taken place on a table. This could result in the retention of more data than specified in historian configuration. This has been fixed.


20159: Sync up data from the history cache when historian starts

The Historian supports a new option named persistInitTimeRange which affects the cache persistence feature. Normally, when the cache persistence feature is enabled in the historian, the historian begins collecting cache history data starting at the time when each data server connects. This is adequate in most situations. The persistInitTimeRange option can be used to specify a time range, in seconds, back from the current time that the historian should get cache history data from the data server. This can be useful if the historian is started sometime after the data server, so the data server has collected cache history that hasn't been sent to the historian. For example, if the data server was started an hour before the historian, then the historian could be started as follows, so that it will request an hour of cache history from the data server: run_historian -persistCaches:true -persistInitTimeRange:3600


20187: Option to perform compaction for a time range prior to "now"

An option was added to the Historian to allow for the smoothing process to only go back as far as a specified range in the form: -smoothCompactionRecent:NN Where NN is '1d' or '1w'


20254: Retention-only compaction now executed correctly

Previously the historian would fail to run compaction if the Compaction Rules consisted of a single rule that only specified a duration of Raw data (-). This has been fixed.


Data Server

20138: add ProcessName, PID columns to ClientData attrib of data server mbean

The data server's Manager mbean has a tabular attribute named ClientData which contains one row for each client connected to the data server. In this release the ClientData table has two new columns named PID and Process Name. These are intended to help administrators identify the process that corresponds to each client connection. The value that appears in the Process Name column depends on the type of client. If the client is an RTView application, then the Process Name shows the value of the PROCESS_NAME property when the app was started. If the client process was started with a standard RTView script (e.g. run_viewer, run_displayserver, etc) then the Process Name will be viewer, builder, dataserver, displayserver, or historian. For a server, a "d" at the end of the process name indicates it was started with the -daemon option. If the PROCESS_NAME property was undefined when the client process was started, then the Process Name will be RTView (the viewer), RTView Display Builder, Display Server, Data Server, or Historian, or the OEM names assigned to those applications. If the client is the viewer applet, then "applet" is appended to the name. If the client is the rtvdata or rtvquery servlet, the Process Name will be RTVDataServlet and rtvquery, respectively, or the custom servlet name that has been configured for the deployed servlet instance. The PID column shows the PID (process ID) of the client process. Typically the PID column value will appear as nnnn@hostname, where nnnn is the PID from the client's host system (as reported by jps, top, or tasklist) and hostname is the name of the client's host. If the client is the rtvdata or rtvquery servlet, then the PID will correspond to the app server (e.g. tomcat) process on the client host. The PID column may be blank if the client is unable to obtain its PID from the local operating system. The @hostname portion may be omitted if it cannot be obtained from the local operating system. The PID and Process Name columns will both be blank if the client process is running an older version of RTView that does not have this enhancement.


20231: Cache extend-by-sql option now supported in REST api

The REST (rtvquery) servlet now supports the "Extend with SQL" option on queries of cache history tables. This is enabled by setting the parameter named sqlex to true in a query URL. For example, the following URL is a query of the history table of a cache named Apps for the past 24 hours with the Extend with SQL option set: http://host/rtvquery/cache/Apps/history?fmt=text&tr=86400&sqlex=true Note that the new option only applies to a history table query, and only in the case where the time range (tr), begin time (tb), or end time (te) parameter is also specified. Use this option with caution as it may generate a large result.


Data Sources

19986: RRD data adapter fixed for Linux

In previous versions the the RRD data adapter was not correctly executing rrdtool on linux systems. This has been fixed.


20100: Cache extend-by-sql query now ignores row filters with value=*

A bug has been fixed in the cache data source which affected cache data attachments using the Extend with SQL option and which also use a row filter with multiple columns or multiple values, where * is used as one or more filter values. In those cases, the "where" clause in the SQL query generated by the cache data source was incorrect and returned no rows. This is fixed.

20191: Prevent data with timestamp < historyTimeSpan from going to history

In prior releases, a row with a timestamp older than a cache's historyTimeSpan could be added to the cache's history table and would not be removed until the next update. In this release this has been fixed so that such a row is not added to the history table in the first place.


Display Server

20009: Animated gif labels no longer mispositioned

In previous releases, the animated gif image on a label object would sometimes appear in the top left corner of the display, rather than positioned correctly on the label object. This is fixed.

20021: Images now found when rtv file loaded from subdirectory

In prior releases, the thin client would fail to load images for some objects if the images and the display containing the objects were in a subdirectory of the display server's working directory. This is fixed.

20097: “loading …” label no longer remains after loading finished

A problem has been fixed in the thin client that would sometimes cause the "loading..." message to remain on the display after the display had finished loading.

20151: Fixed bogus string for checkboxes when tabIndex > 0

A bug has been fixed in the thin client which affected displays containing any control object with its tabIndex property assigned to a nonzero value, as follows: 1) For each checkbox control on the display an unexpected string "tabIndex=nn" appears at the top of the display. 2) The initial keyboard focus may not be set to the expected control object. 3) If the javascript console or debugger window is open, an error is reported. All of these symptoms have been fixed.

20185: Kendo grid now supported

The "web grid" is a new HTML implementation of the RTView table object (obj_table02) that provides enhanced filtering, sorting, and other interactive features. The web grid is available in the thin client only. 1. Enabling the Web Grid: A new property has been added to obj_table02, named webGridFlag. To enable the web grid in the thin client for a specific obj_table02 instance, check the object's webGridFlag property in the Builder property sheet. Alternatively, the web grid can be enabled on all obj_table02 instances by adding the following rule to an rtview stylesheet (.rts) file loaded by the display server: obj_table02 { webGridFlag : 1 } The default value of webGridFlag is false, which indicates that the "classic" html grid should be used in the thin client. 2. Requirements: If webGridFlag = true then the web grid will appear in the thin client in any modern version of a supported browser. No plugin is required. For Internet Explorer users, version 9 or newer is required and version 11 is recommended for best performance. In IE8 or older, the web grid is not supported so the classic grid will be used regardless of the webGridFlag setting. In this release the web grid is not supported on iPad but may be supported in the future. 3. New Features: The web grid supports a number of new, interactive features: sorting on multiple columns, filtering on multiple columns, column resizing, column reordering, and hiding columns. In addition the user can "unsort" a previously selected sort column, returning it to its original unsorted order. In a grid with rowHeaderEnabledFlag = true, additional columns can be locked into the row header so they remain visible regardless of the horizontal scroll position. Many of these features are accessed from the column menu opened by clicking on the menu icon that appears near the right edge of each column's header. The user can save all of the aforementioned column settings/options permanently, in the browser's local. The saved settings are automatically restored when the user later reopens the display, with the same username and role. Also, for improved performance and usability, if a data table contains more than 200 rows the web grid will display it in pages of 200 rows, using a page control that appears at the bottom of the grid. Each new feature is described below: 3a. Column Sorting: The user can click on a column header to sort the table by that column. On the first click, the column is sorted in ascending order (smallest value at the top), on the 2nd click the sort is in descending order, and on the 3rd click the column is returned to its original unsorted state. A sort on a string column is case-insensitive. The user can select multiple sort columns. In that case, the sorting is performed in the order that the column headers were clicked. Multiple column sorting is a very useful feature, but can also cause confusion if the user intends to sort on a single column, but forgets to "unsort" any previously selected sort columns first. Users should check for the up/down sort icon in other column headers if a sort gives unexpected results. Column sorting is reflected in an export to html/excel. 3b. Column Visibility: The user can hide or show columns in the table by clicking on any column's menu icon, and picking Columns from the menu. This will open a submenu with a checkbox for each column that toggles the visibility of the column. All columns in the data table will appear in the Columns menu, even those that are initially hidden by the obj_table02 property columnsToHide. If the grid has the rowHeaderEnabledFlag property checked then the leftmost column (the row header column) cannot be hidden. Column visibility changes are NOT reflected in an export to html/excel. 3c. Column Filtering: The user can create a filter on any column. If filters are created on multiple columns, then only the rows that pass all of the filters are displayed. That is, if there are multiple filters they are logically ANDed together to produce the final result. The background of a column's menu icon changes to white to indicate that a filter is defined on that column. This is intended to remind the user which columns are filtered. The user can configure a filter on any column by clicking on the column's menu icon and picking Filter from the menu. This will open the column filter dialog, which varies according to the data type of the selected column: - For a string column, the user can enter a filter string such as "abc" and, from the dropdown list, select the operator (equal to, not equal to, starts with, contains, etc) to be used when comparing the filter string to each string in the column. All of the filter comparisons on strings are case-insensitive. The user can optionally enter a second filter string (e.g. "xyz") and specify if an AND or OR combination should be used to combine the first and second filter results on the column. - For a numeric column, the user enters numeric filter values and selects arithmetic comparison operators, (=, !=, >, >=, <, <=). The user can optionally enter a second filter value and comparison operator, and specify if an AND or OR combination should be used to combine the first and second filter results. - For a date column, the user can select a date and time and choose whether matching items should have a timestamp that is the same as, before, or after the filter time. The date is selected by clicking on the calendar icon and picking a date from a calendar dialog. The time is selected by clicking on the time icon and picking a time from a dropdown list. Alternatively, a date and time can be typed into the edit box. (See the limitations section for a note on time filtering when the client and server are located in different time zones). - For a boolean column, the user simple selects whether matching items should be true or false. Data updates to the grid are suspended while the filter menu is opened. The updates are applied when the menu is closed. Column reordering is reflected in an export to html/excel. 3d. Column Locking: This feature is available only if the obj_table02 instance has the row header feature enabled (rowHeaderEnabledFlag is checked). If so, the leftmost column is "locked" in position, meaning that it will not scroll horizontally with the other columns in the table. If the row header is enabled, then two items labelled Lock and Unlock will appear in the column menu. These can be used to add or remove additional columns from the non-scrolling row header area. If the row header is enabled, at least one column must remain locked. 3e. Column Reordering: The user can reorder the grid columns by dragging and dropping a column's header into another position. If the grid has rowHeaderEnabledFlag checked, then dragging a column into or out of the row header area (the leftmost columns) is equivalent to locking or unlocking the column. Column reordering is NOT reflected in an export to html/excel. 3f. Paging: If the data table contains more than one page of rows, the page controls are displayed at the bottom of the grid. The default page size is 200 but can be set on each obj_table02 instance via the new property named webGridRowsPerPage. The default value of that property is zero, which indicates that the default size (200) should be used. If the height of the grid is less than about 64 pixels, there is insufficient space to display the page controls so only the rows on the first page will be viewable. 3g. Row mouseover: A new property named webGridHoverColor is available on obj_table02. It is visible only if webGridFlag = true. The default value of webGridHoverColor is checked. If it is set to any other color index value, then that color will be used to highlight the row that is under the mouse cursor. But if the obj_table02 filterProperties feature is used to color rows, that color will take precedence, so the webGridHoverColor may not be useful in those cases. Also, if the row header is enabled, the row header column and the other columns are highlighted separately, according to which section of the grid the mouse is over. 3h. Saving settings: The user can permanently save all of the custom settings made to the grid, including filtering, sorting, column size (width), column order, column visibility, and column locking. This is done by opening any column menu, clicking Settings, and then clicking Save All. The grid's settings are written as an item in the browser's local storage. The item's value is the a string containing the grid's settings. The item uses a unique key comprised of the URL path name, the display name, and the obj_table02 instance's rtview object name. If the thin client's login feature is enabled, the key will also include the username and role, so different settings can be saved for each user and role for a grid on any given display, in the same browser and host. If the user saves the grid settings and navigates away from the display or closes the browser, then the next time the user returns to the display in the same browser the settings are retrieved from the browser's local storage and applied to the grid. The browser's local storage items are persistent, so the grid settings are preserved if the browser is closed and reopened or if the host system is restarted. If the obj_table02 has autoResizeFlag = true then the column widths will not be restored from the saved settings, and the values computed by the auto-resize feature will be used instead. This is by design. The user can delete the grid's item from local storage by clicking Settings -> Clear All in any column menu. This will permanently delete the saved settings for the grid and return the grid to the state defined in the display file. Note that each browser has its own local storage on each host. The local storage items are not shared between browsers on the same host or on different hosts. So, if a user logs in as Joe with role = admin, in Internet Explorer on host H1, and saves grid settings for display X, then those grid settings will be restored each time a user logs in as Joe, role admin, on host H1 and opens display X in Internet Explorer. But if all the same is true except that the browser is Chrome, then the settings saved in Internet Explorer will not be applied. Or if the user is Joe and role is admin and the browser is IE and the display is X, but the host system is H2 not H1, then the grid settings saved on H1 will not be applied. 4. Support for large tables: The web grid can support data tables with many rows and columns. However, for best performance the display server's cellsperpage property should be specified so that the server will send large tables to the client in pages, rather than sending all of the rows. In this server paging mode, large tables are also filtered and sorted in the display server, to improve performance and decrease data traffic. The cellsperpage option is not new or specific to the web grid, it has been available for several years. See the RTView documentation for a description of the cellsperpage property, and the related cellsperexport and cellsperreport properties. A typical value for cellsperpage is 20000. 5. Unsupported obj_table02 features: The following are existing features of obj_table02 that are not supported by the web grid -The rowHeaderEnabledFlag property is supported, but rowHeaderBgColor, rowHeaderTextColor, rowHeaderTextFont, rowHeaderTextSize are ignored. Instead the row header column is rendered like all other columns. - The columnResizeEnabledFlag is ignored if it is false, the web grid always allows column resizing. - The editDataEnabledFlag is ignored, the table editing feature using custom commands is currently not supported. 6. Other limitations, and differences between the new & classic grids: - Time zones: The strings shown in a date column are formatted by the display server using its time zone. But if a filter is specified on a date column, the date and time for the filter are computed using the client system's time zone. This can be confusing if the display server and client are in different time zones. - Selected rows: The grid's row selection is cleared if the sort is changed or if columns are resized or reordered. - Scrollbars: In general the grid will only display scrollbars when they are needed. However, the web grid and the classic grid use different algorithms for deciding when to show or hide scrollbars, and do not use identical row heights and column widths. So the web grid may sometimes display scrollbars when the classic grid does not, for a grid instance with a given width and height. - Keyboard traversal: In the classic grid, selecting a row and then using the up/down arrow keys will change the selection to the previous/next row. In the web grid, the arrow keys will move the keyboard focus to another row, as indicated by a highlight border around the focused table cell, but the user must press the space bar to select the row that contains the highlighted (focused) cell. - Column widths: On a web grid with no locked columns (rowHeaderEnabledFlag = false), columns will expand to fill any unused width in the table, even if autoResizeFlag = false. That is, if the total width of the columns is less than the grid width (ie. the columns don't use all of the available width) then each column is expanded proportionally to fill the table. In contrast, the classic and Swing (viewer) grids just leave unused space at the right edge of the grid. If the grid has locked columns (rowHeaderEnabledFlag = true), then the web grid behaves the same as the classic and Swing grids. - Export: The export to html and export to excel features are supported on the web grid, and behave much the same as on the classic grid. The exported table respects the grid's filter and sort settings but ignores any column reordering, sizing, or hiding changes made by the user. - Data updates to the grid are suspended while the filter menu is opened. The updates are applied when the menu is closed. 7. An implementation note, for custom web page developers only: The rtview thin client now uses 2 versions of the jQuery javascript library jQuery 1.3.2, to support the jQuery UI components used for panels, layout, and (some) navigation controls jQuery 1.9.1, to support the web grid Version 1.3.2 is bundled into the thin client js file named rtvNav1.js, while version 1.9.1 is loaded as a separate js file. To prevent conflicts between the two libraries, the jQuery $ alias is no longer used by rtview and is intentionally removed. Instead the jQuery 1.3.2 library is referenced by the alias rtv.jqNav as needed, and the jQuery 1.9.1 library is referenced by the alias rtv.jq as needed. This could affect existing custom javascript code that users have written. For example, the following is a snippet of javascript from a custom html page that uses jQuery UI tabs for navigation <script src="rtvNav1.js"></script> <script> $(document).ready(function () { var outerLayout = $('body').layout({ north__size:64, north__spacing_open: 0, }); $('#tabs').tabs(); ... The code above uses the jQuery $ alias, which it assumes is defined in the rtvNav1.js file. But that is no longer true, so the custom code should be rewritten to use the rtv.jqNav alias for jQuery in place of the $ alias, as follows: <script src="rtvNav1.js"></script> <script> rtv.jqNav(document).ready(function () { var outerLayout = rtv.jqNav('body').layout({ north__size:64, north__spacing_open: 0, }); rtv.jqNav('#tabs').tabs(); ...


20237: Touchscreen PCs no longer display thin client in tablet mode

In prior releases, if the thin client was opened in a browser on a PC with a touchscreen, items would be missing from in the right-click context menu. The missing items includied the Drill Down, Execute Command, and Export Table to Excel items, plus any custom menu items. This is fixed.


Functions

19950: Fixed Group By Unique Values function error

Previously, when the restrict to value list option was enabled, all rows from the original table that were not found in the value list were incorrectly assigned to the first element of the value list. This has been fixed.


General

19901: Stylesheet processing bug fixed

When colors of objects are driven by both stylesheets and functions, the functions should take precedence. In the previous release, the stylesheet was being incorrectly applied to properties that were attached to data. In many cases this was not noticeable because an update to the data attachment would override the stylesheet setting. However, in some cases where the data attachment didn't update after the display was processed, the stylesheet value was used. This has been fixed so that stylesheet values are no longer applied to properties that are attached to data.


20017: rtvquery servlet now uses "UTF-8" instead of "UTF8"

The rtvquery servlet will now specify UTF-8 character encoding for all responses. Previously, the servlet specified UTF8 which was not recognized by Internet Explorer versions 9 and older and caused an exception with the message "Could not complete the operation due to error c00ce56e"

Object Library

19989: Default format for date columns added to table objects

A property named columnFormatDate has been added to the table object (obj_table02). By default the property's value is blank. If the property is set to a valid time format, then that format will be used for all time/date columns in the table that do not have a format specified in the table's columnFormat property. For example if an obj_table02 instance contains a date column named X, then the format for column X is determined as follows: 1. If the table object's columnFormat property contains a valid date/time format for column X, then that format is applied to column X. 2. If the table object's columnFormatDate contains a valid date/time format, then that format is applied to column X. 3. Otherwise the default date/time format for the current locale, as returned by java.text.DateFormat.getDateTimeInstance(), is applied to column X. As with any object property, an rtview stylesheet entry can be used to set columnFormatDate globally on all obj_table02 instances, for example: obj_table02 { columnFormatDate: "yyyy-MMM-dd HH:mm:ss" }


20007: HTML5 - Color of the Navigator Trace now matches the trace it is representing

The navigator trace on the html5 chart will now use the same color as the trace assigned to the chart's webChartNavigatorTrace. In previous releases, the navigator trace was always blue.

20142: Fixed minor usability problems with tree/accordion control

The following minor problems with the tree and accordion control object are fixed: 1 The initialExpandDepth property is now only applied to new branches. Previously, on a tree control with valueTableType = Row-node the initialExpandDepth was improperly reapplied on each update to the tree, reopening any existing branches that the user may have closed. 2. In the thin client, the labels on accordion buttons are now aligned properly: Parent (non-leaf) node labels are left aligned, and leaf node labels are center aligned. This is consistent with the accordion in the builder/viewer. Previously, parent node labels were center aligned in the thin client, which was incorrect. 3. On a tree control In the thin client, a click on the +/- icon now opens/closes the tree branch as expected but it no longer selects the node or triggers the tree control's command. This is now consistent with the tree control behavior in the viewer. 4. On an accordion control In the thin client in most browsers, a click on a left/down arrow icon now opens/closes the branch as expected but it no longer activates the accordion button or triggers the accordion control's command. However, in IE version 8 or older, and in the viewer, the accordion button is still activated and the control's command is executed.


Solution Package

Amazon CloudWatch

20588: ACW api has changed

In 2015 Amazon added two additional metrics (CPUCreditBalance and CPUCreditUsage) to those available using the basic API. These metrics caused the CloudWatch data adapter to fail. The adapter has been modified to be robust and work correctly when Amazon adds or deletes metrics. In the case of deletion, the adapter may print a warning that an expected metric is not available. Note that ACW monitoring will fail for all versions of the ACW monitor prior to EM version 2.0.


Host Infrastructure

20206: Fixed scaling of CPU % column

The "CPU %" column in the "Host Views" / "All Processes Table" was improperly scaled. The data inserted into the HostProcesses cache is now multiplied by a correction of 100 divided by the number of host processors (threads for hyperthreaded architectures).


IBM Websphere Application Server

20184: Adjustments to allow processes to be run with a Sun JVM

A problem that prevented WSM being executed out of the box in Sun JVMs has been fixed. To use a Sun JVM, after setting WAS_HOME in custom_setup.bat/.sh, edit the sample.properties file and comment out the line: collector.sl.rtview.cp=%RTVAPM_HOME%/wsm/lib/rtvapm_wsm_plus.jar This line is only required for IBM JVM.


Oracle Weblogic

20107: Added MemoryUsedPercent to WLM Server cache

The metric MemoryUsedPercent which is the JVM Memory Used % that was previously calculated has been included in the WlsJvmStats cache and history. To update the history table use the following ALTER TABLE sentences: DB2: ALTER TABLE "WLS_JVMSTATS" ADD "MemoryUsedPercent" DOUBLE; SQL Server: ALTER TABLE [WLS_JVMSTATS] ADD [MemoryUsedPercent] FLOAT MySQL: ALTER TABLE "WLS_JVMSTATS" ADD"MemoryUsedPercent" DOUBLE ; SyBase: Altering the data type of columns in a Sybase table requires enabling the “select into” option for your database. Consult with your DB Admin on the correct procedure for your installation. ALTER TABLE "WLS_JVMSTATS" ADD "MemoryUsedPercent" FLOAT NULL Oracle: ALTER TABLE "WLS_JVMSTATS" ADD "MemoryUsedPercent" NUMBER;


TIBCO ActiveMatrix

20022: Key metrics implemented for TIBCO AMX CI Types

Key Metrics have been added to the amxmon solution package. The following Key Metrics are supported: AMX-SERVICE: Service Hits/Min Service Response Time AMX-SERVICENODE: Node Hits/Min Node Response Time


TIBCO BusinessEvents

20036: Key metrics implemented for TIBCO BusinessEvents CI Types

Key Metrics have been added to the TBEMON solution package. The following Key Metrics are supported: Rules Fired Rate Received Events Rate Concept Cache Ops Rate (where Ops means operations - get, put, remove) Backing Store Ops Rate (where Ops means operations - load, store, erase)


20193: Cluster Summary display added with new cluster-level metrics

The Tibco Business Events solution has been updated with additional displays and alerts relating to Cluster metrics. 1. New aggregated cluster-level metrics A new cache TbeClusterSummary contains metrics aggregated across all nodes in the cluster. 2. New alerts The new alerts have names starting with "TbeCluster", and are bound to cluster-level metrics. 3. Display Changes The previous top-level view of the same name has been renamed "Cluster Nodes". "Clusters" - New top-level tabular view of all currently monitored clusters. "Cluster Summary" - New summary view of a single cluster, with current values of aggregated metrics and trend charts for key metrics. "Agent Event Summary" - The Events screen has two separate tables; previously, the lower table for agent event data had no drill-down. In this release, clicking on a row of agent event data takes you to a "BE Agent Event Summary".


20255: Performance and architectural improvements

The Tibco Business Events solution has been refactored to bring it into full compliance with the best practices for our other solutions. Due to the extensive nature of changes required for this change, existing history data from older versions will not be retained. Users will have to re-create their database tables using the updated .sql schemas under tbemon\dbconfig. Changes to Caches 1. rename cache TbeCluster to TbeClusterNode. This change differentiates the contents (one row for each node in the cluster) from the new TbeClusterSummary cache, which aggregates node data to create new cluster-level metrics. 2. The column ordering in all caches now conforms with best practice (timestamp followed by index columns). 3. Total count columns in history have been replaced by interval deltas. Delta columns have been added to the following caches: TbeInferenceAgent TbeBackingStore TbeNodeEvents TbeAgentEvents TbeNodeConcepts Performance 1. The displays were optimized to minimize the amount of data sent to thin clients, so the displays should render faster in web browsers. New Features: 1. added alert TbeClusterMalformed that triggers when the cluster node count is not equal to the number of neighbors sensed by a given node. This is a sign that a node did not see cluster members and created it's own "single node cluster". 2. combo controls at top of screens that select which item to display now resize with the window so that long object names can be fully displayed. 3. The addition of delta columns to history support the "Use Rates" checkbox on trend charts for following summary displays: Agent Event Summary BE Concept Summary BE Event Summary "Use Rates" allows you to toggle between the display of "counts per collection interval" and "counts per second".


20586: Dropped 2 Heap columns from cache and the extra JMX calls eliminated

Several releases ago, the Tibco BE monitor was modified to display %CPU and heap memory metrics from rtvmgr. In order to avoid any changes to cache strucure in either package, the TbeObjectTable cache was not updated; two columns for collected JVM heap data were retained. In this release, BE Monitor has had a major update of both displays and caches, so these unused columns have been removed.


TIBCO BusinessWorks

20024: Key metrics implemented for TIBCO BW CI Types

The bwmon solution package has been enhanced to support Key Metrics. The following Key Metrics are supported BW-SERVER CI Type: CPU Usage % BW-ENGINE CI Type: CPU Usage % Memory Used % BW-PROCESS CI Type: Process Exec Time / sec


20113: New BwProcessElapsedTImeHigh alert

A new alert has been added: BwProcessElapsedTimeHigh. This is driven by the metric RateTotalElapsed in the BwProcesses table.


20143: Improved resize behavior of top-level common selectors

The resize behavior of the Activity displays has been improved so there will be more room to show the Process and Activity names as the display is resized.


20218: Accuracy of BW Process columns improved

The data types of Active and DeltaCreated columns in the BW_PROCESSES table have been converted to real numbers to account for the loss of resolution when compaction is taking place by averaging the metrics. As part of upgrading you must use alter table SQL like provided below for your supported DB platform (Oracle not required). DB2: ALTER TABLE "BW_PROCESSES" ALTER COLUMN "Active" SET DATA TYPE DOUBLE; ALTER TABLE "BW_PROCESSES" ALTER COLUMN "DeltaCreated" SET DATA TYPE DOUBLE; ALTER TABLE "BW_PROCESS_TOTALS" ALTER COLUMN "Active" SET DATA TYPE DOUBLE; SQL Server: ALTER TABLE [BW_PROCESSES] ALTER COLUMN [Active] FLOAT ALTER TABLE [BW_PROCESSES] ALTER COLUMN [DeltaCreated] FLOAT ALTER TABLE [BW_PROCESS_TOTALS] ALTER COLUMN [Active] FLOAT MySQL: ALTER TABLE "BW_PROCESSES" MODIFY "Active" DOUBLE , MODIFY "DeltaCreated" DOUBLE ; ALTER TABLE "BW_PROCESS_TOTALS" MODIFY "Active" DOUBLE ; SyBase: Altering the data type of columns in a Sybase table requires enabling the “select into” option for your database. Consult with your DB Admin on the correct procedure for your installation. ALTER TABLE "BW_PROCESSES" MODIFY "Active" FLOAT ALTER TABLE "BW_PROCESSES" MODIFY "DeltaCreated" FLOAT ALTER TABLE "BW_PROCESS_TOTALS" MODIFY "Active" FLOAT


TIBCO EMS

18002: Consumer and producer counts now exclude expired entries

The producer and consumer count from the Single Server Summary display now only take into account non-expired indexes.


19497: Drop-down lists adjusted to accomodate for longer values

The drop-down lists have been enhanced to accomodate for longer Server, Queue, and Topic names.


19962: Collection of consumers, producers, and connections can now be disabled

The collection of consumers, producers, and connections has been reorganized to allow disabling their collection independently. If you would like to collect metrics for these elements, you should copy the following lines from the sample.properties file in the EMSMON project directory and make appropriate changes in your properties file: # To disable consumers collection, comment out this line: sl.rtview.cache.config=ems_consumers_cache_source.rtv # To disable producers collection, comment out this line: sl.rtview.cache.config=ems_producers_cache_source.rtv # To disable connections collection, comment out this line: sl.rtview.cache.config=ems_connections_cache_source.rtv Please note that if these lines are not included in any of your properties files, you would not gather any metric for consumers, producers, and connections.


20026: Key metrics implemented for TIBCO EMS CI Types

Key Metrics have been added to EMSMON CI Types. EMS-SERVER: Pending Msgs In Msgs / sec Out Msgs / sec EMS-QUEUE: Pending Msgs In Msgs / sec Out Msgs / sec EMS-TOPIC: Pending Msgs In Msgs / sec Out Msgs / sec


20058: Convert PendingMessageCount and PendingMessageSize to DOUBLE

The types of several rate metrics have been converted to real numbers to account for the loss of resolution when compaction is taking place by averaging the metrics. Follow the appropriate alter table SQL syntax to apply the change to your supported DB platforms (Oracle not needed). DB2: ALTER TABLE "EMS_CONSUMERS" ALTER COLUMN "consumerByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_CONSUMERS" ALTER COLUMN "consumerMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_DURABLES" ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_DURABLES" ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_PRODUCERS" ALTER COLUMN "producerByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_PRODUCERS" ALTER COLUMN "producerMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUETOTALS" ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUETOTALS" ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUETOTALS" ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUETOTALS" ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUETOTALS" ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUETOTALS" ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUES" ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUES" ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUES" ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUES" ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUES" ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_QUEUES" ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_ROUTES" ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_ROUTES" ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_ROUTES" ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_ROUTES" ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_SERVERINFO" ALTER COLUMN "inboundBytesRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_SERVERINFO" ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_SERVERINFO" ALTER COLUMN "outboundBytesRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_SERVERINFO" ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_SERVERINFO" ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_SERVERINFO" ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICS" ALTER COLUMN "inboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICS" ALTER COLUMN "inboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICS" ALTER COLUMN "outboundByteRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICS" ALTER COLUMN "outboundMessageRate" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICS" ALTER COLUMN "pendingMessageCount" SET DATA TYPE DOUBLE; ALTER TABLE "EMS_TOPICS" ALTER COLUMN "pendingMessageSize" SET DATA TYPE DOUBLE; SQL Server: ALTER TABLE [EMS_CONSUMERS] ALTER COLUMN [consumerByteRate] FLOAT ALTER TABLE [EMS_CONSUMERS] ALTER COLUMN [consumerMessageRate] FLOAT ALTER TABLE [EMS_DURABLES] ALTER COLUMN [pendingMessageCount] FLOAT ALTER TABLE [EMS_DURABLES] ALTER COLUMN [pendingMessageSize] FLOAT ALTER TABLE [EMS_PRODUCERS] ALTER COLUMN [producerByteRate] FLOAT ALTER TABLE [EMS_PRODUCERS] ALTER COLUMN [producerMessageRate] FLOAT ALTER TABLE [EMS_QUEUETOTALS] ALTER COLUMN [inboundByteRate] FLOAT ALTER TABLE [EMS_QUEUETOTALS] ALTER COLUMN [inboundMessageRate] FLOAT ALTER TABLE [EMS_QUEUETOTALS] ALTER COLUMN [outboundByteRate] FLOAT ALTER TABLE [EMS_QUEUETOTALS] ALTER COLUMN [outboundMessageRate] FLOAT ALTER TABLE [EMS_QUEUETOTALS] ALTER COLUMN [pendingMessageCount] FLOAT ALTER TABLE [EMS_QUEUETOTALS] ALTER COLUMN [pendingMessageSize] FLOAT ALTER TABLE [EMS_QUEUES] ALTER COLUMN [inboundByteRate] FLOAT ALTER TABLE [EMS_QUEUES] ALTER COLUMN [inboundMessageRate] FLOAT ALTER TABLE [EMS_QUEUES] ALTER COLUMN [outboundByteRate] FLOAT ALTER TABLE [EMS_QUEUES] ALTER COLUMN [outboundMessageRate] FLOAT ALTER TABLE [EMS_QUEUES] ALTER COLUMN [pendingMessageCount] FLOAT ALTER TABLE [EMS_QUEUES] ALTER COLUMN [pendingMessageSize] FLOAT ALTER TABLE [EMS_ROUTES] ALTER COLUMN [outboundByteRate] FLOAT ALTER TABLE [EMS_ROUTES] ALTER COLUMN [outboundMessageRate] FLOAT ALTER TABLE [EMS_ROUTES] ALTER COLUMN [inboundByteRate] FLOAT ALTER TABLE [EMS_ROUTES] ALTER COLUMN [inboundMessageRate] FLOAT ALTER TABLE [EMS_SERVERINFO] ALTER COLUMN [inboundBytesRate] FLOAT ALTER TABLE [EMS_SERVERINFO] ALTER COLUMN [inboundMessageRate] FLOAT ALTER TABLE [EMS_SERVERINFO] ALTER COLUMN [outboundBytesRate] FLOAT ALTER TABLE [EMS_SERVERINFO] ALTER COLUMN [outboundMessageRate] FLOAT ALTER TABLE [EMS_SERVERINFO] ALTER COLUMN [pendingMessageCount] FLOAT ALTER TABLE [EMS_SERVERINFO] ALTER COLUMN [pendingMessageSize] FLOAT ALTER TABLE [EMS_TOPICTOTALS] ALTER COLUMN [inboundByteRate] FLOAT ALTER TABLE [EMS_TOPICTOTALS] ALTER COLUMN [inboundMessageRate] FLOAT ALTER TABLE [EMS_TOPICTOTALS] ALTER COLUMN [outboundByteRate] FLOAT ALTER TABLE [EMS_TOPICTOTALS] ALTER COLUMN [outboundMessageRate] FLOAT ALTER TABLE [EMS_TOPICTOTALS] ALTER COLUMN [pendingMessageCount] FLOAT ALTER TABLE [EMS_TOPICTOTALS] ALTER COLUMN [pendingMessageSize] FLOAT ALTER TABLE [EMS_TOPICS] ALTER COLUMN [inboundByteRate] FLOAT ALTER TABLE [EMS_TOPICS] ALTER COLUMN [inboundMessageRate] FLOAT ALTER TABLE [EMS_TOPICS] ALTER COLUMN [outboundByteRate] FLOAT ALTER TABLE [EMS_TOPICS] ALTER COLUMN [outboundMessageRate] FLOAT ALTER TABLE [EMS_TOPICS] ALTER COLUMN [pendingMessageCount] FLOAT ALTER TABLE [EMS_TOPICS] ALTER COLUMN [pendingMessageSize] FLOAT MySQL: ALTER TABLE "EMS_CONSUMERS" MODIFY "consumerByteRate" DOUBLE , MODIFY "consumerMessageRate" DOUBLE ; ALTER TABLE "EMS_DURABLES" MODIFY "pendingMessageCount" DOUBLE , MODIFY "pendingMessageSize" DOUBLE ; ALTER TABLE "EMS_PRODUCERS" MODIFY "producerByteRate" DOUBLE , MODIFY "producerMessageRate" DOUBLE ; ALTER TABLE "EMS_QUEUETOTALS" MODIFY "inboundByteRate" DOUBLE , MODIFY "inboundMessageRate" DOUBLE , MODIFY "outboundByteRate" DOUBLE , MODIFY "outboundMessageRate" DOUBLE , MODIFY "pendingMessageCount" DOUBLE , MODIFY "pendingMessageSize" DOUBLE ; ALTER TABLE "EMS_QUEUES" MODIFY "inboundByteRate" DOUBLE , MODIFY "inboundMessageRate" DOUBLE , MODIFY "outboundByteRate" DOUBLE , MODIFY "outboundMessageRate" DOUBLE , MODIFY "pendingMessageCount" DOUBLE , MODIFY "pendingMessageSize" DOUBLE ; ALTER TABLE "EMS_ROUTES" MODIFY "outboundByteRate" DOUBLE , MODIFY "outboundMessageRate" DOUBLE , MODIFY "inboundByteRate" DOUBLE , MODIFY "inboundMessageRate" DOUBLE ; ALTER TABLE "EMS_SERVERINFO" MODIFY "inboundBytesRate" DOUBLE , MODIFY "inboundMessageRate" DOUBLE , MODIFY "outboundBytesRate" DOUBLE , MODIFY "outboundMessageRate" DOUBLE , MODIFY "pendingMessageCount" DOUBLE , MODIFY "pendingMessageSize" DOUBLE; ALTER TABLE "EMS_TOPICTOTALS" MODIFY "inboundByteRate" DOUBLE , MODIFY "inboundMessageRate" DOUBLE , MODIFY "outboundByteRate" DOUBLE , MODIFY "outboundMessageRate" DOUBLE , MODIFY "pendingMessageCount" DOUBLE , MODIFY "pendingMessageSize" DOUBLE ; ALTER TABLE "EMS_TOPICS" MODIFY "inboundByteRate" DOUBLE , MODIFY "inboundMessageRate" DOUBLE , MODIFY "outboundByteRate" DOUBLE , MODIFY "outboundMessageRate" DOUBLE , MODIFY "pendingMessageCount" DOUBLE , MODIFY "pendingMessageSize" DOUBLE ; SyBase: Altering the data type of columns in a Sybase table requires enabling the “select into” option for your database. Consult with your DB Admin on the correct procedure for your installation. ALTER TABLE "EMS_CONSUMERS" MODIFY "consumerByteRate" FLOAT ALTER TABLE "EMS_CONSUMERS" MODIFY "consumerMessageRate" FLOAT ALTER TABLE "EMS_DURABLES" MODIFY "pendingMessageCount" FLOAT ALTER TABLE "EMS_DURABLES" MODIFY "pendingMessageSize" FLOAT ALTER TABLE "EMS_PRODUCERS" MODIFY "producerByteRate" FLOAT ALTER TABLE "EMS_PRODUCERS" MODIFY "producerMessageRate" FLOAT ALTER TABLE "EMS_QUEUETOTALS" MODIFY "inboundByteRate" FLOAT ALTER TABLE "EMS_QUEUETOTALS" MODIFY "inboundMessageRate" FLOAT ALTER TABLE "EMS_QUEUETOTALS" MODIFY "outboundByteRate" FLOAT ALTER TABLE "EMS_QUEUETOTALS" MODIFY "outboundMessageRate" FLOAT ALTER TABLE "EMS_QUEUETOTALS" MODIFY "pendingMessageCount" FLOAT ALTER TABLE "EMS_QUEUETOTALS" MODIFY "pendingMessageSize" FLOAT ALTER TABLE "EMS_QUEUES" MODIFY "inboundByteRate" FLOAT ALTER TABLE "EMS_QUEUES" MODIFY "inboundMessageRate" FLOAT ALTER TABLE "EMS_QUEUES" MODIFY "outboundByteRate" FLOAT ALTER TABLE "EMS_QUEUES" MODIFY "outboundMessageRate" FLOAT ALTER TABLE "EMS_QUEUES" MODIFY "pendingMessageCount" FLOAT ALTER TABLE "EMS_QUEUES" MODIFY "pendingMessageSize" FLOAT ALTER TABLE "EMS_ROUTES" MODIFY "outboundByteRate" FLOAT ALTER TABLE "EMS_ROUTES" MODIFY "outboundMessageRate" FLOAT ALTER TABLE "EMS_ROUTES" MODIFY "inboundByteRate" FLOAT ALTER TABLE "EMS_ROUTES" MODIFY "inboundMessageRate" FLOAT ALTER TABLE "EMS_SERVERINFO" MODIFY "inboundBytesRate" FLOAT ALTER TABLE "EMS_SERVERINFO" MODIFY "inboundMessageRate" FLOAT ALTER TABLE "EMS_SERVERINFO" MODIFY "outboundBytesRate" FLOAT ALTER TABLE "EMS_SERVERINFO" MODIFY "outboundMessageRate" FLOAT ALTER TABLE "EMS_SERVERINFO" MODIFY "pendingMessageCount" FLOAT ALTER TABLE "EMS_SERVERINFO" MODIFY "pendingMessageSize" FLOAT ALTER TABLE "EMS_TOPICTOTALS" MODIFY "inboundByteRate" FLOAT ALTER TABLE "EMS_TOPICTOTALS" MODIFY "inboundMessageRate" FLOAT ALTER TABLE "EMS_TOPICTOTALS" MODIFY "outboundByteRate" FLOAT ALTER TABLE "EMS_TOPICTOTALS" MODIFY "outboundMessageRate" FLOAT ALTER TABLE "EMS_TOPICTOTALS" MODIFY "pendingMessageCount" FLOAT ALTER TABLE "EMS_TOPICTOTALS" MODIFY "pendingMessageSize" FLOAT ALTER TABLE "EMS_TOPICS" MODIFY "inboundByteRate" FLOAT ALTER TABLE "EMS_TOPICS" MODIFY "inboundMessageRate" FLOAT ALTER TABLE "EMS_TOPICS" MODIFY "outboundByteRate" FLOAT ALTER TABLE "EMS_TOPICS" MODIFY "outboundMessageRate" FLOAT ALTER TABLE "EMS_TOPICS" MODIFY "pendingMessageCount" FLOAT ALTER TABLE "EMS_TOPICS" MODIFY "pendingMessageSize" FLOAT


20272: New flag to enable topic/queue browsing

A new flag to enable the Browse button for browsing messages on queues and topics has been added. By default browsing is disabled. Once this flag is enabled, a button for browsing queues will be visible on the Single Queue Summary page To enable this flag, add the following property to a properties file in use by your servers: sl.rtview.sub=$emsDestBrowseButtonVisFlag:1 For users of standalone BW Monitor, we recommend adding it to sample.properties. Users of RTView EM should add it to servers\central\central.properties (or their own custom properties file loaded by central servers).


20539: Drill down to Topics Summary from All Topics Heatmap fixed

A bug that prevented correct drilling down from All Topics Heatmap to the Topic Summary has been fixed.


TIBCO Hawk

20200: Sorting, navigation, and appearance improvements to Hawk Agent Table

Several defects have been corrected for the Hawk Agents Table. 1. The table now shows rows sorted by "Domain" and "Host Name" in ascending order. Clicking on a column name will resort the table by that column. 2. An Expired column has been added to the table to indicate stale data, and the row background is shaded by the standard "Expired" color. 3. Row background is also shaded in a slightly different color for rows for which drill-down is not available (ie, the host solution package is not configured to collect from the given agent). The display does not change when such a row is clicked. Clicking on an unshaded row leads to the corresponding "Host Summary" screen. Note: for drill-down to work correctly, the configured hawk console connection name must be the same as the hawk domain name, as shown in the following example (slwin). sl.rtview.hawk.hawkconsole slwin rvd slwin 7474 ; tcp:7474


20201: Standardized Time column in Hawk Alert Table

The time format for Hawk alerts displayed in "Tibco Hawk Monitor" / "Hawk Alerts Table" has been changed to match the time formats used elsewhere in RTView EM: "dd-MMM-yyyy HH:mm:ss".


VMWare vSphere

19382: VM's now retain history when changing hosts

This release of vmwmon provides a new indexing scheme which is independent of the index values assigned by the vSphere server. The previous vmwmon relied on vSphere indexes, which changed when a virtual machine was moved to a different host. This index change caused EM to think that the old VM had simply been turned off, and a new VM created. There was no linkage between the old and new VMs, and so the new VM could not access the history saved for the old VM. Using the new indexing scheme, VMs can migrate to new hosts and history is preserved (a short outage will be observed in the trend charts for the period required to stop, move, and restart the VM). Due to the extensive nature of changes required for this change and for task 20160 (vSphere 5.5 support), existing history data from older versions will not be retained. Users will have to re-create their database tables using the updated .sql schemas under vmwmon\dbconfig.


20160: Support for vSphere SDK 5.5

The RTView datasource for vmwmon has been updated to use vSphere 5.5 SDK (necessary because previous datasource used vSphere 4.1 SDK which is end of life and unsupported). The older 4.1 API will not work with this new data source. Configuration is now much simpler, as the Apache Axis jars are no longer required. Java 1.6 is required. Download the 5.5 SDK from the following URL, extract the vim25.jar, and add to the classpath in your property file. (See sample.properties in the vmwmon project\samples folder for an example.) https://communities.vmware.com/community/vmtn/developer/forums/java_toolkit


20203: New metrics and a new display added

The VMWMON solution package has been updated with the following changes: 1. new cache (VmwVmDiskUsage) with disk utilization metrics for each VM. A tabular display has been added to view disk utilization, and a new alert for high disk utilization was added. 2. new host metrics (host physical memory size, num CPU threads/cores, num packets Rx/Tx and packet errors, % packet drops/errors and alerts ) 3. new guest metrics (guest configured memory size, guest OS name, VM tools status, num CPUs, num packets Rx/Tx , % packet drops and alerts ). 4. mem.consumed.average was changed to mem.active.average, as this VM metric better describes actual memory usage by the running guest OS. See https://vdc-download.vmware.com/vmwb-repository/dcr-public/2d445149-7707-4c7d-98a7-9f00394b7df2/7322d611-ef3b-454a-ab63-ad3302d8b218/SDK/vsphere-ws/docs/ReferenceGuide/index.html for more details. Note: with the cumulative changes to VMWare vSphere monitor for this release, this is effectively a new solution package, and the history schema and CMDB definitions are incompatible with previous versions. Customers are advised to delete previous history and CMDB references from their databases.


Version 1.5.3 Release Notes

Monitor

19865: New display for History table monitoring

A new display to monitor the History tables has been added. Go to Architecture -> Data Server Summary and click on the History Tables button. A new display with all information about the existing tables for each cache in the selected Data Server will appear.


RTVMGR

19956: New Tomcat alerts for access rates of server and apps

Two new alerts for Tomcat have been added: TomcatAccessRateHigh and TomcatAppAccessRateHigh. The former alerts when the Access Rate of a Tomcat Server reaches its maximum and the latter alerts when a given application deployed on a Tomcat Server reaches its maximum.


19958: MemoryUsedPercent added to history cache for Operating System

A new metric, MemoryUsedPercent, has been included in the history of the JvmMemory cache. This addition impacts the previous sql schema provided in the product. To update previous schema, execute the following sentence in your DB admin tool: For DB2 and MySQL: ALTER TABLE "JVM_MEMORY" ADD "MemoryUsedPercent" DOUBLE; For Oracle: ALTER TABLE "JVM_MEMORY" ADD "MemoryUsedPercent" REAL; For SQL Server: ALTER TABLE [JVM_MEMORY] ADD [MemoryUsedPercent] FLOAT; For SyBase: ALTER TABLE "JVM_MEMORY" ADD "MemoryUsedPercent" FLOAT NULL;


19999: New alert for high memory usage after GC

A new alert, JvmMemoryUsedAfterGCHigh, has been added to RTVMGR. This alerts is activated when the percentage of the minimum memory used relative to the maximum memory used after GC reaches the threshold.


RTView Core Functionality

Data Historian

19987: Compaction now recovers after a lost database connection is restored

Compaction now recovers correctly after a lost database connection is restored.


Data Sources

19960: Fixed bogus extend-by-SQL query if history has future timestamps

A bug in the cache data source has been fixed that triggered an unnecessary SQL query if an attachment to a cache history table had the Extend with SQL option checked, and the history table contained timestamps in the future as compared to the current time on the system hosting the cache data source.


20072: Fixed concurrency exception when updating sql RTViewDs.Connections table

A bug has been fixed in the sql data source which, in rare cases, caused a ConcurrentModificationException to be thrown if a display was open with a data attachment to the sql RTViewDs.connections table.


Object Library

20002: Right/Double-click features supported for status history chart

The status history chart (obj_statushistory) can now be configured to extend the right-click context menu and support double-click behavior, in the same manner as the heatmap, table, and grid objects. To support this feature properties named menuItemGroup and rightClickActionFlag have been added to the chart. See 17835 for more information on using these properties to extend the context menu and control the double-click behavior.


Solution Package

Amazon CloudWatch

19501: CPU % no longer incorrectly is shown as >100%

In previous versions the CPU % sometimes showed a value greater than 100 %. This has been fixed.


Host Infrastructure

19955: The HostStats cache no longer misses asynchronous updates from sender

An advanced feature of RTView EM is the ability of remote data servers to serve as collectors and forward their data to a central server for aggregation (the alternative is for the central displayserver to simply refer the client to the remote dataserver to display the data directly). An example of how one or more remote collectors are started is as follows: rundata -properties:my.properties -propfilter:sender The aggregating dataserver is started as follows: rundata -propfilter:receiver This release corrects two problems in the sender/receiver architecture. 1. several columns were not updated in the receiver's cache. 2. occasionally, an entire row in the receiver's cache might not be updated.


Oracle Weblogic

20000: New alert for high number of threads waiting for JDBC connections

A new alert, WlsJDBCConnectionsWaitingHigh, has been implemented that will be triggered when the number of threads waiting for a JDBC connection has reached the threshold.


TIBCO ActiveMatrix

19881: Updates to history table columns

The SQL schemas have been updated with two changes. 1) In the previous version, the table definition for AMX_BW_PROCESS_TOTALS was incorrect - it was missing an initial index column "MicroAgentName". This omission has been fixed. Users affected by this bug will need to delete and re-create the AMX_BW_PROCESS_TOTALS table according to the new definition under rtvapm\amxmon\dbconfig 2) The data type for "Hits Per Interval" and "Faults Per Interval" columns in the table AMX_SERVICE_TOTALS changed from integer to double/float. This is in support of the change for 20012 in 1.5.2. Users with existing tables should consult with their DBA on the correct "alter table" syntax for their database DB2 Example: ALTER TABLE "AMX_SERVICE_TOTALS" ALTER "Hits Per Interval" SET DATA TYPE DOUBLE; ALTER TABLE "AMX_SERVICE_TOTALS" ALTER "Faults Per Interval" SET DATA TYPE DOUBLE;


20012: Hits and Faults per interval calculation now more sensitive

When the incoming hits per minute reported by AMX is small, the Total Hits counter displayed in the "All Services" and "All Service Nodes" tables was zero. This was due to inappropriate integer math in the calculation, which has been corrected in this release. The following supplementary explanation describes how Total Hits is calculated, and limitations in the approach. Total hits is not directly provided by Tibco; rather, it is derived from the average hits per minute that we get from AMX internal stats. Tibco documentation is not available for how this average is computed, but we can be certain that the total hits we display are approximately correct but can be delayed by up to half the averaging interval. For example, say Tibco gives us a metric value of .2 hits per minute. Obviously, we did not receive .2 hits in the preceding minute; an averaging period of perhaps several minutes is implied.. If the averaging interval is 5 minutes, then we can say that 1 hit was received in some 5 minute interval. But, EM provides metrics by polling interval, so with a 30 second interval, we add .1 hits/interval to our accumulator for the next 10 intervals and finally display an integer hit count incremented by 1 (with no rounding). This works regardless of whether Tibco uses fixed periods like 0-5, 6-10, etc, or a rolling average. Hence, the rounded total hits values displayed in EM have a lag of up at least half the averaging period. That is, it could be 2.5 minutes if their averaging period is 5 minutes before we see the hit count increment. Hence, the hit count is most useful as an activity indicator, rather than an absolute readout of real-time activity.


TIBCO ActiveSpaces

19983: Active Spaces added to the Services By CI Type grid display

The Active Spaces CI has been added to the XML file that drives the Services By CI Type grid display.


TIBCO BusinessEvents

19998: Enhanced sample.properties

A new sample.properties file has been provided that describes the connection properties necessary to monitor each BusinessEvents engine in a cluster. Additional detail can be found in the documentation for TIBCO RTView for TIBCO BusinessEvents.


VMWare vSphere

19953: New VmwHostMemoryUsageHigh alert

An alert for memory usage by a VMWare virtual machine (VmwHostMemoryUsageHigh) was referenced in a configuration file but not implemented. An implementation for the alert has been added.


Version 1.5.2 Release Notes

Monitor

19976: HTML5 labels and trend charts enabled as EM defaults

In EM, the default settings for the display server now set the webChartFlag property to true on all obj_fxtrend objects and set the webLabelFlag to true on all of the label objects that support that property. For more information on webChartFlag, see the release note for 19454. For more information on webLabelFlag, see the release note for 19861.


RTView Core Functionality

Builder - Editing

19879: Fixed NPE when deleting local var with same name as global

A bug has been fixed in the Builder which caused a NullPointerException to be thrown if a local variable was deleted and the local variable had the same name as a global variable.


Data Historian

19469: Avoid removal of all batch data when some data is wrong.

The historian will no longer discard all rows in a batch if a SQL exception is thrown during an row insert. Instead it will catch the exception and continue with the other row inserts in the batch and commit all of the successful inserts at the end of the batch.


19786: smoothCompaction no longer throws NPE when there are no compaction rules

Previously a NPE was thrown when -smoothcompaction was used with a cache with a compaction type of "aggregate" but with no compaction rules. Now this scenario fails silently.


19915: Simple retention now applied only to tables without compaction rules

If a cache history table that was persisted by the historian had no compaction rules, then the simple retention time limit was applied to ALL tables persisted by the historian. This was incorrect. The simple retention limit will now only be applied to tables without compaction rules.


Data Sources

19977: New onData Length column

The TIBCO Hawk data source has been enhanced to include a new onData Length column in the RTViewDs GetSubscriptionStatus method. This column contains the amount of time, in milliseconds, that the last onData call took to process the subscription data.


Display Server

19880: Fixed unstable dropdown list in FF & Chrome

In prior versions of the thin client, on each display refresh the dropdown list of the combo box control would scroll and the highlighted list item would change, even if the refresh did not change the items in the list. This behavior could make it difficult to use the dropdown list. This problem has been fixed. Note that this problem affected the thin client in Firefox and Chrome, but not Internet Explorer.


General

19933: rtvquery default time range for current table changed from 30s to ALL

The rtvquery servlet will no longer apply a default time range of 30 seconds to queries on the current table of a cache. Instead, it will apply a default time range of zero, which will return all rows from the current table regardless of their timestamp. A default of 30 seconds will still be applied to all queries on cache history tables. Note that the time range, in seconds, can be specified with the tr parameter in the URL. For example, this query will return the last 10 minutes of history data from a cache named Servers: http://host:port/rtvquery/cache/Servers/history?tr=600


Object Library

19861: Support HTML label object in the thin client

A number of simple RTView graphical objects have been enhanced to allow them to be rendered as HTML elements in a thin client deployment, rather than rendered in the image generated by the Display Server. This enhancement can improve system performance in some cases and also allows the user to copy text strings in the objects to the clipboard. Most of the objects affected by this enhancement are found on the General tab and Labels tab in the Builder's object palette. The enhanced objects are: obj_rect obj_rect_il obj_rect_ilv obj_rect_ilvs obj_rect_ilvx_da3 obj_rect_ilvx_ra4 obj_circ2d obj_circ2d_il obj_circ2d_ilv obj_circ2d_ilvs obj_circ2d_ilvx_da3 obj_circ2d_ilvx_ra4 obj_label05 obj_label05s obj_label11 obj_label11s obj_text01 obj_c1btn_chk These objects now support a new a new property named webLabelFlag. In a display server deployment, if webLabelFlag is true (checked) then the object will be rendered as HTML in the thin client, rather than rendered in the image by the display server. This allows the display server to update the individual object, if necessary, when the display is refreshed, rather than regenerating the entire display image. If all of the dynamic objects on a display can be rendered as HTML, this can improve the performance of the display server and thin client. The list of objects that can be rendered as HTML now includes all the objects listed above, all objects on the Controls tab in the object palette (obj_c1*), the table object (obj_table02), and the trend chart (obj_fxtrend). Another advantage of setting webLabelFlag on an object is that it allows the user to select the object's text and copy it to the clipboard. By default webLabelFlag is false (unchecked). The webLabelFlag property is listed in the "Label" category in the Builder's property sheet. The webLabelFlag can be set on all of the objects listed above via the following entry in an rtview stylesheet (.rts) file: rtv-all { webLabelFlag: 1; } In certain cases, an object included in the list above will still be rendered in the image by the display server even if webLabelFlag = true. These cases are: - the display is opened in Internet Explorer 8 or older. - the display server is run with the -nohtml5 option on the command-line. - an obj_text01 instance with rotated text (a nonzero value for rotationAngle). - an obj_rect* with labelTextPosY = Tab Top - an obj_rect* with labelTextPosY= Title Top and bgBorderFlag = true - an obj_label* with bgStyle = Round Rectangle - the object is inside an object grid, and is not inside a composite object in that grid - the object is an obj_rect* and there is a non-html object above it in Z-order which overlaps (for example, an obj_rect instance used as a background behind several meter objects) In other cases, an object may have a slightly different appearance in the thin client when it is rendered as HTML, as follows: - only vertical and horizontal gradients are supported on HTML objects in the thin client, so if an object has its bgGradientMode property set to "Diagonal Edge" or "Diagonal Center" it is treated as "Vertical Edge" instead. - the object's bgShadowFlag property is ignored Note that the webLabelFlag property has no effect in the builder or viewer (thick client).


19934: New property to limit size of label area

The status history object (obj_statushistory) supports a new property named barLabelMaxLengthPct. This can be used to specify the maximum length for each bar label as a percentage of the plot area width. The default is zero which means no limit is applied to the label length. If a positive value is specified for both the barLabelMaxLength and barLabelMaxLengthPct properties, then the smaller length limit of the two will be used.


19935: Newlines now supported in mouseover

The status history chart (obj_statushistory) will now properly convert a backslash-n sequence into a newline when displaying the mouseover (tooltip) string. This string is acquired from the column specified by the chart's descriptionColumnName property.


19938: HTML5 obj_trendgraph02 no longer ignores data table with 1 column

A problem in the display server has been fixed which prevented an obj_trendgraph02 instance with webChartFlag = 1 from plotting any data points on trace N if traceNValue was attached to a table containing a single numeric column.


Reporting

19939: obj_trendgraph02 using HTML 5 can now be exported to PDF

A problem has been fixed which prevented an obj_trendgraph02 instance with webChartFlag = 1 from being included in the output of the thin client's "Export to PDF" option.


Solution Package

19893: Removal of empty references

References to empty files containing global variables have been removed.


Amazon CloudWatch

19712: SQL schemas updated to conform to explicit structure of cache

Previous to 1.5.1, the structure of the acwmon caches was not explicitely defined, but was instead dependent on the structure returned by Amazon. This could cause storage and read of historical data to be unreliable. The cache structure has now been explicitly defined, and as a consequence, the database schemas under acwmon\dbconfig have been adjusted to reflect this definitive column order.


IBM Websphere MQ

19888: Added mqmon to sample EM probject

A server directory for the mqmon solution package has been added to the RTView EM sample project


Oracle Weblogic

19892: AllProcessorAverageLoad no longer reporting incorrect data

A bug that caused AllProcessorsAverageLoad to report incorrect values has been fixed.


TIBCO ActiveMatrix

19836: Look and feel improvements made to trend graphs

The trend graphs in the AMX Service and Service Node Summary pages and on the BW Process Summary page have had their trace colors improved for readability with light styles.


TIBCO EMS

19941: Updated description of EmsConsumerStalled alert

The description of the EmsConsumerStalled alert has been improved to include include the units of the alert.


UX Monitor

19803: UXMon robot now works with a buttonInputElementType of ID

Previously the UXMon robot would throw an NullPointerException with a buttonInputElementType of ID. This has been fixed.


19804: UXMon robot now supports encrypted passwords in URLs

The UX Robot now supports encrypted passwords in URLs.


Version 1.5.1 Release Notes

Customization

19790: Improvements to custom example

The sample project for the creation of Custom Solution Packages has been updated to use the startup scripts. Its properties files have been simplified and a sample.properties file with custom configuration properties has been included.


Deployment

19788: WSM added to projects/emsample/servers

WSM directory has been added to emsample. This inclusion will allow monitoring of WebSphere deployments under EM.


RTView Core Functionality

18643: japanese chars no longer garbled by "Send Email" command

The email command will now properly encode Japanese and other Asian characters contained in the text of the email. In prior release, such characters were garbled.

19813: Fixed javascript error thrown by obj_datechooser in IE

A bug in the thin client has been fixed which caused an "unterminated string constant" error message to appear in Internet Explorer's javascript console when the date chooser control was clicked.

Splunk

19379: Splunk data adapter updated

The Splunk data adapter has been updated to make it compatible with recent versions of Splunk (6.0+). The Splunk data adapter uses the recent splunk java SDK so is compatible with compatible with recent versions of Splunk (6.0+). This version of the SDK requires java SE version 6 or higher (for both the splunk server and the data adapter client). If you are using Windows, make sure the JAVA_HOME system variable is set to the directory where the JDK is installed. The required jars are included in the delivery and added to the classpath by the GmsLauncher; The user does not need to use RTV_USERPATH as in previous versions. Splunk Connections are now defined using explicit Host and Port values rather than a single URL as previously. The Splunk options now contains a search job wait time field (in ms). This is used to control the wait time when polling for search job completion; the user will typically not need to modify this value. The Attach To Splunk Data dialog has some new fields compared with previous versions. The new fields are as follows. Earliest Time: Filters the (splunk search) returned objects by their timestamp. Only objects that have a timestamp that is >= earliest_time will be returned. The time format is always ISO-8601 formatted. Ex:2008-01-29T11:40:58-0800. If omitted, then no earliest time bound is used. Latest Time: Filters the (splunk search) returned objects by their timestamp. Only objects that have a timestamp that is < latest_time will be returned. The time format is always ISO-8601 formatted. Ex:2008-01-29T11:40:58-0800. If omitted, then no latest time bound is used. Example Times are 2014-06-05T00:00:00-0800 2014-06-06T00:00:00-0800 ISO-8601 format is described on the web http://en.wikipedia.org/wiki/ISO_8601 http://www.iso.org/iso/home/standards/iso8601.htm http://www.w3.org/TR/NOTE-datetime Offset: The starting offset (0-based) of the first object to return in the (search result) list. Can be used together with Max Results: to "cursor" through a large result set, a small "chunk" at a time. (not the effect on the internal "_serial" splunk data column) Divide Data Column: When Selected, this check box makes additional fields visible for use in dividing up data in a returned column ,by means of a Java regular expression, into numbered columns in the returned data. Typically this is used to extract data that has an implicit token or field based positional location in the raw data returned by splunk. Examples of use would be to break up raw log line / HHTP request into fields / columns. The additional Divide Column Data fields are as follows Divide Column Name: The name of the column to divide (split) into individual values - typically this will be the raw data column returned from splunk "_raw" Column Data Regexp: The Java Regular Expression (Regexp) specification used to split the data in the named column into individual numbered columns that contain matched occurrences of the regular expression, where the new column name is the number of the occurrence (e.g. "1", "2", "3", etc) The Column Data Regexp field contains a drop down with a number of predefined regular expression literals, or you can enter your own. Note: Normally Splunk will recognize and extract fields and make them available for searching on, but sometimes you need to split up the raw data to extract meaningful information.

TIBCO Hawk Data Source

19818: Hawk 5.1 support

The TIBCO Hawk data source has been enhanced to support running against Hawk 5.1. Support for running against Hawk 5.0 has been removed. This means that the system where you are running RTView must have the HAWK_ROOT environment variable pointing to a Hawk 4.x or Hawk 5.1+ installation. The TIBCO Hawk data source can still connect to agents that are running version 5.0, the limitations is only that cannot run on a system where HAWK_ROOT is set to a Hawk 5.0 installation. If RTView is run on a system where HAWK_ROOT is set to a Hawk 5.0 installation, it will crash with the following exception: Exception in thread "main" java.lang.IncompatibleClassChangeError: Found class COM.TIBCO.hawk.console.hawkeye.AgentMonitor, but interface was expected at com.sl.gmsjhawkds.GmsHawkConsole4x.initAgentMonitor(GmsHawkConsole4x.java:160) at com.sl.gmsjhawkds.GmsTibConsole.initHawk(GmsTibConsole.java:513) at com.sl.gmsjhawkds.GmsRtViewHawkDs.initHawk(GmsRtViewHawkDs.java:1192) at com.sl.gmsjhawkds.GmsRtViewHawkDs.initializeData(GmsRtViewHawkDs.java:1296) at com.sl.gmsjrtview.GmsRtViewAppManager.initializeData(GmsRtViewAppManager.java:4099)

Tables

19796: Table Rows containing larger images no longer clip

A problem in the display server has been fixed which could cause the heights of table rows containing images to be too small to display the entire image. This problem only occurred if multiple instances of the rtvdisplay servlet were connected to the same display server instance.

Solution Package

General

19806: Style sheet cleanup

To improve the readability, several style overrides have been fixed. These changes have been made in AMXMON, OCMON, UXMON, SOLMON, TBEMON, and OEMCON.


IBM Websphere MQ

19699: Time gaps now displayed correctly on trends

Trend graphs in the MQ package previously showed gaps incorrectly in data; it filled all gaps with a continuous line. Now all trend graphs show gaps when a period with no data has been detected.


19791: Alerts no longer missing Connection index and description

A bug has been fixed that prevented many MQ alerts from being displayed properly in RTView EM. The CI Type MQ-CHANNEL has been added to the MQ package.


19792: Added Alert State to Broker, Channel, and Queue tables

Broker, Channel, and Queue tables have been enhanced to indicate alert severity. A bug has been fixed in Queue Managers table where the contents of the table disappear intermittently under certain circumstances.


Oracle Coherence

19690: Added OutgoingByteBacklog to proxy node and extend client caches

OutgoingByteBacklog has been added to history in the OcProxyServiceStats, OcProxyServiceTotals, and the OcExtendConnections caches. As part of this change, the column "OutgoingByteBacklog" has been added to the history tables OCM_PROXYSERVICESTATS, OCM_PROXYSERVICETOTALS, and OCM_EXTENDCONNECTIONS. These history tables are not enabled in a default configuration, so not all users will already be using these tables. Users who do have existing database tables will need to alter their table to include this additional column. (Task 19797 also has caused changes to OCM_PROXYSERVICESTATS. See that release note for more information.) The new table structure (DB2 example) is: CREATE TABLE "OCM_EXTENDCONNECTIONS" ( "TIME_STAMP" TIMESTAMP , "OutgoingByteBacklog" BIGINT , "UUID" VARCHAR(100) , "name" VARCHAR(100) , "Connection" VARCHAR(100) , "Location" VARCHAR(100) , "RemoteEndpoint" VARCHAR(100) , "DeltaTotalBytesReceived" BIGINT , "DeltaTotalBytesSent" BIGINT , "DeltaTotalMessagesReceived" BIGINT , "DeltaTotalMessagesSent" BIGINT , "DeltaRefreshTime" BIGINT , "RateTotalBytesReceived" DOUBLE , "RateTotalBytesSent" DOUBLE , "RateTotalMessagesReceived" DOUBLE , "RateTotalMessagesSent" DOUBLE ) IN "USERSPACE1" ; CREATE INDEX "rtvts_ocm_extendconnections" ON "OCM_EXTENDCONNECTIONS" ("TIME_STAMP"); CREATE INDEX "rtvpk_ocm_extendconnections" ON "OCM_EXTENDCONNECTIONS" ("Connection","Location","name","UUID","RemoteEndpoint","TIME_STAMP"); CREATE TABLE "OCM_PROXYSERVICESTATS" ( "TIME_STAMP" TIMESTAMP , "name" VARCHAR(100) , "Location" VARCHAR(100) , "RequestPendingCount" BIGINT , "Connection" VARCHAR(100) , "ConnectionCount" INTEGER , "OutgoingByteBacklog" BIGINT , "DeltaTotalBytesSent" BIGINT , "DeltaTotalBytesReceived" BIGINT , "DeltaRefreshTime" BIGINT , "RateTotalBytesSent" DOUBLE , "RateTotalBytesReceived" DOUBLE ) IN "USERSPACE1" ; CREATE INDEX "rtvts_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS" ("TIME_STAMP"); CREATE INDEX "rtvpk_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS" ("Connection","Location","name","TIME_STAMP"); CREATE TABLE "OCM_PROXYSERVICETOTALS" ( "TIME_STAMP" TIMESTAMP , "Connection" VARCHAR(100) , "name" VARCHAR(100) , "ConnectionCount" INTEGER , "DeltaTotalBytesSent" BIGINT , "DeltaTotalBytesReceived" BIGINT , "RateTotalBytesSent" DOUBLE , "RateTotalBytesReceived" DOUBLE , "DeltaTotalMessagesSent" BIGINT , "DeltaTotalMessagesReceived" BIGINT , "RateTotalMessagesSent" DOUBLE , "RateTotalMessagesReceived" DOUBLE , "RequestPendingCount" BIGINT , "OutgoingByteBacklog" BIGINT ) IN "USERSPACE1" ; CREATE INDEX "rtvts_ocm_proxyservicetotals" ON "OCM_PROXYSERVICETOTALS" ("TIME_STAMP"); CREATE INDEX "rtvpk_ocm_proxyservicetotals" ON "OCM_PROXYSERVICETOTALS" ("Connection","name","TIME_STAMP"); See rtvapm/ocmon/dbconfig/*.sql for the example schema that pertains to your database.


19797: Added the Service Name as an index to proxy/extend caches

The Proxy / Extend Overview, Proxy /Extend Connections, and Proxy /Extend Detail displays have been enhanced to provide better drill down capabilities and additional information about alert state of Proxy Services and Extend Connections. As part of this change, the column "name" has been added to the history table OCM_PROXYSERVICESTATS as an index column. Users with existing database tables will need to alter their table to include this additional column. (Task 19690 also has caused changes to this table. See that release note for more information.) The new table structure (DB2 example) is: CREATE TABLE "OCM_PROXYSERVICESTATS" ( "TIME_STAMP" TIMESTAMP , "name" VARCHAR(100) , "Location" VARCHAR(100) , "RequestPendingCount" BIGINT , "Connection" VARCHAR(100) , "ConnectionCount" INTEGER , "OutgoingByteBacklog" BIGINT , "DeltaTotalBytesSent" BIGINT , "DeltaTotalBytesReceived" BIGINT , "DeltaRefreshTime" BIGINT , "RateTotalBytesSent" DOUBLE , "RateTotalBytesReceived" DOUBLE ) IN "USERSPACE1" ; CREATE INDEX "rtvts_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS" ("TIME_STAMP"); CREATE INDEX "rtvpk_ocm_proxyservicestats" ON "OCM_PROXYSERVICESTATS" ("Connection","Location","name","TIME_STAMP"); See rtvapm/ocmon/dbconfig/*.sql for the example schema that pertains to your database.


19864: Enhanced visibility of Status in Summary pages

The visibility of the Status text has been enhanced in the Single Cache -> Cache Summary and the Cache Service -> Single Service Summary displays.


Oracle Weblogic

19808: Location no longer wrong in ThreadPool, JdbcDatasource, JMSServer

A parsing bug that caused incorrect information in the ThreadPool, JdbcDatasource, and JMSServer caches has been fixed.


Solace

19627: New Extension - Solace Solution Package

A new extension, the Solace Solution Package (SOLMON), has been added. The Solace Appliance is an advanced messaging platform that allows customer applications to efficiently exchange messages over dedicated "VPN"s. SL's Solace Solution Package provides pre-configured alerts and dashboards to monitor current status and manage history for the Solace Appliance. This Solution Package can help operators avoid or detect many problems relating to configuration, topology, and performance. See the README.txt file included with the solmon package for configuration details.


TIBCO ActiveSpaces

19842: New Extension - TIBCO Active Spaces Solution package

A new extension, the Solution Package for TIBCO ActiveSpaces (TASMON), has been added. TIBCO ActiveSpaces is a distributed in-memory data grid for building highly scalable, fault-tolerant applications. The Solution Package for TIBCO ActiveSpaces is a plug-in application to RTView Enterprise Monitor that allows you to monitor the health and performance of TIBCO ActiveSpaces® instances and services in real-time. See the README.txt file included with the tasmon package for more details.


TIBCO BusinessWorks

19462: Update in the TRA microagent set to 300 seconds

The RTView plugin microagent for BW Monitor has an update setting which will cause it to re-read the Tibco deployment files on the specified period. This enables it to find engines that have been newly deployed or undeployed. The default update setting is now 300 seconds (5 minutes) and may be changed by editing the line "<arg>-update:300</arg>" in $TIBCO_HOME/tra/domain/<name>/plugin/BWAgentPlugin.hma.


19566: CPU% utilization no longer rounded to zero if ess than 1

BWMON 6.1 was modified to use EM's hawkmon solution package to collect host and process metrics. In the case of process CPU utilization (as displayed in BWMON's all engines table), hawkmon used the integer CPU utilization directly from hawk, whereas earlier versions of BWMON calculated %CPU from the CPU Time metric.The result is that BWMON 6.1 displayed zero % CPU when the actual percentage was less than 0.5, whereas older BWMON versions displayed a fraction. Hawkmon has been updated to calculate % CPU the same way previous versions of bwmon did, so the older behavior is now present in newer releases of bwmon.


19621: Sorting consistency improved on BW Table displays

The BWmon Server and Process tables are now sorted initially by the item they display, like the Engines table. The order of Activities in the table is left as it comes from the source.


19802: BW versions no longer read incorrectly on certain BW servers

In certain cases the BW Monitor Servers data would include the incorrect BW Version, i.e., when there are additional BusinessWorks plugins installed in the BW server. This has been fixed.


19809: BW Process history table now disabled by default

By default BW Monitor will no longer save historical BW Process data to the database. To enable the collection of historical BW Process data find the following section in rtvapm.bwmon.properties and proceed as indicated. ########################## # HISTORIAN PROPERTIES # # By default we disable collection of historical data for Processes. # sl.rtview.sub=$BW_PROCESSES_TABLE:'' sl.rtview.sub=$BW_ACTIVITY_TOTALS_TABLE:'' # # To enable this, copy the following two lines into your local properties and uncomment them: # #sl.rtview.sub=$BW_PROCESSES_TABLE:BW_PROCESSES #sl.rtview.sub=$BW_ACTIVITY_TOTALS_TABLE:BW_ACTIVITY_TOTALS


19850: Default server expiration time raised to 300 seconds

The default value for $bwserverExpirationTime has been raised to 300 (seconds), so as to be less sensitive to network delays, variance in system clocks, etc. To change this value copy the following line into your local properties and edit it: sl.rtview.sub=$bwserverExpirationTime:300


19851: Flashing "expired" status fixed

Under some conditions in a multi-dataserver environment, a BW Server that was expired would cycle between expired and unexpired in the displays. This has been corrected.


TIBCO EMS

19316: Enhanced visibility of Last Data Time in the Server Summary page

The visibility of the Last Data Time text has been enhanced.


19544: Improve visibility of Consumer ID from EMS Consumer Summary

The Consumer ID field on the EMS Consumer Summary display will now resize correctly.


19815: Disabled Connections/Consumers/Producers tables in history

By default EMS Monitor will no longer save historical EMS Connections, Producers, and Consumers data to the database. To enable the collection of this historical data find the following section in rtvapm.emsmon.properties and proceed as indicated. ########################## # HISTORIAN PROPERTIES # # By default we disable collection of historical data for these tables: # sl.rtview.sub=$EMS_CONNECTIONS_TABLE:'' sl.rtview.sub=$EMS_PRODUCERS_TABLE:'' sl.rtview.sub=$EMS_CONSUMERS_TABLE:'' # # To enable history for them, copy any of the following three lines # into your local properties and uncomment them: # #sl.rtview.sub=$EMS_CONNECTIONS_TABLE:EMS_CONNECTIONS #sl.rtview.sub=$EMS_PRODUCERS_TABLE:EMS_PRODUCERS #sl.rtview.sub=$EMS_CONSUMERS_TABLE:EMS_CONSUMERS


Version 1.5.0 Release Notes

Configuration

18822: Enabled purging of stale data for display server

To improve the performance of the display server, the property sl.rtview.staledatapurgerate has been enabled.


19612: Properties file cleanup

The properties files for each Solution Package have been simplified to contain the minimum set of properties to provide functionality. Examples of properties files for customization are provided on each sample directory.


Logging

19450: Log4j diagnostic console statements removed

Some diagnostic messages containing "Log4j is not yet initialized" were removed.


Metric Explorer

19334: New Metric Explorer

RTView EM has been enhanced with a new feature called the Metric Explorer. RTView EM provides many out of the box displays which show performance metrics of various components of an application stack. However sometimes the pre-defined views of data do not encapsulate all the related information that a user needs to analyze. The Metric Explorer allows you to configure Views showing up to 5 CI metrics in a trend graph. These configured Views can be named and saved and then available to use as a list of predefined configurations to bring up to examine the real time historical information. Running the Metric Explorer: The emsample application has been updated to contain the Metric Explorer. To access it, navigate to Metric Explorer->Metric Explorer. To view an already configured view, select it from the View list. To add, edit or delete Views, click on the Edit (pencil) button to open the Edit Pane. Navigate through your CMDB in the Service Tree and select the Service that contains the CI with the metric you want to add to your view. Once you have selected a Service, the Metric Tree will populate with the available metrics for the selected Service. Add up to 5 metrics to your view and save it. When you are finished adding or editing your view, click on the Done button to hide the Edit Pane. Views that have the Share View with Others checkbox selected will be available to all users when the Shared Views option is selected. Views that do not have the Share View with Others checkbox selected will only be available to you. You can also access the Metric Explorer from the following Service Summary Views: - Service Summary Views->Service By CI Type - Service Summary Views->Service Summary - Service Summary Views->Service Browser The MX button and the table context menu in these displays will take you to the Metric Explorer Edit Pane with the selected Service already selected in the Service Tree. If you have a CI Type or CI selected, it will also be selected in the Metric tree. This makes it easy to create a new View for the selected service. Configuration: 1. If you are using a database other than the hsqldb database included in emsample\DATA, you will need to do the following: - add a database connection named RTVMX that points to the database you will use to store your Views by overriding the following property: ConfigCollector.sl.rtview.sql.sqldb=RTVMX sa - jdbc:hsqldb:hsql://localhost:9099/rtvmx org.hsqldb.jdbcDriver - false true - use the schema in the appropriate file under rtvapm\mx\dbconfig to create the RTVMX_VIEW_TABLE and RTVMX_METRICS_TABLE in your RTVMX database 2. If you are updating an existing application instead of starting with the emsample application, do the following in addition to #1: - Add the following to rtview.properties in the directory where you are running the central EM servers: rtvapm_package=mx - Add the following to your navigation tree: <node label="Metric Explorer" mode="" display="mx_dir"> <node label="Metric Explorer" mode="" display="rtv_mx_view"/> </node> 3. The Service Tree in the Metric Explorer Edit Pane is filtered by the following login substitutions: $rtvOwnerMask, $rtvAreaMask, $rtvGroupMask, $rtvServiceMask. Limitations - When you save a view, RTView writes to both the view table and the metrics table when you save even if only one or the other changed. - When you save a view, the UI temporarily reverts back to the previous version for one update, then updates with the latest changes. - The search button will fail without an error if the service that was selected when you initially added the metric is no longer in your CMDB. To fix this, delete the metric and add it again from a service that is currently in your CMDB. NOTE: The missing service will only make the search button fail. It will not cause any problems with the viewing the metric. - When you try to add a metric to a view that already contains that metric, it will not be added again. In the viewer, an error message will come up saying that the metric is already in the view. In the thin client, no error is shown. - Views are limited to 5 metrics. Once a view contains 5 metrics, the Add Metric button is disabled. - There is no indicator that the database or config server (which is the server connected to the database) if offline. This means that you could edit a view, save and lose your changes. - By default, the metric explorer attaches to the history_combo table for the metric history. If the cache is not configured with a history_combo table, the metric explorer will instead make a one-time attachment to the history table. In this case, toggling the Log Scale checkbox will cause all points plotted after the initial history query to be lost. On the next update of current data a straight line will be drawn from the last history point to the new current data point.


Monitor

19615: Extraneous navtree file removed

Some inconsistencies from the EM sample directory have been removed. In particular, the navigation tree under emsample\servers\ocmon has been removed.


19617: Removed war files for packages in miscmon

War files from Solution Packages that are used under the miscmon data server have been removed from the deliverable.


RTVMGR

19593: Readability improvements for RTView Servers views

In the RTVMGR, the Function Stats button in on the "Data Servers" and "Display Servers" displays has been enlarge to better present well on various browsers.


RTView Core

Alerts

19141: alertExpireMode added to event alerts

Event Alerts have been enhanced with a new property, alertExpireMode. This property supports 2 options: - Initial Time - if selected and the alertExpireTime is greater than 0, the alert will clear if the alertExpireTime has passed since the alert was generated. - Last Update Time - if selected and the alertExpireTime is greater than 0, the alert will clear if the alertExpireTime has passed since the alert received a data update Note that only indexed event alerts can receive data updates, so the Last Update Time option will not work for unindexed event alerts.


19291: Cleared event alerts no longer regenerated in ssa

In previous releases, event alerts that did not have a mapping for Cleared in the valueTableMap were erroneously regenerated after being cleared when running with Self Service Alerts enabled. This has been fixed.


19292: unindexed event alerts can't be disabled in ssa

In previous alerts, unindexed event alerts could not be disabled using Self Service Alerts. This has been fixed.


19714: Sybase schemas corrected

Errors have been corrected in two sql scripts: RTV\dbconfig\alert_persist\createtables_sqlserver.sql demos\selfservicealerts\dbconfig\createtables_sybase.sql


Commands

18643: japanese chars no longer garbled by "Send Email" command

The email command will now properly encode Japanese and other Asian characters contained in the text of the email. In prior release, such characters were garbled.


Data Sources

19164: Cache data source now reports missing config file

The cache data source will now generate an error message if a cache definition file cannot be loaded. For example, if a cache definition file named MyCaches,rtv is specified in CACHEOPTIONS.ini but the file does not exist then the following error message will be printed to the console: ERROR: can't load cache definition file MyCaches.rtv, file not found. In previous releases, no message was printed if a cache file could not be loaded.


19216: Added per-index row limit to cache history table

To allow more control over the number of rows stored in a cache history table, a new property named maxNumberOfRowsPerIndex has been added to the cache table object (obj_cachetable). In the Builder's property sheet, the new maxNumberOfRowsPerIndex property appears in the Cache History Table category. The property is visible only if the cache's maxNumberOfHistoryRows value is greater than zero. (Otherwise the cache does not have a history table). If a positive number N is assigned to maxNumberOfRowsPerIndex, then the cache's history table will contain at most N rows for each unique combination of the cache's index column values. For example if a cache has one index column named Server and maxNumberOfRowsPerIndex is 500, then the cache's history table will contain no more than 500 rows for each unique name in the cache's Server column. If the cache's condenseRowsFlag is set, then the maxNumberOfRowsPerIndex limit is applied to the cache's history_condensed table. If the cache's condenseRowsCombineHistoryFlag is also set, then the maxNumberOfRowsPerIndex limit is also applied to the cache's history_combo table. To reduce overhead, a cache's maxNumberOfRowsPerIndex is checked only once per minute or, in the case of the history_condensed table, at the condense interval, whichever is less frequent. This means that the maxNumberOfRowsPerIndex may be exceeded until the next time the limit is checked. By default the value of maxNumberOfRowsPerIndex is blank, meaning that no per-index limit is applied to the cache's history tables. With the addition of the maxNumberOfRowsPerIndex property the cache history table size is now controlled by 3 properties: 1. If the historyTimeSpan property is set, the cache trims its history table by removing rows with timestamps that are older than the limit, 2. Next, if the cache's history table exceeds the maxNumberOfHistoryRows limit (which must be > 0 for the cache to store any history), then the oldest rows are removed from the history table to satisfy the limit. 3. Next, if the cache's maxNumberOfRowsPerIndex limit is set then it is applied as described above.


Distribution

19692: Core version removed from derivative releases

Due to changes in the build procedures for Enterprise Monitor, BW Monitor, EMS Monitor, and OC Monitor, there is no longer a separate Core version number. The console and About dialogs have been updated to reflect this change. A Build Number has been added to the configuration information in order to identify the build from which a release was generated. The RTView Info function has been modified to reflect this change. Previously, the RTView Version Info argument returned a table with EM version information and the Product Version Info argument returned a table with Core version information. Since there is now only one version, both arguments now return the same thing which is the table previously returned by the Product Version Info argument.


Functions

19150: Warning if subst string arg to SetSub function contains spaces

An error message will now be logged if the Substitution String argument to the Set Substitution function contains spaces. Spaces are not permitted in substitution strings and will likely cause parsing problems elsewhere in RTView, particularly in the thin client. If a function named F has its Substitution String argument set to "$A B" the following error message will be generated: ERROR: function <F>, substitution string $A B contains space To avoid breaking existing configurations that may already define substitution strings with spaces and are working in spite of the potential parsing problems, the function will still define the substitution including any space characters, but will generate the error message. Note that spaces are allowed in the Value argument of the Set Substitution function. That has always been the case and is not affected by this task.


19331: Pivot on Unique Values function upgraded to accept multiple index columns

The Pivot On Unique Values function has been enhanced so that it accepts multiple column names as the Key Column parameter. When multiple column names are used, separated by semicolon, it groups the results by unique occurrences of the combined values of all columns. When only one column is specified, the behavior is the same as before.


19557: Ensure Columns now allows a single value with semi-colons if only one column

The Ensure Columns function has been enhanced to support semi-colons as literals in the Value(s) argument under the following circumstances: 1. There is only one value in the Column(s) argument. 2. The Value(s) argument is enclosed in single quotes. If those conditions are not met, the semi-colon is assumed to be a delimiter for multiple values.


Object Library

15035: Image property added to Button Control

The button control (ob_c1button) now supports an Image property. A button can display an image, a label, or both. If both the image and label are set, the image will be to the left of the label. (This order is not configurable). This feature is supported in the viewer and thin client. However the appearance can vary slightly between the viewer and the various supported browsers. When displayed in the viewer and different browsers, you may notice differences in the following: 1. Alignment of the image inside the button: The image may be somewhat closer to the top or bottom edge of the button 2. Vertical alignment of the image with the button's label, if any: The center of the image may be somewhat lower or higher than the center of the label 3. Appearance of the image and label if they don't fit inside the button: In some cases the label may be clipped with a "..." replacing the clipped text, or the label may be clipped with no indication, or the label may wrap and may extend below the button. It is best to leave several pixels of padding between the image and/or label of a button to avoid wrapping or clipping of text in all browsers. Also, check the button appearance in all browsers you intend to support. In Firefox, a button with an image will not depress when it is clicked. However the button's command will still be invoked. In iOS Safari, if the image property is set on a small button (32 pixels or less in width) the button will have square corners rather than rounded corners.


18167: FX Graphs traceNVisFlag now work even if there is no data

Previously there was a bug with FX Graphs where un-checking the traceNVisFlag did not have an affect unless it was attached to data. This has been fixed.


18873: Corrected behavior of listValues property of a ComboBox or a ListBox

A problem has been fixed that prevented the items listed in a combo box or list box control from updating when a new string was assigned to the control's listValues property.


19454: HTML5 chart basic support

BASICS: The html5 trend chart is a pure HTML implementation of an RTView trend graph object. In the RTView thin client, the html5 trend chart provides an interactive, high performance trend chart without requiring the Flash player or other browser plugin. There is no html5 trend chart in the Builder palette. Instead, a new property named webChartFlag has been added to the flex (obj_fxtrend) and swing (obj_trendgraph02) trend graphs. To enable the html5 trend chart the user simply sets the webChartFlag property to true (checked) on a flex or swing trend graph instance. Then, when the display is opened in the thin client in an HTML5 compatible browser, the html5 trend chart will appear in place of the flex or swing trend graph. REQUIREMENTS: Firefox, iOS Safari, and Internet Explorer version 9 or newer support HTML5 and will display the html5 trend chart on displays where enabled. Internet Explorer version 8 and older do not support HTML5 so in those browsers the flex or swing trend chart will be used regardless of the value of the webChartFlag property. PROPERTIES: The html5 trend chart supports all of the major properties available in the flex and swing trend graphs. However several minor properties are not supported or have limited support in the html5 trend chart, as follows: - background styles: Not supported. Except for the bgColor property, none of the background style properties are supported. This includes the properties whose names begin with bg, traceBg, and border. - gradients: Gradient fill is not supported, so none of the properties named *GradientStyle, *GradientMode, or *GradientFlag are supported. - markDefaultSize, markScale: Not supported. These default to 6 and No Scale. The markers for each trace can be configured with the traceNMarkStyle/Color properties. - traceNMarkStyle: The markers for trace N can be enabled by setting traceNMarkStyle > 0 but the shape of the markers (circle, square, triangle, etc) is selected automatically. - traceNType: Supported types are Line and Bar. Event type is not supported. - legendWidthPercent, legendValueMinSpace: Not supported. The legend (if visible) is sized automatically. - scrollbarMode/Size, zoomEnabledFlag: Not configurable. The scroll and zoom features are always enabled and the scrollbar size is fixed. - traceFillStyle: Supported values are None and Transparent. All other values (Solid, Gradient, Transparent Gradient) are converted to Transparent - x/yAxisMajor/MinorDivisions: Not supported. The number of ticks on the x & y axis are selected automatically according to the size of the chart. - yAxisPostion: Not configurable. The y axis position is always outer-left. - yAxisAutoScaleVisTracesOnlyFlag: Not configurable, always true. - x/yAxisFlag, x/yAxisThickness: Not configurable. The x and y axes are always visible with a thickness of 1 and 2 pixels, resp. - traceGroupNBandedFlag: Not supported. Trace groups are supported but banding within groups is not. - alert properties (valueHighAlarm*, valueLowAlarm*, valueHighWarning*, valueLowWarning*): The html5 chart supports one alert threshold per chart. If more than one alert threshold is enabled, the html5 chart will not be used. Also, the alert TraceColor is used only if the traceFillStyle is None. For any other traceFillStlye the alert TraceColor is ignored. The alert TraceStyle, Mark, and MarkColor are ignored. The alarmGlowFlag is not supported. The properties marked as Not supported or Not configurable in the list above will not appear in the Builder's property sheet when a trendgraph object is selected and webChartFlag is checked. In some cases if the properties listed above have been configured on a flex or swing trendgraph instance, then the webChartFlag property will be automatically set to false and hidden in the property sheet, because the html5 trend chart does not support those features. This occurs if any traceGroupNBandedFlag is checked, if more than one alarm threshold is enabled, or if the alarmGlowFlag is checked. Are any new properties supported? The html5 trend chart supports two additional properties that are only visible in the property sheet if webChartFlag = true. - webChartNavigatorTrace: If this property is set to a trace number (a value between 1 and the traceCount value) the html5 chart will display a "time navigator" at the bottom of the chart, just below the x (time) axis. The navigator plots the data for the indicated trace, and highlights the time range that is currently visible in the chart. The highlighted section can be resized or dragged to perform a time zoom or scroll. The navigator is intended to show the user the entire data set and let the user zoom/pan to the time range of interest. By default webChartNavigatorTrace = 0 so the navigator is disabled. - yAxisAutoScaleVisDataOnlyFlag: If this property is checked the chart will compute the y axis scale according to the min & max y values of the visible data points only. This means that the y axis scale may change as the user changes the visible time range by scrolling or zooming. By default the property is unchecked and the y axis is scaled according to the y values of all of the data points, visible or not, which matches the behavior of the swing and flex trendgraphs. The Builder does not allow the webChartFlag property to be attached to data. This is by design, since the flag's value is expected to be constant. BEHAVIOR: In addition to the properties listed above, there are some behavioral differences between the html5 trend chart and the flex/swing trend graph as follows. - Legend: The legend does not show trace point data (y) values. Data values are only shown in the mouseover tooltips (if cursorFlag = 1). The cursor always snaps to the nearest data point, it does not show interpolated values between data points. Trace labels longer than 200 pixels are wrapped in the legend, and labels longer than 150 pixels are clipped in the tooltip. - Y axis autoscaling: Given the same y data values, the html5 trend chart may choose a different value range for the y axes in autoscale mode as compared to the other trendgraphs, because somewhat different algorithms are used. - Reset button: If the user changes the chart's visible time range, via the scrollbar or navigator or by dragging the cursor to perform a zoom, then a button labeled Reset will appear in the upper left corner of the plot area. A click on this button will reset the time axis to its original settings. The chart will also resume shifting to show the newest trace points, unless the timeRangeBegin/End properties are set. - Data point grouping: The html5 trend chart makes use of a feature known as data grouping to enhance performance when a trace has many data points. With data grouping, the chart plots a single point using the average y value in cases where otherwise multiple points would be plotted on the same x pixel coordinate. When data grouping is in effect, the chart's tooltip will display a start time and end time (rather than the usual single time value) to indicate the time range of the averaged data points, for example: 05-Mar 12:35:00 ~ 05-Mar 12:45:00 [Notes: The data point grouping feature is enabled automatically and is not configurable. Also data gropuing is performed independently of (and possibly in addition to) any data condensing or compaction that has already been applied by the RTVuew cache data source or the historian. Also the maxPointsPerTrace property (3200 in the test1 display) is applied to the raw data, before any data grouping is applied.} The legendTimeFormat is used to format the date/time strings in the tooltip. If that property is blank then the timeFormat property is used instead, but if the string contains a newline it is replaced with a space character to avoid making the tooltip overly tall. - timeShift: The html5 trend chart does not attempt to keep the tick marks on the time axis aligned on even multiples of the timeShift value, in the case where timeShift > 1. ENABLING / DISABLING: The html5 trend chart can be enabled for all obj_fxtrend (flex) instances by adding the following rule to an rtview stylesheet (.rts) file loaded by the display server: obj_fxtrend { webChartFlag : 1 } Similarly, the html5 trend chart can be enabled for all obj_trendgraph02 (Swing) instances by the following rule: obj_trendgraph02 { webChartFlag : 1 } See the documentation for more information on using RTView stylesheets. If a stylesheet is used note that the webChartFlag value can still be overridden and set to zero (false) on individual instances. Also, even if webCharFlag is set on all instances, the flex or Swing trendgraph will still be used if a display is opened in Internet Explorer 8 or older, or if certain properties not supported by the html5 chart (as listed above) are configured on a specific trendgraph. To disable the html5 trend chart globally, regardless of the webChartFlag value on individual objects, specify the -nohtml5 argument on the display server command line, or use the equivalent property. Alternatively, add the following line to the rtvdisplay.properties file then rebuild and deploy the rtvdisplay.war file: HTML5Enabled=false Finally, the html5 chart can be disabled in a specific browser window by appending nohtml5=true to the URL, for example: http://myserver/rtvdisplay/getdisplay.jsp?display=test1&nohtml5 http://myserver/rtvdisplay/panels.jsp?file=myapanels.xml&nohtml5 KNOWN ISSUES/LIMITATIONS: - After zooming or scrolling, the time axis labels may briefly be misaligned or overlap. They should be drawn correctly on the next refresh. - The chart's tooltip may overlap the Reset button making it difficult to click the button. Moving the mouse a bit will correct this problem. - Like the flex chart, the web chart will display all timestamps using the local time zone. This may cause user confusion if the display server is in a different time zone. - Performance is affected by the number of traces, trace points, use of trace line shadows, trace line thickness, trace markers, trace fill, and other properties. Performance is also affected by the browser and version, and the CPU speed of the client host system. - If any of the chart's graphical properties are changed while the chart is displayed (eg. the traceFillStyle is toggled via a checkbox control) the chart is rebuilt in the thin client, which in turn resets the chart's time range (as though the Reset button was clicked). - Scrolling: If the mouse is moved below the bottom of the chart while dragging the scrollbar, the scrolling will stop. This is unlike the behavior of other rtview objects, which will continue to scroll until the mouse button is released. - Drilldown from trace points: If traceFillStyle is not "None" (i.e. trace fill is enabled) and multiple traces share the same Y axis, then it is not possible to click on a point belonging to trace N if the fill area of a higher numbered trace is drawn over that point. - When yAxisLogFlag = 1 and the chart has multiple y axes and traces, some y axis labels may show ??? rather than numeric values. This is rare. - Since the html5 trend chart does not support legendWidthPercent, the width of each chart's legend will vary according to the trace labels. This makes it difficult to create multiple trend chart instances on the same display whose time axes are all the same length, even if the charts all have the same width. (A single chart in stripchart mode may be more appropriate in those cases). - On a touch interface, a swipe will scroll the chart left or right. To move the cursor without scrolling, tap the location to which you want the cursor to move. - On a touch interface, a pinch-open gesture in the plot area, scrollbar, or navigator will zoom the chart's range in to the pinched range. A pinch-close gesture will zoom out to the pinched range. The pinch-close operation may be difficult to use. A tap on the Reset button gives a better zoom-out experience. MISC: Here is a complete list of the obj_fxtrend properties that are hidden if webChartFlag is checked: legendBgGradientFlag legendWidthPercent markDefaultSize traceBgColor traceBgGradientFlag traceGroupNBandedFlag (for each trace N) yAxisAutoScaleVisTracesOnlyFlag yAxisThickness yAxisPosition yAxisFlag xAxisFlag yAxisMajor/MinorDivisions xAxisMajor/MinorDivisions xAxisThickness Here is complete list of the obj_trendgraph02 properties that are hidden if webChartFlag is checked: borderPixels labelMinTabWidth legendWidthPercent legendBgGradientMode legendBgGradientColor2 legendValueMinSpace markDefaultSize markScaleMode outlineColor scrollbarMode scrollbarSize zoomEnabledFlag timeRangeOfHistory traceBgColor traceBgGradientMode traceBgGradientColor2 traceBgImage yAxisAutoScaleVisTracesOnlyFlag yAxisFormat yAxisFlag yAxisPosition yAxisValueLabels yAxisMajor/MinorDivisions xAxisFlag xAxisMajorDivisions For each trace N: traceNValueAlarmStatus traceNValueAlarmStatusTable traceNValueHistoryFlag traceGroupNBandedFlag traceNYAxisGridVisFlag traceNYAxisMinLabelWidth traceNYAxisValueLabels traceNYAxisVisFlag traceNYAxisAutoScaleMode traceNYAxisValueMin traceNYAxisValueMax


19503: Fixed builder crash on save when display contains composite with tabular local vars

A problem has been fixed that caused the Builder to throw a ClassCastException if a display contains a composite whose subdisplay creates a tabular local variable.


Platform Support

19592: Support Chrome as a broswer for the thin client

The thin client is now supported in Chrome, on Windows. The version tested was Chrome 35.0. Chrome was not tested on iOS or Android.


Viewer - Applet

19308: Support applets in Java 1.7 with all permissions.

In previous releases, the Registration and Viewer Applets failed to run using Java 1.7 due to a security error. This has been fixed. The Registration and Viewer jars have been enhanced to include the Application-Name and Permissions parameters in their meta-data in order to pass the Applet security check. Note that the Viewer applet Permissions parameter is set to all-permissions. The Registration applet Permissions parameter is set to sandbox.


Scripts

19203: Windows service scripts provided for em apps

EM servers, dataservers, display servers, etc. may now be installed as Windows services using the new install_service.bat script (in RTVAPM_USER_HOME/bin) as follows: install_service appName -service:serviceName where "appName" is ConfigServer, AlertServer, DisplayServer1, AlertHistorian, or dataserver The current directory will be used for the server startup directory. For example: To install the ConfigServer as a service named myConfigServer: First ensure it is not running, then cd to its startup directory (e.g. RTVAPM_USER_HOME/servers/central) and issue the command install_service ConfigServer -service:myConfigServer To install the emsmon dataserver as "myEmsServer" you would cd to servers/smsmon and issue the command install_service dataserver -service:myEmsServer You may append arguments such as -properties and -propfilter as needed by the given server, e.g. install_service dataserver -service:myEmsServer -properties:myproject -propfilter:sender The service is started when it is installed and amy subsequently be started and stopped via the Windows service manager. The service may be uninstalled with just its service name, e.g. uninstall_service dataserver -service:myEmsServer It will be stopped before it is uninstalled.


Solution Package

19355: Corrections to various discrete alert definitions

Discrete alert types in the db2mon, oramon, tbemon, and vmwmon solution packages previously set the alert severity incorrectly. This error caused a number of screens to malfunction when displaying severity for either a CI Type or aggregated across components of a service. (These alerts display an odd "infinity" symbol in the Warning Level column.)


Host Infrastructure

18440: New extension - RTView EM Host Agent (HOSTMON)

A new extension, RTView EM Host Agent (HOSTMON), has been added. The Host Agent for RTView Enterprise Monitor collects CPU, network, storage, and process metrics for Linux, Solaris, Mac, and Windows hosts. The agent may also be configured to tail log files and forward selected entries to EM. The agent is not polled by EM; instead, the agent collects and pushes metrics at a rate specified in the agent.properties file. See the README.txt file included with the hostmon package for more details.


IBM DB2 Database

19375: Column names shortened in DB2_SNAPDB table

Two columns in the Db2SnapDb cache (db2mon) had columns longer than 30 characters in length. Attempts by the historian to persist this cache to an oracle history database resulted in SQL errors. This problem was resolved by shortening the column names in Db2SnapDb. Customers with existing database tables should rename the following two columns in the DB2_SNAPDBM table: DEADLOCKSANDLOCKTIMEOUTSPERKTRANSACTION is now DEADLOCKSLOCKTIMEOUTSPERKTRAN DIRTYSTEALTRIGGERSPERKTRANSACTION is now DIRTYSTEALTRIGGERSPERKTRANS


Oracle Coherence

19448: Single Cache Summary trends now displayed correctly

In previous versions, under certain circumstances, data for the Trend Graphs were not displayed correctly. This is no longer the case.


19610: Fixed Proxy/Extend Connections trend

The Proxy Services -> Proxy / Extend Connections display has been improved to prevent some errors in the trend graphs. Alert Level has been also added to the two tables that show Proxy and Remote End Point information. Alert Level has been also added to the two tables shown in Proxy Services -> Proxy / Extend Detail display.


19611: Enhanced Proxy/Extend Client Heatmap

The Proxy Services -> Proxy / Extend Overview has been enhanced to be driven through four more metrics: Alert Severity, Alert Count, Bytes Backlog, and Proxy Bytes Backlog. Total metrics have been removed from the Metric drop down. Now from the heatmap one can drill down to the Proxy Services -> Proxy / Extend Connections display.


19623: Updated all displays with new resizing behavior

Six OCM displays were modified so that when they are stretched vertically the upper and lower data display elements (heatmaps, bar charts, etc) resize equally. Prior to this change only one of those elements would resize, with the other remaining at the initial height. The six displays are: Cluster Views -> All Services History Cluster Views -> All Nodes History Cache Services -> Service Metric Heatmap Cache Services -> Single Service History All Caches -> Current Activity Chart All Nodes -> Communication Issues


19625: Modified trend colors

The colors of certain displays have been modified to improve their readability.


19689: Two new alerts for proxy/extend backlog

Two new limits alerts OcExtendConnectionByteBacklogHigh and OcProxyNodeByteBacklogHigh have been added to the OCMON alerts set. These alerts are associated to Extend Connections and Proxy Node respectively.


Oracle Database

19282: ORAMON can now be configured to accept data from OEM

Oracle Database Monitor (oramon) can now be configured to accept data from Oracle Enterprise Manager (OEM) by way of the new Oracle Enterprise Monitor Connector (OEMCON). See the README.txt files for oramon and oemcon for more information


Oracle Enterprise Manager

19289: New extension - Oracle Enterprise Monitor Connector

A new extension, Oracle Enterprise Monitor (OEM) Connector (OEMCON), has been added. The connector package OEMCON listens for data exported from OEM via JMS. OEMCON parses each JMS message and stores the data into the OemMetricsData intermediate cache. From there, it is reformatted and stored in caches for the Oracle Database Monitor (ORAMON) and HOSTBASE solution packages, which handle basic display and alerting functions for hosts and databases. See the README.txt file included with the oemcon package for configuration details.


19421: Integrate Coherence Network Information With Hostmon Network Information

A new display ( Network/TCMP History Heatmap / oc_host_nic_tcmp_history_heatmap.rtv ) has been made available so that related Host Data and Coherence data can be provided on the same display to facilitate recognition of correlations between the two sets of data Different metrics can be selected for display in each data set, displayed as a history heatmap, for a user selected time range. In this display the data is Network Card Data, and aggregated Coherence network statistics from nodes, displayed by host. Selecting a Host for a data set will drill down to a more detailed display for the selected entity. CONFIGURATION The display requires a configured EM system that collects metrics about a Coherence Cluster, via an OCM data server, and hosts metrics from the corresponding hosts via a hostmon data server. These data servers are identified by the named data server connections, using the substitution variables $OC_HOST_DS for the OCM data server, and $OC_HOST_DS for the hostmon dataserver. The substitution variables are initialized to the default ?out of the box? values for the named dataserver connections used in the default emsample EM project, thus: $OC_HOST_DS=MISCMON-LOCAL $OC_OCM_DS=OCMON-LOCAL If non default values have been used for the named data servers, then the substitution variables will need to be set to the correct non-default values for the display to function correctly. The display is commented out by default in the sample em navtree file (servers/central/rtv_appmon_navtree.xml), under the commented out ?Coherence Hosts? section so it will need to be uncommented if is required to be displayed in the nav tree. USAGE The display has two history heatmaps. The upper history heatmap, labeled ?Host Network?, displays Network (Rate) Metrics over a user selected time range. Each row in the history heatmap represents a host on which coherence nodes for the cluster are present. The ?Network Metric:? Dropdown allows the selection of a given metric to be used as the value plotted in the history heatmap (higher values of the metric are displayed as darker colors in the heatmap) The Values of the metrics, together with the timestamp for the selected host are displayed in the pop-up mouse over, when a cell in the heat map is moused-over. The lower history heatmap, labeled ?Host Nodes?, displays Network (Rate) Metrics over a user selected time range. Each row in the history heatmap represents a host on which coherence nodes for the cluster are present. The ?Node Metric:? Dropdown allows the selection of a given metric to be used as the value plotted in the history heatmap (higher values of the metric are displayed as darker colors in the heatmap) The values of the metrics, together with the timestamp for the selected host are displayed in the pop-up mouse over, when a cell in the heat map is moused-over. The values represent the average metric rates for all nodes on the given host, for the timer period represented by the cell. The ?Enable MouseOver? Check Box can be used to enable or disable the display of pop-up mouse overs The ?Log Scale? Check Box can be used to display the metrics in a Log scale or a linear Scale. The ?Range? Drop Down can be used to select the time range over which values are plotted in the history heatmaps. The [?] Button can be used to select a non-current date and time for the rightmost values displayed in the history heatmap The Labels at the base of the display show the start and end timestamps of the data displayed in the heatmaps.


19423: Integrate Coherence Service Metrics With Hostmon CPU Information

A new display ( Coherence Host/Service History Heatmap / oc_host_task_history_heatmap.rtv ) has been made available so that related Host Data and Coherence data can be provided on the same display to facilitate recognition of correlations between the two sets of data Different metrics can be selected for display in each data set, displayed as a history heatmap, for a user selected time range. In this display the data is Host Performance data and aggregated Coherence Cache Service statistics from nodes, displayed by host. Selecting a Host for a data set will drill down to a more detailed display for the selected entity. CONFIGURATION The display requires a configured EM system that collects metrics about a Coherence Cluster, via an OCM data server, and hosts metrics from the corresponding hosts via a hostmon data server. These data servers are identified by the named data server connections, using the substitution variables $OC_HOST_DS for the OCM data server, and $OC_HOST_DS for the hostmon dataserver. The substitution variables are initialized to the default ?out of the box? values for the named dataserver connections used in the default emsample EM project, thus: $OC_HOST_DS=MISCMON-LOCAL $OC_OCM_DS=OCMON-LOCAL If non default values have been used for the named data servers, then the substitution variables will need to be set to the correct non-default values for the display to function correctly. The display is commented out by default in the sample em navtree file (servers/central/rtv_appmon_navtree.xml), under the commented out ?Coherence Hosts? section so it will need to be uncommented if is required to be displayed in the nav tree. USAGE The display has two history heatmaps. The upper history heatmap, labeled ?Coherence Hosts?, displays Host Performance Metrics over a user selected time range. Each row in the history heatmap represents a host on which which coherence cache services for the cluster are present. The ?Host Metric:? Dropdown allows the selection of a given metric to be used as the value plotted in the history heatmap (higher values of the metric are displayed as darker colors in the heatmap) The Values of the metrics, together with the timestamp for the selected host are displayed in the pop-up mouse over, when a cell in the heat map is moused-over. The lower history heatmap, labeled ?Coherence Service?, displays (Coherence Cache) Service (Rate) Performance Metrics over a user selected time range. Each row in the history heatmap represents a host on which coherence cache services for the cluster are present. The ?Service Metric:? Dropdown allows the selection of a given metric to be used as the value plotted in the history heatmap (higher values of the metric are displayed as darker colors in the heatmap) The values of the metrics, together with the timestamp for the selected host are displayed in the pop-up mouse over, when a cell in the heat map is moused-over. The values represent the average metric rates for all (cache service, node) combinations on the given host, for the timer period represented by the cell. The ?Enable MouseOver? Check Box can be used to enable or disable the display of pop-up mouse overs The ?Log Scale? Check Box can be used to display the metrics in a Log scale or a linear Scale. The ?Range? Drop Down can be used to select the time range over which values are plotted in the history heatmaps. The [?] Button can be used to select a non-current date and time for the rightmost values displayed in the history heatmap The Labels at the base of the display show the start and end timestamps of the data displayed in the heatmaps.


19424: Integrate Coherence Service Metrics With Hostmon Network Information

A new display ( Network/Service History Heatmap / oc_host_nic_service_history_heatmap.rtv ) has been made available so that related Host Data and Coherence data can be provided on the same display to facilitate recognition of correlations between the two sets of data. Different metrics can be selected for display in each data set, displayed as a history heatmap, for a user selected time range. In this display the data is Host Network data and aggregated Coherence service statistics from nodes, displayed by host. Selecting a Host for a data set will drill down to a more detailed display for the selected entity. CONFIGURATION The display requires a configured EM system that collects metrics about a Coherence Cluster, via an OCM data server, and hosts metrics from the corresponding hosts via a hostmon data server. These data servers are identified by the named data server connections, using the substitution variables $OC_HOST_DS for the OCM data server, and $OC_HOST_DS for the hostmon dataserver. The substitution variables are initialized to the default ?out of the box? values for the named dataserver connections used in the default emsample EM project, thus: $OC_HOST_DS=MISCMON-LOCAL $OC_OCM_DS=OCMON-LOCAL If non default values have been used for the named data servers, then the substitution variables will need to be set to the correct non-default values for the display to function correctly. The display is commented out by default in the sample em navtree file (servers/central/rtv_appmon_navtree.xml), under the commented out ?Coherence Hosts? section so it will need to be uncommented if is required to be displayed in the nav tree. USAGE The display has two history heatmaps. The upper history heatmap, labeled ?Host Network?, displays Network (Rate) Metrics over a user selected time range. Each row in the history heatmap represents a host on which nodes with coherence cache services for the cluster are present. The ?Network Metric:? Dropdown allows the selection of a given metric to be used as the value plotted in the history heatmap (higher values of the metric are displayed as darker colors in the heatmap) The Values of the metrics, together with the timestamp for the selected host are displayed in the pop-up mouse over, when a cell in the heat map is moused-over. The lower history heatmap, labeled ?Host Service?, displays (Coherence Cache) Service (Rate) Performance Metrics over a user selected time range. Each row in the history heatmap represents a host on which nodes with coherence cache services for the cluster are present. The ?Service Metric:? Dropdown allows the selection of a given metric to be used as the value plotted in the history heatmap (higher values of the metric are displayed as darker colors in the heatmap) The values of the metrics, together with the timestamp for the selected host are displayed in the pop-up mouse over, when a cell in the heat map is moused-over. The values represent the average metric rates for all (cache service, node) combinations on the given host, for the timer period represented by the cell. The ?Enable MouseOver? Check Box can be used to enable or disable the display of pop-up mouse overs The ?Log Scale? Check Box can be used to display the metrics in a Log scale or a linear Scale. The ?Range? Drop Down can be used to select the time range over which values are plotted in the history heatmaps. The [?] Button can be used to select a non-current date and time for the rightmost values displayed in the history heatmap The Labels at the base of the display show the start and end timestamps of the data displayed in the heatmaps.


TIBCO EMS

19614: Button typo fixed in All Topics for Server

A typo has been fixed. The button for navigating to EMS Destinations -> All Topics Heatmap display has been changed from Table to Heatmap.


19784: All EMS Servers bug with multiple collectors fixed

All EMS Servers is now correct when TIBCO EMS Monitor has been configured to collect data from multiple data servers.


UX Monitor

18913: New Extension - User eXperience Monitor (UXMON)

A new extension, the User eXperience Monitor (UXMON), has been added. The UX Monitor Solution Package provides End User Monitoring for web applications. It does so by performing simulated transactions as if a real user is accessing a URL. When these simulated transactions are performed, information about the transaction such as the performance of the transaction, whether any errors were produced by the transaction or if the transaction produces invalid data are captured.


Version 1.4.5 Release Notes

19327: Sybase schemas updated to conform to Sybase requirements

All historian database schemas for Sybase have been updated with the following syntax changes: - All non-index columns now set the "NULL" parameter - The use of the BIT type for boolean columns has been changed to SMALLINT, to allow the use of boolean columns in indexes. If you have existing database tables for storing historical data, you should not need to make any changes to them, unless you have seen errors EM server logs that suggest that one of the above changes would resolve the problem..


Deployment

19400: fixperms.sh updated to fix files from any location.

The installation and setup of the RTView EM framework and projects has been streamlined as follows: (1) The script file fixperms.sh has been moved to the bin directory so it can be used from multiple locations. (2) fixperms.sh will automatically be made executable and executed the first time rtvapm_init.sh is run so the user no longer need perform these steps. For example here are the steps to install the framework and a project named myproject: * unzip -a ...rtvapm...zip * unzip -a rtvapm_projects.zip (contains myproject) * cd rtvapm * . ./rtvapm_init.sh * cd ../rtvapm_projects/myproject * . ./rtvapm_user_init.sh * fixperms.sh Note the following: (1) fixperms.sh will be made executable and executed when rtvapm_init.sh is invoked. (2) when fixperms.sh is subsequently executed in the project, it is invoked as "fixperms.sh" not "./fixperms.sh".


19490: Linux/unix version of make_all.sh for emsample

In the emsample project there is a Windows script named make_all.bat, which executes make scripts in various subdirectories. There is now also a unix version, make_all.sh.


Drill Down

19440: Implement dataserver selection in default dir page under EM

The default directory display has been enhanced to provide a drop down to select from when there are CIs from the corresponding Solution Package across multiple Data Servers. This drop down will be hidden when there is only one deployed Data Server. WLM is the exception to this behavior as this Solution Package supports data collection from multiple Data Servers.


RTView Core

Data Historian

16720: Table creation for Sybase now declares NULL for non-index columns

Two problems in the Historian have been fixed related to Sybase: 1) The following exception was sometimes thrown when the historian was storing or compacting data: SQLException: The column <abc> in table <xyz> does not allow null values. 2) The following exception was sometimes thrown when the historian was compacting data: SybSQLException: The 'CREATE TABLE' command is not allowed within a multi-statement transaction in the <xyz> database. Both problems are fixed.


19312: Sybase integer conversion error fixed

A problem has been fixed that caused the Historian to throw an exception when compaction of an integer column by averaging produced a floating point result, when used with Sybase. The exception was reported as "Scale error during implicit conversion of NUMERIC value". This has been fixed by setting "arithabort numeric_truncation off" in the active session between the Historian and the Sybase database.


Data Server

19477: Data Server NPE when DS is busy and pushing data to a disconnecting client

A problem has been fixed that in rare circumstances caused the data server to throw a NullPointerException and become unresponsive after a client disconnected.


Data Sources

18738: Data type handling improvements for Extend by SQL option

Three problems affecting the Extend By SQL option in cache data source attachments have been fixed. The first problem caused the following SQL error in some conditions when a cache attachment was configured with the Extend By SQL option and a filter on a string column, and the database in use was Sybase: "Implicit conversion from datatype 'VARCHAR' to 'INT' is not allowed. Use the CONVERT function to run this query." The second problem caused SQL errors when a cache attachment was configured with the Extend By SQL option and a filter on a Boolean column, and the database in use was Sybase, Oracle, DB2, or MySQL. The third problem caused the Extend By SQL query result to use integer columns for columns that were Boolean in the cache, if the database was Oracle or DB2. All three problems are fixed.


19204: Improved support for mbeans that serialize (Tabular/Composite)DataSupport

The JMX adapter was updated to handle mbeans that serialize TabularDataSupport and CompositeDataSupport objects, as used in some Tibco BusinessEvent mbeans. The previous adapter would return a text blob for BE methods that returned these types. Now, these objects are properly deserialized into an RTView table.


Object Library

19504: listbox selection no longer clears when list changes

A problem has been fixed in the viewer which caused the selected item in a list box control (obj_c1tlb) to be deselected when the control's listValues property was updated.


19511: Listbox validation bug fixed

A problem in the listbox control (obj_c1tlb) has been fixed which caused it to ignore changes to the listValues property in some cases.


Scripts

19491: New custom script for adding solution package environment info

There are certain environment variables required for RTView servers, for example those pertaining to a TIBCO installation, as documented in the installation guides. These variables may now be set in an emsample project by editing the supplied file rtvapm_user_env.bat(sh). This file will be called by rtvapm_user_init.bat(sh) whenever it is executed.


Solution Package

IBM DB2 Database

18967: Improvements for navigation and layout consistency

Previously the "Back" and "Up" controls may have been positioned differently from one screen to the next. The buttons are now precisely positioned and will not "move" as you cycle thru DB2 displays. Also, the "All Members" display has been added to the emsample example for navigation consistency; previously, the "Up" navigation from Member Summary linked to a display not shown in the navigation tree.


Oracle Coherence

18736: Sybase support for OCM history tables

Two support issues for Sybase have been addressed: 1) When auto-creating a database table for Sybase, the Historian will now declare a column of type SMALLINT rather than BIT for a boolean column in a cache table. This is necessary because Sybase does not allow a BIT column to be used in an index, and some EM caches use boolean columns as index columns. This change has also been made to the database schema file for Sybase found under rtvapm\ocmon\dbconfig. 2) The following error that was seen with some Sybase drivers should be fixed: WARNING: unrecognized database product name "sql server". A lost connection to __RTVHISTORY will be undetected.


18863: Notify when the hit Percentage drops below a percentage

A new alert - OcCacheHitPercentageLow- has been added. This alert will trigger when the current Hit % (total current hits/total current gets) drops below the specified threshold for a sampling period and the specified cache(s). This alert has a service/cache override.


18864: New alert for average read Millis

A new alert - OcStoreReadMillisHigh - has been added. This alert will trigger when the current average read millis (total current StoreReadMillis/total current StoreReads) drops below the specified threshold for a sampling period and the specified cache(s). This alert has a service/cache override.


18865: GC Duty Cycle in Node History Heatmap

A new display has been added to show the GC Duty Cycle for all the nodes in a cluster. The display can be accessed from the existing All Nodes History Heatmap, from a newly added "GC Metrics" button.


18866: Time Range Comparison Cache

A new display has been added that allows for analysis of cache data between two sets of time ranges.


19180: All trends now show 7 days of data

All trend graphs have been enhanced to allow the display of up to 7 days of data.


19449: All Nodes Heatmap now shows departed nodes correctly

In prior versions, under certain circumstances, various All Nodes Heatmaps showed departed nodes incorrectly. This is no longer the case.


19555: Log Scale fixed for the All Nodes History Heatmap

The Log Scale functionality of the All Nodes History heatmap has been restored. A bug in the previous version left the Log Scale setting ineffective. Also, resizing of this display will now result in both heatmaps equally sharing the available display space.


Oracle Database

19137: Non-responding DBs are now visible in All Oracle Databases

All configured database connections are now listed in the "All Databases Table". In previous versions of the Oracle database solution package, if a database did not respond, it was not listed in the table when EM started. If a database goes down while EM is monitoring the connection, the database will continue to appear in the "All Databases Table" along with the last sampled metrics. This data will eventually be deleted from cache and display as nulls or zeroes after the $oraRowExpirationTimeForDelete interval in rtvapm.oramon.properties.


Oracle Weblogic

19516: WlsServerStateNotRunning is now working reliably

Previously inactive servers did not always trigger the alert WlsServerStateNotRunning. Also, it was not always possible to create per-server alert overrides for this alert. Both problems have been fixed.


19562: Database schema changes for WlsSessionStats table

In EM 1.4.1, a correction to the WlsSessionStats cache resulted in a change in the order of columns in the cache table. The columns "Connection" and "OpenSessionsCurrentCount" switched location. This change has now been reflected in the database schema files under wlm\dbconfig. Users with existing database tables will need to update WLS_SESSIONSTATS table to change the order of these columns. The correct order is listed below, with the two columns that have switched locations marked with arrows. time_stamp Connection <--- Location ApplicationRuntime OpenSessionsCurrentCount <--- DeltaSessionsOpenedTotalCount RateSessionsOpenedTotalCount


TIBCO BusinessEvents

18789: Cluster filter added to all displays

The "All Clusters" tabular display used cluster name to filter the size of the list. For consistency, filtering by cluster name has been added to all of the displays for the Tibco Business Events Monitor. Also, the terms "Connection" and "Node" were used to mean the same thing in several displays. "Node" now consistently refers to a named member of the cluster. The term "Connection" is used to indicate the connection string (host:port or url) for the source of the JMX data. Other minor display improvements include consistency in field width and positioning for similar display elements on different screens, consistent display format for timestamps, and the addition of the count of outstanding alerts for each node in the cluster.


19370: Corrected timing anomalies in history charts for summary displays

This bug fix corrects chart errors in the TIBCO Business Events summary displays for Inference Nodes and Storage Nodes. The erroneous points appear in the most recent data plotted (ie, the last one minute of data). Although the default sample rate is one sample every 10 seconds, the bug occasionally resulted in erroneous points spaced less than 5 seconds apart.


19408: Bug in rules/sec trend data on summary display fixed

Previously there was a bug when the historian generated tables in an Oracle database. This problem does not affect users who created tables in Oracle manually using rtvapm\tbemon\create_tbemon_history_tables_oracle.sql This bug caused the "Inference Node Summary" screen to not display history for the "Rules / second" chart. The cause was an incorrectly set flag (to quote sql column names) on the TbeInferenceAgent cache, and this resulted in sql errors when the TBE_INFERENCE_AGENTS table was queried. Customers who are affected by this bug will need to apply the following correction to their Oracle history database. If loss of previous agent history is not a concern, simply drop the old TBE_INFERENCE_AGENTS table, then let the historian re-create it with the quoted column names. Otherwise, you can avoid data loss by stopping the historian, renaming the old table, restarting the historian, then doing a "select into" to copy data from the old table after the historian creates the new table, and finally deleting the old table.


TIBCO BusinessWorks

19296: Enhance discovery of BWSE engines

The BW Monitor can be configured to discover BW Engines running as BWSE components of an AMX service implementation. The engines must be configured with HawkEnabled=true. To enable the discovery of BWSE engines you may edit rtview.properties and uncomment two lines, or copy those lines to your own properties file. The lines are: collector.sl.rtview.hawk.enablematable true collector.sl.rtview.cache.config=bw_engine_microagents.rtv


TIBCO Hawk

19135: Optional collection parameters for hawkmon added to rtview.properties

The following lines have been added for this release in rtvapm\projects\emsample\servers\hostmon\rtview.properties and rtvapm\projects\emsample\servers\miscmon\rtview.properties: # Uncomment following to optionally enable collection for process, storage, and network data. #collector.sl.rtview.cache.config=hawk_host_process_cache_source.rtv #collector.sl.rtview.cache.config=hawk_host_storage_cache_source.rtv #collector.sl.rtview.cache.config=hawk_host_network_cache_source.rtv These properties are for collecting optional process, network, and storage data for hawkmon. Customer can optionally uncomment these properties to enable collection.


Version 1.4.4 Release Notes

Configuration

19367: Fixed inactive buttons in the CMDB Admin

A bug that prevented some buttons in the CMDB Admin display from enabling when appropriate has been fixed.


Logging

19415: Adjustments to log4j default behavior

Log4j default properties file have been enhanced to mimic the previous default properties of RTView CORE logging mechanism. Additionally, two examples about how to configure log4j using file and daily appenders have been included. The recommended way to change the default properties is to copy from rtvapm/common/conf the sl.log4j.properties file into your projects directory and then reference it in your custom.properties file by including a new property as follows: # Specify default configuration sl.rtview.cmd_line=-log4jprops:mycustom.log4j.properties You should invoke all processes including this custom.properties file.


Monitor

18788: Improvements to navigation tree

Several improvements have been made to the navigation pane: - The RTView Servers parent node now shows a summary of the server child displays. - The TIBCO Hawk Monitor category has been split into two areas: TIBCO Hawk Views and Host Views. The Hawk Agents Table view has been added to TIBCO Hawk Views.


CMDB Editor

19381: Button layout improved

A bug that prevented the buttons of the CMDB Admin display from displaying correctly has been fixed.


RTView Classic

Data Server

19420: Exception in data server if attachment has bogus column name

A problem has been fixed that could cause the data server to become unresponsive. The problem occurres if a client makes a cache data attachment with no row filter and a column filter that specifies one or more nonexistent columns. In those conditions, the data server would occasionally throw the following exception: Exception in thread "GmsTimer-DataServer" java.lang.ArrayIndexOutOfBoundsException at com.sl.gmsjrt.GmsTabularData.gg$1(SourceFile:5925) at com.sl.gmsjrt.GmsTabularData.writeObject(SourceFile:5849) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) ... at com.sl.gmsjrtvhistorian.GmsRtViewDataServerDs.sendDataToClients(SourceFile:860) at com.sl.gmsjrtvhistorian.GmsRtViewDataServerDs.gmsTimerFired(SourceFile:899) at com.sl.gmsjrt.GmsTimer.run(SourceFile:106)


Solution Package

Host Infrastructure

19388: Host Summary trends now all display gaps

A bug that prevented Host Summary trend graphs from showing gaps when data is not available for longer than 5 minutes has been fixed. Now CPU % Used, Mem Used, and Mem Total display gaps when data is not available for that period of time.


19411: All Host Heatmap corrected for CpuPercent and MemoryUsed

Previously the color legend of the heatmap displayed an incorrect alarm level for some of the metrics. It should display the alarm level of the alerts associated with HostCpuPercent and MemUsed metrics. This has been fixed.


TIBCO BusinessWorks

19215: All Engines table Clear button fixed

The BW Monitor All BW Engines Table has a text field for filtering on the Engine Name and an associated Clear button to clear the text field and return to the full display. In the thin client this button did not correctly clear the text field. This has been fixed. Also a checkbox labeled "Regex" has been added. This will select whether the string entered in the text box is interpreted as a simple wildcard expression or a full Regular Expression.


19306: Provide process data subset; add all engines all processes display

BW Monitor has been enhanced with an alternative All BW Processes table, which can be enabled to replace the default table (or be used in addition to it) by editing the bwmon_navtree.xml file. This table has the option to display all BW Processes across all BW Engines and BW Servers but with a subset of table columns. The column subset used in the table is specified by the $bwprocessColumnSubset property in rtview.properties, e.g. sl.rtview.sub=$bwprocessColumnSubset:'Active;Created;Completed;AverageExecution;'


19403: Display title changes

The titles of the BW Monitor "single summary" displays did not include the word "BW". This has been corrected.


19404: Count, Active Count, and Show Active toggle added to engine displays.

The BW Monitor All Engines displays (Heatmap, Table, Grid) have been enhanced so that they all have text fields showing the counts of engines currently displayed and engines active, and a checkbox to cause the display to show active engines only.


TIBCO Hawk

19407: Hawk Alert table clear button fixed

The Hawk Alerts Table has two text fields for filtering on the Alert Text or the Rulebase fields. Each text field has an associated Clear button to clear the text field and return to the full display. In the thin client these buttons did not correctly clear the text field. This has been fixed.


Version 1.4.3 Release Notes

Logging

19183: Log4j set as default logging mechanism

Log4j has been confirmed as the default logging engine. In the previous releases there were some cases in which the property "useLog4j" was set to false.


RTView Classic

Data Server

19365: REST output generation breaks with special characters

In previous releases, the output of the rtvquery (REST) servlet was truncated if a query result contained a non-ascii character. This is fixed


Data Sources

19363: Fixed memory leak for cache attachment with column filter

A memory leak has been fixed in the cache data source. The leak occurs if there is a data attachment to the current table of a cache, and the data attachment specifies a column filter but no row filter, and rows are never or only very rarely removed from the cache. If there is such a data attachment the data server will leak memory each time the cache is updated. The size of the leak depends on the number of columns specified in the filter. The leak was introduced by changes in RTView version 6.2.


Logging

19256: Log4J on Linux platforms

Log4J functionality was restored on Linux platforms.


Service Model

19119: Corrected CI count and removed PROD, DEV, DR, UAT from service summary

The following Service Summary Views displays have been enhanced to filter the CI Count to the CI's shown based on the selected filters: Service By CI Type (rtv_service_citype_summary.rtv) Service Summary (rtv_service_summary.rtv) Service Browser (rtv_service_browser.rtv) The Service By CI Type and Service Summary displays have also been modified to remove the DEV, UAT, DR and PROD labels.


Solution Package

Host Infrastructure

19354: Timestamps now from local receiver rather than remote sender

Host data from hostbase agents now uses a timestamp indicating when the receiving dataserver added the data to cache. Previously, the timestamp came from the monitored host. This caused host data to display as expired when the monitored host's system clock lags the dataserver system clock by the expiration interval or more.


IBM Websphere MQ

19315: New column "Oldest message age" in history table MQM_QUEUESTATS

In EM 1.4.2 the cache for storing queue stats gained a new column, but this column was not added to the database schemas. This has been addressed. Users with existing database tables will need to add the following integer (or NUMBER for oracle) column to the end of the MQM_QUEUESTATS table: "Oldest message age"


TIBCO BusinessWorks

19313: Add Active Processes to engine table and heatmap.

The BW Monitor All Engines table and heatmap have been enhanced with the addition of the metric Active Processes. This per-engine value is distinct from Running Processes in that it is calculated by BW Monitor each update using data returned by the Hawk GetProcesses method.


19324: Reduce amount of process data sent by the sender data server

BW Monitor has been enhanced with the ability to limit the amount of BW Process data sent by the BW Monitor data server in sender mode. The user may specify a subset of the available Process table columns to be sent via a new property in rtview.properties, e.g. sl.rtview.sub=$bwprocessColumnSubset:'Active;Created;Completed;' In addition an alternative sender file must be selected as per the instructions in rtview;properties: # # Sender functions # sender.sl.rtview.cache.config=bw_rtvagent_sender.rtv # # Sender functions for process table subset # (Comment out the line above and uncomment the one below) # #sender.sl.rtview.cache.config=bw_rtvagent_sender_subset.rtv


19368: 'Active' column in bw_process cache reverted back to type long

In EM 1.4.2 the data type for the ?Active? field in the bw_process cache changed from a type of long to integer. This may have caused problems reading from database tables defined with a column type of BIGINT for ?Active?. This change has been reverted so that ?Active? is again a type of long.


TIBCO EMS

19309: Create new displays for queue/topic clients for producers and consumers

Two new displays to show producers and consumers from one single Queue or Topic have been added. These displays are reachable from the Clients button located in the upper side of the Single EMS Queue/Topic for Server Summary displays.


19314: Split all producers and all consumers displays

The All EMS Consumers and All EMS Producers displays have been enhanced. These enhancements are the following: - addition of filtering options by ClientID and Destination Name - addition of a check box to toggle the visualization of non-expired Consumers/Producers from the table - addition of two drill-down mechanisms: going to the Consumer/Producers Summary by left-mouse double click and going to the Destination Details. This will send you to the Single EMS Queue/Topic Summary Display depending on the Destination Type. By default Destination Types that are different from Topic will be redirected to the Single EMS Queue Summary display


Version 1.4.2 Release Notes

Configuration

19264: Historian backlog feature now enabled by default

The backlog property has been set as the default option for the historian. For further information, see RN of TN19131.

Deployment

19265: projects/emsample/webapps/make_all_wars.sh fixed

The Unix shell script make_all_wars.sh in RTVAPM_HOME/projects/emsample/webapps did not make any wars. This has been corrected.

RTVMGR

19214: Autodiscover now disabled by default for sender

JMX autodiscover for RTVMGR has been fixed to be disabled.

RTView Classic

Alerts

19175: Fixed memory leak when no "new data only" alert table listeners

In previous releases, the Alert data source leaked memory if there were no data attachments to the AlertTable with either the New Data Only option selected or a row filter. This has been fixed.

Data Historian

18655: Historian smoothing and compaction on non-US date strings

Historian smoothing and compaction no longer fail on non-US date strings in non_US timezones.

19100: Extraneous debug message removed from Advanced Compaction

A leftover debug message was in the Historian code at the highest -compactionverbose:2 level. This message was benign and has been removed.

19101: Improved multi-thread support for Advanced Compaction

A better method for multi-thread support for Advanced Compaction was implemented. Messages like ?database connection busy, skip? should not appear.

Data Sources

18796: Support Hawk 5.0

The Hawk data source has been enhanced to support Hawk 5.0. In order to use Hawk 5.0, you must run with java 1.7+. If Hawk 5.0 is configured for log4j logging, you will need to add your log4j jar to the RTV_USERPATH. RTView does not support AS (DataGrid) transports. Only RVD and EMS transports are supported for Hawk 5.0. The Hawkspot sample microagent application does not work with Hawk 5.0.

19176: Synchronization bug fixed

In previous releases, the JMS data source had a synchronization bug that could cause occasional data updates to be missed. This would only happen in the case where multiple updates for the same listener came in almost simultaneously. This bug has been fixed.

19177: Synchronization bug fixed

In previous releases, the RV data source had a synchronization bug that could cause occasional data updates to be missed. This would only happen in the case where multiple updates for the same listener came in almost simultaneously. This bug has been fixed.

19257: Gather Consumer Details information

The TIBCO EMS Administration data source Consumers table has been enhanced to include 12 new columns with information from the com.tibco.tibjms.admin.ConsumerInfo.Details class methods: curMsgSentCount (long) - getCurrentMsgCountSentByServer() or -1 if unavailable totalMsgSentCount (long) - getTotalMsgCountSentByServer() or -1 if unavailable curMsgSentSize (long) - getCurrentMsgSizeSentByServer() or -1 if unavailable destinationPrefetch (int) - getDestinationPrefetch() or -1 if unavailable prefetchDeliveredCount (int) - getPrefetchDelivered() or -1 if unavailable elapsedSinceLastAck (long) - getElapsedSinceLastAcknowledged() or -1 if unavailable elapsedSinceLastSent (long) - getElapsedSinceLastSent() or -1 if unavailable routeName (String) - getRouteName() or blank if unavailable sessionAckMode (String) - getSessionAcknowledgeMode() or Unknown if unavailable ** totalMsgAckCount(long) - getTotalAcknowledgedCount() or -1 if unavailable isActive (Boolean) - isActive() or false if unavailable isSystem (Boolean) - isSystem() or false if unavailable ** The sessionAckMode column contains a String created from the value returned by getSessionAcknowledgeMode() as follows: TibjmsAdmin.SESSION_UNKNOWN_ACKNOWLEDGE: "Unknown Ack" TibjmsAdmin.SESSION_XA: "XA" TibjmsAdmin.SESSION_TRANSACTED: "Transacted" TibjmsAdmin.SESSION_NO_ACKNOWLEDGE: "No Ack" TibjmsAdmin.SESSION_AUTO_ACKNOWLEDGE: "Auto Ack" TibjmsAdmin.SESSION_DUPS_OK_ACKNOWLEDGE: "Dups OK Ack" TibjmsAdmin.SESSION_CLIENT_ACKNOWLEDGE: "Client Ack" If getSessionAcknowledgedMode() returns a value not listed here, the sessionAckMode will be "Unrecognized Type(x)" where x is the value returned by getSessionAcknowledgedMode().

19263: New option to disable FT discovery

The TIBCO EMS Administration data source has been enhanced with a new command line option: -disableFTDiscovery This option is not used by default. When this option is NOT used, for each server that is defined in the servers.xml or discovered using Hawk or Routes, RTView queries the EMS Server for its fault tolerant URL. The URL returned by the EMS Server is the value used in the ft_active setting in the EMS Server configuration. If RTView does not already have this URL in the ServerTable, it will be added and a connection to it will be made. This can cause duplicate entries in the ServerTable in the case where the server was specified in servers.xml using a different URL than was used in the ft_active field. For example, the URL in ft_active uses a host name but the servers.xml entry for the same server uses an IP address. Or, the servers.xml uses a DNS alias, but the ft_active uses a host name or ip address. When this option IS used, RTView will not query each EMS Server for its fault tolerant URL. Instead, it expects that all fault tolerant EMS Server pairs are added to servers.xml as compound urls (ex. tcp://myhost:7222,tcp://myhost2:7224). For each server in the compound url, the fault tolerant url will be set to the other server in the compound url. No error checking is done to confirm that the 2 urls listed are actually a fault tolerant pair. It is up to the user to be sure that the servers.xml information is correct. In addition to the command line option, you can also use the following property to enable this feature: sl.rtview.jmsadm.disableFTDiscovery=true

19297: ConsumerInfo.Details metrics made optional (now disabled by default)

Task 19257 added 12 new columns with information from the com.tibco.tibjms.admin.ConsumerInfo.Details class methods to the TIBCO EMS Administration data source Consumer table.The query for this data can be slow, and so by default these columns have been removed from the table. To include these columns in the Consumer table, use the following command line argument: -queryCIDetails Or the following property: sl.rtview.jmsadm.queryCIDetails=true Note that enabling this option will slow down the EMS metrics queries on servers with a large number of consumers.


Reporting

19178: Report generator now available for EM

In previous releases, the report generator could not be used in EM. This has been fixed.


Service Model

19102: EM-SERVICE CI can now be used by more than one environment

Previously, the the index for the EM-SERVICE CI type and RtvEmServiceAlert/RtvEmServiceAlertImpactHigh alerts did not use the Environment. This caused problems when adding multiple services where the only difference was the Environment. This has been fixed. Upgrade Notes ============ When upgrading from a version previous to 1.4.2, users will need to update the RTVCMDB database entries for all EM-SERVICE CI's and also their ALERTDEFS database entries for all RtvEmServiceAlert/RtvEmServiceAlertImpactHigh alert overrides. RTVCMDB: For all rows where the CIType=EM-SERVICE, modify the CIName to append a ; followed by the value in the Environment field. For example, if the CIType is EM-SERVICE, the CIName is Owner 1;Area 1;Group 1;My Service, and the Environment is PRODUCTION, you should change the CIName to Owner 1;Area 1;Group 1;My Service;PRODUCTION. ALERTLEVELS: For all rows where the ALERTNAME is RtvEmServiceAlert or RtvEmServiceAlertImpactHigh and the INDEXTYPE does NOT equal Default, modify the ALERTINDEX to append a ; followed by the correct Environment value. You can determine the correct Environment value by looking up the corresponding CIName in the RTVCMDB table. For example, if your ALERTINDEX is Owner 1~Area 1~Group 1~My Service and the correct environment for that service is PRODUCTION, you should change the ALERTINDEX to Owner 1~Area 1~Group 1~My Service~PRODUCTION.


19140: Enhanced environment setting in auto-created Infastructure CI's

The automatically generated Infrastructure CMDB entries have been enhanced with a couple of options for setting the Environment for each CI: - If a matching CI is found in the SQL CMDB table, the Environment from the SQL CMDB table is used for the Infrastructure CI. If the CI is found in the SQL CMDB table multiple times with multiple Environments, it will be added multiple times to the Infrastructure CMDB, once for each Environment in the SQL CMDB for that CI. - If no matching CI is found in the SQL CMDB table, the Environment in the Infrastructure CMDB is set to PRODUCTION by default. You can override the default Environment but specifying a different environment in the rtv_cmdb_source_default.rtv line in your properties file. For example, the following will set the default Environment to DR: ConfigCollector.sl.rtview.cache.config=rtv_cmdb_source_default.rtv $rtvDefaultCIEnvironment:DR A matching CI is a row where the CIType and CIName match.


Solution Package

IBM Websphere MQ

19213: Queue Summary table enhanced

The Queue Summary page has been enhanced with additional fields in the list of queues to choose from. This allows the user to sort by and easily identify the queues of interest.

19246: Implemented sender/receiver agents on MQMON

Agent sender/receiver capabilities have been added to MQMON package.

TIBCO BusinessWorks

19207: Correct filter for Hawk Alert Table

The Hawk Alerts table may now be filtered by Rulebase as well as Alert Text, by entering a regular expression of rulebase names into the new Rulebase Filter text field in the display. The Rulebase and Alert Text filters are applied in sequence.

19221: Process Summary trend graph no longer including incorrect 0 points

Under some circumstances the process data trends on the Process Summary page would show a sawtooth appearance caused by multiple rows of data with the same timestamp, one of which has a zero value. This has been corrected.

19222: Added more selectors to All Engines Heatmap

Added Created and RateCreated to the metrics available to the All Engines heatmap display.

19223: Elapsed Time metrics added to Processes Heatmap

Added two new metrics on the processes heatmap: Averaged Elapsed Time and Most Recent Elapsed Time.

19279: Hawk Server expiration corrections

Hawkmon, which is used by itself or inside of BW Monitor, will sometimes indicate servers as expired, when they should not be marked that way. The cache source processing was changed to use full outer joins for joining certain intermediate caches, so that missing data in any of these caches will not block final server row update and cause rows in final display caches to expire. Also, dataserver CPU utilization should be improved by clearing the updateListenersImmedFlag property on all intermediate hawk caches.


TIBCO EMS

19094: Pending messages on all servers display now correct

A bug on EMS Servers Heatmap has been fixed. Previously if the number of Pending Msgs was above the threshold for the maximum value of the color legend, it would not show the correct color.


19209: Implement Drilldown to Destination from Consumers / Producer

The Producers For Server and Consumers For Server tables have been enhanced with drilldowns that correctly identify the type of each row as Topic or Queue and drill down to the corresponding Topic or Queue Summary page. Also the ID text fields (Producer/Consumer ID, Conn ID, Session ID) on both those pages were not always correctly formatted as integers; this has been fixed.


19210: Improvements to All Topics and All Queues display

The All Queues and All Topics displays have been improved as follows: - Timestamp column widened - Expired column added - Drilldown to corresponding heatmap display added


19211: Improved table placement and resize in Queue and Topic Summary pages

The Queue and Topic summary pages have been enhanced by improving the placement and resize behavior of the tables on those pages.


19212: Implement All Queues and Topics Heatmaps

Two new displays have been created to visualize, on a heatmap, the main metrics for queues and topics: Severity, Alert Count, Consumers, Receivers/Subscribers, Pending Messages, In/Outbound Msgs Rate, In/Outbound Total Msgs.

19220: EMS Metrics Administration display supports named dataservers

A bug that prevented RTView EM from showing valid data in the EMS Metrics Administration display has been fixed.

19247: Routes page now shows correct bytes/sec & totals for in/out msgs

An error that prevented several metrics from being displayed correctly has been fixed. These metrics were: Message In Bytes/sec, Message In Total, Message Out: Bytes/sec, and Message Out: Total.

19266: Additional details available for EMS Consumers

An enhancement has been added to show consumer details in the Consumers Table of the EMS Consumers for Server display. In order of collecting the consumer detail info, you should first enable the collection of these columns in the Consumer table by using the following command line argument: -queryCIDetails Or the following property: sl.rtview.jmsadm.queryCIDetails=true Note that enabling this option will slow down the EMS metrics queries on servers with a large number of consumers.

19267: New alert for Consumer Stalled

A new alert, EmsConsumerStalled, has been added to indicate when there are stalled consumers. This alert does not allow overrides. To collect the consumer detail info that this alert uses, you should first enable the collection of these columns in the Consumer table by using the following command line argument: -queryCIDetails Or the following property: sl.rtview.jmsadm.queryCIDetails=true Note that enabling this option will slow down the EMS metrics queries on servers with a large number of consumers. This alert filters all consumers from the following initial conditions: (elapsedSinceLastAckInSec > AlertThreshold) || (totalMsgAckCount == 0) && (uptime > minUptime) && (totalMsgSentCount > totalMsgAckCount), where minUptime in the minimum running time of the server (default of 5, set using $emsServerMinUptime). This set of conditions is equivalent to: (elapsedSinceLastAckInSec > AlertThreshold) && (uptime > minUptime) && (totalMsgSentCount > totalMsgAckCount)) || ((totalMsgAckCount == 0) && (uptime > minUptime) && (totalMsgSentCount > totalMsgAckCount) which equals to: (elapsedSinceLastAckInSec > AlertThreshold) && (uptime > minUptime) && (totalMsgSentCount > totalMsgAckCount)) || ((uptime > minUptime) && (totalMsgSentCount > 0) And provided that: (uptime > minUptime) && (totalMsgSentCount > totalMsgAckCount) contains the condition: (uptime > minUptime) && (totalMsgSentCount > 0) we can eliminate the second part of the or without any loss of data. Therefore, the implemented alert filters out consumer rows that satisfies each of these three conditions sequentially: First, by filtering by Condition (totalMsgSentCount > totalMsgAckCount). Second, by filtering from the rows that satisfied Step 1 by Condition (uptime > minUptime) . And third, by issuing an alert from the rows that satisfied the previous step those that fulfilled Condition (elapsedSinceLastAckInSec > AlertThreshold), where AlertThreshold is set in the alert definition.

TIBCO Hawk

19206: File renamed to remove extraneous space

An include filename used by the hawk solution package had an embedded space. Although this caused no problems, it could lead to future problems and is inconsistent with solution package programming standards. Hence, the space was removed. No change in behavior of the package should be observable.

Version 1.4.1 Release Notes

Alerts

18802: Time tracing added to alert notifier

Time tracing has been added to EM alert notifications. This information is useful when debugging notification issues. It let's you know how many notifications are being generated and how long it takes to execute them. To enable tracing, add this to your properties file: sl.rtview.alert.notifiertimetrace=1 A value of 1 will output trace similar to the following for all notifications: notify: 14 alerts, queue time=1, processing time=0, cmd process time=6, cmd execute time=179, total time=186 And output similar to the following for timer renotifications: renotify: 14 alerts, processing time=0, query time=0, cmd process time=0, cmd execute time=159, total time=159 A value of 2 will output additional information for renotifications: renotify: 14 alerts, processing time=0, query time=1, cmd process time=0(subTime=0, alertStrTime=0, setupTime=0, attachRowTime=0), cmd execute time=143, total time=144

18853: Timer re-notifications implemented for new alert notifier

In release 1.3.0, task 18357 implemented a new alert notifier that supported notifying centrally or on the backend data server. This new notifier did not support timer renotifications. The notifier has been enhanced to support timer renotifications. If the following properties are set, EM will renotify on all open and unacknowledged alerts: sl.rtview.alert.notifierrenottime - Sets the rate (in seconds) to renotify. This must be set to a value greater than 30. If it is set to a value greater than 0 and less than 30, the value of 30 will be used. sl.rtview.alert.notifiercommandrenot - Set the command to execute for renotifications. If sl.rtview.alert.notifierrenottime is set to a value greater than 0 and this property is blank, the command specified in sl.rtview.alert.notifiercommandnew will be used instead. Commented out examples of these properties have been added to common\conf\rtvapm.properties and common\conf\custom_handler.properties and to the custom command handler.

18898: Alert group value no longer reset to default when navigating

In the previous release, the thin client had a limitation when the default Alert Group filter was set by the login. In this case, if the user set the Alert Group to another value using the Alert Group filter combo and then selected a different node in the navigation tree, the Alert Group filter was reset to the default. This problem has been fixed.

18908: AlertIndex parsing in notifications improved

The standard my_alert_actions.sh script has been improved to eliminate echoing extraneous characters in the ALERTINDEX field.

Configuration

18907: Added $alertActionScript sub property incl. unix example

The alert script substitution properties in RTVAPM_HOME\common\conf \rtvapm.properties have been modified. Previously, the $alertActionScript and $scriptEnding properties were set via cmd_line properties. They have been modified to be set via sub properties in order to make it easier to override these properties: # Substitutions to define the script executed by the above command # Use these values if running on windows: sl.rtview.sub=$scriptEnding:bat sl.rtview.sub=$alertActionScript:my_alert_actions The RTVAPM_HOME\common\conf \rtvapm.properties has also been enhanced to include commented out versions of these properties for unix users: # Uncomment the following if running on unix: #sl.rtview.sub=$scriptEnding:sh #sl.rtview.sub=$alertActionScript:./my_alert_actions

19118: Historian performance optimized with batch insert statements

In order to improve the performance of the historian especially in cases of higher than average load, the default configuration settings have been enhanced to enable the historian to make database inserts in batches. The size and frequency of the batch inserts are controlled by two properties: historian.sl.rtview.historian.cache_size=200 historian.sl.rtview.historian.cache_time=30 This says that the historian will insert a batch when either it reaches 200 records or 30 seconds has passed since the last insert.

19158: EM updated with more displays from standalone monitors

The EM navtree configuration file now contains all available displays for wlm, ocmon, bwmon, and emsmon. Previously they only showed a subset of available displays.

19170: Updates to central.properties for bwmon integration

When bwmon was run in an EM project, under some circumstances it would fail to display data. This has been corrected.

Monitor

CMDB Editor

19181: Fixed bug preventing addition of CIs in CMDB Admin display

A bug that prevented the CMDB editing has been fixed. This bug was introduced when enhancing the display to allow for insertion of multiple CIs at once.

RTView Classic

Alerts

19032: Fixed synch bug in alert ds for new data only listeners

In previous releases, a synchronization bug caused some updates from alert commands not to be applied to the new data only listeners in the case where several command updates were executed at the same time. This has been fixed.

Data Historian

19131: Data Historian Backlog property

The historian now supports a property named local_backlog. This property can be used to help avoid loss of data during busy periods when the historian is receiving data from a data server at a higher rate than it can be stored in the database. If the local_backlog property is set, the historian will use its local heap space to keep the backlog of data rows to be stored in the database. If the local_backlog property is not set then the row backlog is kept in the data server, where it may be discarded after a relatively brief time if the historian is unable to process it. By default the local_backlog property is not set. The property can be set as follows on the command line: run_dataserver -local_backlog or in a properties file: sl.rtview.historian.local_backlog=true The local backlog will keep a minimum of 50,000 rows of data. If the Oracle server jvm is used, the backlog will grow as large as the available heap space allows. The following message appear in the historian log each time the backlog is increased by 1000 rows: backlog: increased to N rows or decreased by 1000 rows: backlog: decreased to N rows where N is the current number of rows in the backlog. If the incoming rate of data exceeds the rate at which data can be stored in the database for an extended period of time, the backlog may need to be trimmed in order to avoid an OutOfMemory exception in the historian. If that occurs, the following message appear in the historian log: backlog: discarded N rows If this message is seen frequently, then it may be necessary to adjust the data server, historian, and/or database configuration to reduce the incoming data volume or increase database throughput. (That topic is beyond the scope of this note).


Data Sources

19130: Hawk data synchronization improvement

In previous releases, a synchronization bug in the hawk data source occasionally resulted in some data being missed. This has been fixed.

Display Server

18825: Display server memory leak fixed

A memory leak has been fixed in the display server that caused memory to grow at a small rate for each new session.

18893: Global subs set in login no longer reset after navigation

The following problem in the thin client has been fixed: If a global variable $x is initialized to a value of (say) 100 via a login sub defined in users.xml or roles.xml, and then $x is set to a value of 200 by user interaction with a display, the value of $x will incorrectly revert to 100 when the user later navigates to a new display.

Functions

19143: GroupBy result now correct when possible index combos > 2 ^ 31

A bug in the GroupByTimeAndUniqueValues function has been fixed which caused rows to be missing from the result in the case where the input table has multiple index columns and the union of all possible combinations of the index values present in the table exceeds 2^31

Solution Package

Host Infrastructure

18912: Fixed compaction rule bug in HostStorage

The compactions rules for HostStorage cache history data referenced a non-existent history column. This caused a SQL error in the historian.log file, and compaction to fail. Removing the column reference from the compaction rules corrected this problem.

Oracle Weblogic

18750: WlsServerStateNotRunning alert now accepts per-server overrides

WlsServerStateNotRunning alert has been fixed to allow overrides of individual servers.

18829: Sessions created for app servlets are now included

Sessions per Application has been fixed to account for the existence of multiple servlets with independent number of sessions.

18843: New CI Types for JMS Servers and JMS Destinations

Two new CI Types have been added to the CMDB to account for the JMS Servers and JMS Destinations under WebLogic.

18844: WLS Server drop down now lists all servers

All WLS Servers are now shown even when no applications have been deployed in them.

18845: Data server validation fixed on Cluster Apps Table display

On the clustered application table display, the data server validation has been fixed.

18846: Alert improvements

The following alerts have been improved: WlsJmsDestinationsCurrentLow, WlsServerPendingUserRequestsHigh, WlsLockedUserCurrentHigh, and WlsServerReloadsHigh. To enable WlsJmsDestinationsCurrentLow and WlsLockedUserCurrentHigh you should first uncomment on rtvapm\wlm\projects\sample\rtview.properties the section: "Collect all other metrics".

18855: Corrected for missing data in JDBC trends

The JDBC filtering function for the trends has been fixed to account for an update problem of the last history points in the trend graphs. With this fix, when selecting among JDBC modules to change the shown trends, there will not be any loss of data points at any time between update periods.

TIBCO BusinessEvents

18766: BEMon unable to get metrics from only inference agents

Configuration instructions in Readme.txt were updated with the following pre-requisite for tbemon use. Tbemon requires that your Business Events project use Cache memory management. The "In Memory" memory management setting will not expose the mbeans queried by tbemon. In other words, the project must use a cluster of both inference and cache agents. Inference-only configurations are not supportable, since the JMX Mbean data is not available.

18896: Rules fired per second calculation no longer fails with BE 5.1.x

The "Rules Fired per Second" calculation was producing results higher than expected when monitoring BE 5.1.x systems. BE 4.0 and 5.0 results were correct.

TIBCO BusinessWorks

17315: Support for BWSE (ActiveMatrix)

BW Monitor can now display BW Engines running as BWSE components in an ActiveMatrix environment. See the documentation for instructions on configuring BW Monitor appropriately. Limitations: (1) JVM memory metrics will be available for BWSE components running in AMX 3.x environments only. (2) The BW Version column in the Engines table will be blank for BWSE components. (3) The Deployment column in the Engines table will be UNKNOWN for BWSE components. The AMX environment controls in which node or nodes a BWSE component is running so the concept of "deployment" in traditional BusinessWorks does not apply. (4) Likewise, BWSE components will only appear in the Engines table when they are running in a node.


18821: Deployed Engines and Active Engines added to All Servers pages

The columns Deployed Engines and Active Engines have been added to the All Servers Table and Heatmap displays. In the Heatmap these metrics may be selected in the dropdown list and seen in the mouseover tooltip.

19073: Periodic update now disabled by default

In the BWAgentPlugin.hma file the argument -update is now commented out. This allows it to take its default value of 0, which disables the periodic update of the deployment data by the BWAgentPlugin microagent. If the argument is uncommented and given a nonzero value (seconds) the microagent wil update its deployment data on that interval.

19120: Server process summary pages disabled by default

The BW Monitor Server Processes and Server Process Summary pages are not enabled by default, because (due to limitations in Tibco Hawk) the data they display is not available from IBM AIX or HP-UX servers. To enable these displays, edit bwmon_navtree.xml in the project directory and uncomment the following two lines, then restart BW Monitor. <!-- <node label="Server Processes" display="bw_server_processes"/> --> <!-- <node label="Server Process Summary" display="bw_server_process_summary"/> -->

19169: BWM will show duplicates of Hawk alerts

BW Monitor Solution Package (1.4.0) was showing duplicate entries for in the alerts table for Hawk alerts. This has been corrected.

TIBCO EMS

18529: New display dedicated to bridges

The EMS display Connections has been divided into two displays, with Connections on the first and Bridges, Ports, and Users on the second.

18614: EMS_COMPDESTTOTALS cache disabled

The EmsCompdestTotals cache has been disabled by default. This cache is not normally used in any displays. The definition for the history table, EMS_COMPDESTTOTALS, has been correspondingly removed from rtvapm\emsmon\dbconfig\*.sql Users with existing databases can remove this table from their installations at their convenience.

18814: Password column removed from server table

The Password column in the Server Table section of EMS Single Server Tables display has been removed.

19160: Additions to projects/sample folder

The emsmon/projects/sample folder was missing some useful files. This has been corrected.

Version 1.4.0 Release Notes

18696: SQL definitions updated for Central alert tables

Table and index definitions for ALERT_PERSIST_TABLE_RTVRULES and ALERT_PERSIST_TABLE_CENTRAL have been added to the SQL schemas in the rtvapm/common/dbconfig directory.

Alerts

18268: Support defining and filtering by Alert Groups

EM has been enhanced to support defining and filtering by Alert Groups. This allows users to filter out alerts that are not relevant to them. Alert Groups are defined in the CITYPE_ALERTMAP table in the rtvconfig database. In order to define an alert group, add a row to this table where the CITYPE value is GROUP-AlertGroupName and the ALERTNAME value is the name of an alert you want to include in that group. For example, to define an Alert Group named Availability and add the JvmNotConnected alerts to it, you would add a row like this: GROUP-Availability -- JvmNotConnected A single alert name may belong to multiple Alert Groups and an alert group may contain as many alert names as necessary. Any alert names that are not associated with an Alert Group are added to the "None" Alert Group. Note that you may not define an Alert Group named None. Add the following property to the properties file used by your Central Configuration server: ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_db.rtv This property is included in projects\emsample\servers\central\central.properties, but is commented out. Uncomment this line in order to use Alert Groups. When you have one or more Alert Groups defined, you will see an Alert Group combo box at the top of all displays in all of the following sections of the navigation tree: All Management Areas Multi Area Service Views Service Summary Views Component Views The Alert Group combo box was also added to the RTView Alerts Table (Alert Views->RTView Alerts Table) and the Alerts History Table (Alert Views->Alerts History Table). The navigation tree when you run in the alert-viewer mode also has the Alert Group combo box. Select an Alert Group from the Alert Group combo box to filter the alerts in the display by the selected Alert Group. This will filter out all alerts that are not part of the selected group from the display. The Alert Group filter is an application wide filter, so changing the selected Alert Group will also change it on all other displays in the application. You can also set the default Alert Group filter for your application, either in the properties files or per user or role. To do this, set the $rtvAlertGroupFilter to the name of the Alert Group you would like to filter by. For example, to set it to the Availability Alert Group in your properties file: sl.rtview.sub=$rtvAlertGroupFilter:Availability Or add it to your users.xml or roles.xml to define a per-user or per-role default: sub name="$rtvAlertGroupFilter" value="Availability" /> The thin client deployment has a limitation with the per-user or per-role default. When the user's log in sets the default Alert Group filter and then the user changes the Alert Group filter by selecting another from the Alert Group filter combo box on a display, this value is reset to the default value if the user selects another node in the navigation tree. Note that the Alert Group combo box will only show up in your displays if you have defined at least one Alert Group in the CITYPE_ALERTMAP. To see the defined Alert Groups, navigate to Architecture->RTView Cache Tables and select CONFIG-SERVER in the DataServer combo box at the top of the display. Then, select the RtvAlertGroupMap cache from the top table. This will show you all of the Alert Groups and the associated alert names. Note that this cache includes the None Alert Group which RTView defined for all alerts that are not included in a user defined Alert Group. 5 new caches were added to the central alert server to support this feature: RtvAlertStatsByCIAndAlertGroup, RtvAlertStatsByAreaAndAlertGroup, RtvAlertStatsByServiceAndAlertGroup, RtvAlertStatsByServiceRegionAndAlertGroup., and RtvCmdbAlertStatsByAlertGroup. The RtvCmdbAlertStatsByAlertGroup is configured to be stored in history when you run the Historian. It is stored in a new database table named RTV_SERVICESTATSBYAG in the RTVHISTORY database. The schema for this table is included in common\dbconfig\create_common_history_tables_*.sql. Custom displays using data from the following caches can be enhanced to include the Alert Group filter: RtvAlertStatsByCI RtvAlertStatsByArea RtvAlertStatsByService RtvAlertStatsByServiceRegion RtvCmdbAlertStats The technique for adding the Alert Group filter depends on the content of your custom display. If your display uses one of the following include files to feed data to your display, do the following: 1. Add a function named getAlertGroupsSupported to your display. This function doesn't need to do anything - it can just be an Add function with both arguments set to 0. 2. Save and reopen your display and see that the Alert Group combo box is now included at the top left of the display. Selecting a value from this combo box should filter the data in your display. Include Files: rtv_alerts_table_include.rtv rtv_cistats_current_include.rtv rtv_cmdb_area_current_include.rtv rtv_cmdb_citable_current1s_include.rtv rtv_cmdb_citable_current_include.rtv rtv_cmdb_service_current1a_include.rtv rtv_cmdb_service_current1o_include.rtv rtv_servicestats_current1a_include.rtv rtv_citypes_include.rtv If your display does not use one of the following include files, do the following: 1. Tools->Include - add rtv_alertgroups_include.rtv (this file is in the rtvapm\appmon\lib\rtvapm_appmon.jar) 2. Add a function named getAlertGroupsSupported to your display. This function doesn't need to do anything - it can just be an Add function with both arguments set to 0. 3. Find the function in your display that is directly attached to one of the caches listed above. Copy the data attachment to this cache. 4. Add a new Conditional Function. - Paste the data attachment you copied in step 3 into the Table1 argument. - Paste the data attachment you copied in step 3 into the Table2 argument. - Double-click on the Table2 argument to edit it. Change the cache name to append "AndAlertGroup" to the end of it. For example, if your data attachment was to RtvAlertStatsByCI, modify it to RtvAlertStatsByCIAndAlertGroup. Also, modify the filter to include the ALERTGROUP column filtered by $rtvAlertGroupFilter. Click OK. - Attach the ReturnTable2 argument to the getFilterByAlertGroup function - Give the new function a name and click OK to save the function. 5. Edit the function from step 3 that is directly attached to the cache. Modify it to attach to the function you created in step 4 instead. 6. Save and reload your display. You should now see the Alert Group combo box at the top left of the display. Selecting a value from this combo box should filter the data in your display.

18677: Filter added to alert administration

The Alert Administration screen has been enhanced to include an Alert Filter. To filter the alerts listed in the table, enter a string into the Alert Filter and press <enter> or click elsewhere in the display. No wildcard characters are needed for partial strings. For example, you have 3 alerts: BlueAlert GreenAlert BlueGreenAlert If you enter Blue in the Alert Filter field and press enter, the Alert Table will be filtered to only show the BlueAlert and BlueGreenAlert rows. Click the Clear button to clear the filter.

18678: Alert Index checkbox added to alert table to toggle visiblity

The Alert Table display (Alert Views->RTView Alerts Table) has been enhanced with a checkbox to toggle the visiblity of the Alert Index column. By default, this column is hidden and can be shown by selecting the Alert Index checkbox at the bottom of the display. To make this column visible by default, add the following property to the properties file used by your viewer application: # Show the Alert Index column in the alert tables sl.rtview.sub=$rtvUserShowAlertIndex:1 The position of the Alert Index column in the table depends on the configuration of the $rtvUserAlertTableColumns substitution property. The $rtvUserAlertTableColumns allows the user to configure which columns are included in the table, along with the column widths and order. The Alert Index column is always included in the table regardless of the $rtvUserAlertTableColumns value. If the $rtvUserAlertTableColumns value is not specified, the Alert Index column will be positioned after the Alert Name column. If $rtvUserAlertTableColumns is specified and it includes the Alert Index column, it will use the size and posisiton specified. If $rtvUserAlertTableColumns is specified and it does not include the Alert Index column, it will be positioned at the end of the table. The Field Filter list will always contain the Alert Index column regardless of whether or not that column is visible. The following displays will also hide or show the Alert Index column in the alert table based on these settings: rtv_service_citype_summary.rtv (Service Summary Views->Service By CI Type) rtv_service_summary.rtv (Service Summary Views->Service Summary) rtv_allareas_allservices_citype_summary.rtv (Multi Area Service Views->Services CI Type Summary) rtv_area_allservices_citype_summary.rtv (Single Area Service Views->Services CI Type Summary - not included in the default navigation tree) Examples of these properties are included in the emsample demo in %RTVAPM_HOME%\projects\emsample\servers\central\rtview.properties. All of the above substitutions can be set on a per-user or per-role basis if the RTView login is enabled and custom users or roles are defined. See the documentation for information on how to define substitution values for custom users and roles.


18852: Corrections to alert historian database schema defintions

The database schema definitions for history tables under common\dbconfig have been updated. Users with existing tables in production should not need to make changes to their tables, unless they have been experiencing problems and suspect that one of the following is the cause of a problem. 1) The "AlertCount" column of RTV_SERVICESTATS has been corrected to have an integer data type instead of string data type. 2) The per-database syntax was not consistent with other database schema definitions. SQL Server in particular has changed dramatically. 3) The naming convention has been changed. The previous files were: create_rtvhistory_tables_db2.sql create_rtvhistory_tables_mysql.sql create_rtvhistory_tables_oracle.sql create_rtvhistory_tables_sqlserver.sql create_rtvhistory_tables_sybase.sql The new files are: create_common_history_tables_db2.sql create_common_history_tables_mysql.sql create_common_history_tables_oracle.sql create_common_history_tables_sqlserver.sql create_common_history_tables_sybase.sql 4) Other tasks in this release have affected the contents of these database definitions. You can read their release notes for more details. 18868 changed the length of varchar strings used as indices to 100 18268 added a new table RTV_SERVICESTATSBYAG


Configuration

18604: Allow multi-selecting of CI's in CMDB admin

The CMDB Admin display now allows users to select multiple CIs and add them to a Service in a single step. This new behavior applies to both the 'Add CI' and 'Add CI to...' buttons.


18688: Optimization of history database table schema definitions

Several changes have been made to the history table SQL schemas. 1) The max length for all non-index VARCHAR columns has been set to 255, and the max length for all index VARCHAR columns has been set to 100. Users should not need to modify existing tables. 3) Index names for Sybase and Oracle that may have otherwise been more than 30 characters have been renamed to a unique index name less than 30 characters. Users should not need to modify existing indexes. 4) A few database table definitions still contained an unnecessary "RTVHISTORY". table prefix. These have all been removed. Users should not need to modify existing tables.

18793: New property defines the default character limit for index cols

A new property that defines the default character limit to 100 characters for the size of index columns has been added. To modify this default add the following property to your chosen properties file: # Define the size of varchar index columns in RTVHISTORY database historian.sl.rtview.historian.charlimitindex=[newSize] This new property solves the issue on Sybase of failures with index limits while increasing performance on the other supported databases.

18810: Default value for compaction interval increased to 60 seconds

To allow the historian to perform compaction without missing data, the historian property compactiontimerinterval has been increased from 5s to 60s.


18857: New property to skip history/history_s check

The following property has been added to rtvapm\common\conf\rtvapm.properties to prevent the Historian from attempting to create or modify the HISTORY and HISTORY_S tables sl.rtview.historian.historyTableName=__none

Deployment

18699: Support sender/receiver on same host out-of-box

The default properties for the packages bwmon, emsmon, rtvmgr, and wsm have been modified so that if a dataserver is run as a sender (aka. "agent") it will be given unique port assignments. Note that for a deployed sender-receiver configuration, both the sender and receiver dataservers must be restarted after this upgrade is installed.

Documentation

18775: Updated help links with latest documentation

The RTView help system has been updated with the latest published documentation.

General

18740: Help button enabled

Context-help system has been integrated in the RTView EM displays. To use it, click the button ? at the upper right location of each display. A new browser window will be shown with the html page in which the display has been described in the documentation.

Monitor

18453: Default CI Type defs moved out of rtvconfig db and into packages

EM has been enhanced to support defining CI Types within each package in addition to the central RTVCONFIG database. All of the standard SL packages have been enhanced to take advantage of this. Previously, all of the CI Type definitions for the standard RTView packages were stored in the central RTVCONFIG database. In this release, they have been moved out of the central RTVCONFIG database and are now defined in xml files in each package's jar. In order to read the CI Type definitions, 2 lines are needed in the properties file used by the central configuration server for each package that you are using (where pkg is the name of the package): ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:pkg For example, if you are using the Custom package, you would add the following: ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.custom.xml 0 rtvconfig.custom.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:custom The central.properties file in projects\emsample\servers\central contains these 2 lines for each standard RTView package. The RTVCONFIG database is now shipped without any rows. In future releases, this will make it easier for customers with custom CI Types and/or Alert Group definitions to upgrade to new versions of EM since the database will now only contain user defined custom CI Type definitions. Users that have created custom packages have 2 options for storing custom CI Type definitions: 1. Add CI Type definitions to the RTVCONFIG database as was done in previous versions. In this case, include this line in the properties file used by the central configuration server: ConfigColllector.sl.rtview.cache.config=rtv_config_cache_source_db.rtv 2. Create an xml file named rtvconfig.pkg.xml (where pkg is the name of the package) with CITYPE_DEFS, CITYPE_CACHEMAP and CITYPE_ALERTMAP tables, pack it into the package jar and add the following 2 lines to the properties file used by the central configuration server: ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:pkg Also add this line to the properties file for the custom package: sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1 The custom package defined in projects\emsample\custom shows an example of how to do this. In projects\emsample\custom\src\rtfiles, there is a file named rtvconfig.custom.xml that contains the custom CI Type definitions. The projects\emsample\custom\conf\rtvapm_custom.properties file contains the following line: sl.rtview.xml.xmlsource=rtvconfig.custom.xml 0 rtvconfig.custom.xml 0 1 The projects\emsample\servers\central\central.properties contains the following lines in the CUSTOM section: ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.custom.xml 0 rtvconfig.custom.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:custom By default, the rtvconfig.pkg.xml files are read from the central EM installation. In the case where you have a backend data server that is a different version than the one in the central EM installation and the backend server is EM version 1.4.0+, you can configure EM to get the rtvconfig information from the data server instead. To do this, modify the properties file used by the central configuration server as follows: 1. Append $rtvDataServer:DATASERVER-CONN to the rtv_config_cache_source_xml line for that dataserver, replacing DATASERVER-CONN with the data server connection name. 2. If necessary, add a named data server connection for that server with the ConfigCollector property filter. For example, to do this for the custom package, you would replace this line: ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:custom with the following lines: ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:custom $rtvDataServer:CUSTOM-LOCAL ConfigCollector.sl.rtview.dataserver=name=CUSTOM-LOCAL;connect=localhost:3278 Upgrade Notes --------------------- NOTE: If you skip these steps, you will either have no CI Type definitions or outdated CI Type definitions. Either condition will cause EM to break. Customers upgrading from a previous version of EM will need to do the following: 1. Clean up the RTVCONFIG database: - If you have custom CI Types defined in the RTVCONFIG database, remove all rows except those for your custom CI Types. Optionally, you can move your custom CI Type definitions to an xml file in your package jar as described above. If you opt to do this, remove all rows from the database. - If you do NOT have custom CI Types defined in the RTVCONFIG database, remove all rows from the RTVCONFIG database. 2. For each standard RTView package that you are using, add 2 lines to the properties file used by your central configuration server where pkg is the package name: ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:pkg For example, if you are using the EMSMON package, you would add the following: ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.emsmon.xml 0 rtvconfig.emsmon.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:emsmon The projects\emsample\servers\central\central.properties file contains these 2 lines for each of the standard RTView packages. 3. If you have custom CI Types, add a reference to them in the properties file used by your central configuration server: - If you opted to leave your custom CI Type definitions in the RTVCONFIG database in step 1, add this line to the properties file used by the central configuration server: ConfigColllector.sl.rtview.cache.config=rtv_config_cache_source_db.rtv - If you opted to move your custom CI Type definitions to an xml file in your package jar, add these lines to the properties file used by the central configuration server (where pkg is the name of your custom package): ConfigCollector.sl.rtview.xml.xmlsource=rtvconfig.pkg.xml 0 rtvconfig.pkg.xml 0 1 ConfigCollector.sl.rtview.cache.config=rtv_config_cache_source_xml.rtv $package:pkg 4. If you have created custom displays with data attachments to the RTVCONFIG database, replace them with data attachments to the following caches on the central configuration server: RtvCITypeDefs, RtvCITypeAlertMap and RtvCITypeCacheMap.

Navigation

18705: Fixed bug causing "OK" button to not close window in thin client

The commandCloseWindowOnSuccess property now works in the thin client on a pushbutton control with a drilldown command. In prior releases, the popup window did not close.

RTView Classic

Alerts

18805: Bug loading alert definitions after multiple HA failovers fixed

In previous releases, a bug with HA caused some alerts not to load in the backup server in the case where the primary server in the pair had failed multiple times without the backup server rebooting and the servers were configured with multiple alert definition files. This has been fixed.

Builder

18377: New mechanism to specify template for new displays

The builder supports a new property named displayTemplate. It allows the user to specify an rtv file that should be used as the template for all new displays. The user can make any changes (e.g. add objects) to the template, and the builder will prompt for a new file name when the user attempts to save the changes, so the template remains unchanged. Command-line example: run_builder -displayTemplate:MyTemplate.rtv Property file example: sl.rtview.displayTemplate=MyTemplate.rtv


Customization

18658: Support customization of user/role manager classnames

In previous releases the java class names for the custom user manager and role manager were hard-coded to MyUserManager and MyRoleManager, respectively. In this release, MyUserManager and MyRoleManager are still the default class names but they can be overridden on the command line via two new options, as shown in the following example: run_viewer -customUserManagerClassName:com.xyz.UserMgr -customRoleManagerClassName:com.xyz.RoleMgr The custom classnames can also be specified in a properties file, as follows: sl.rtview.customUserManagerClassName=com.xyz.UserMgr sl.rtview.customRoleManagerClassName=com.xyz.RoleMgr


18700: Role substitutions now queried on login

The display server will now call GmsRoleManager.getSubstitutions(roleName) every time a user logs in or changes roles. This will allow a custom role manager to change the substitutions returned for a specific role without requiring a restart of the display server. In prior releases, the method was only called once for each unique role name.


Data Historian

18791: New property to set the character limit of text index columns

The historian supports a new property named charlimitindex to specify the length of each text (VARCHAR) column that is an also index column in the corresponding cache. For example, if -charlimitindex:70 is specified on the command line when starting the historian, then for each text column that is an index column in a cache, the historian will add a VARCHAR(70) column to the database table it creates to persist the cache. If the charlimitindex property is not specified then all text columns, including index text columns, will use the size specified by the charlimit property. If the charlimit property is not specified, then all text columns will be created as VARCHAR(50). For example, if the following properties are specified on the historian command line then all index text columns will be created as VARCHAR(70) and all non-index text columns will be created as VARCHAR(200): run_historian -charlimit:200 -charlimitindex:70 The charlimitindex property is useful in cases where the database limits the total width (in characters or bytes) that can be used in an index. This includes DB2, Sybase, and Oracle.


18854: New property to skip check for history/history_s

The following property can now be specified to prevent the Historian from attempting to create or modify the HISTORY and HISTORY_S tables sl.rtview.historian.historyTableName=__none (Note that the value __none begins with two underscores). By default the Historian will create the HISTORY and HISTORY_S tables and, depending on other properties, may periodically attempt to delete old rows from those two tables. Since neither table is used in EM, it is convenient to prevent the historian from attempting to create or modify those tables.

Data Sources

18737: Corrected extra rows in history_condensed table

In prior releases the history_condensed and history_combo tables of a cache with the condenseRowsFlag = true would contain 2 rows per condense interval per index, instead of 1 row as expected, if the cache's condenseRowsRawDataTimeSpan < condenseRowsInterval * 3. This is fixed.

18820: Hawk DS now requesting for retransmitted alerts properly

In previous releases, there was a bug with requesting existing alerts after an agent expired and then came back. This has been fixed.

Display Server

18694: Tooltips now accomodate quote and bracket characters

In prior releases, if an object's mouseOverText property was assigned to a string containing a ', ", <, or > character, the thin client would not render the tooltips properly and sometime extraneous text characters would appear on the display. This is fixed.

Object Library

18712: Support animated GIFs in table cells in thin client

An animated gif image will work properly in the thin client if used in a cell value in obj_table02. In previous releases, only the first frame of an animated gif was displayed. To avoid excessive CPU usage in the display server, the frame delay in all animated gif images should be 50 msec or larger. Note that animated gifs are still not supported in the builder/viewer, where the animation is only updated every two seconds or after a mouse click. This is a known limitation that is not addressed by this task.


18713: Support animated GIFs in some objects in thin client

The thin client has been enhanced to support animated gif images on obj_rect_il (simple label object), obj_ind_limits (indicator object with 4 analog alert limits) and obj_ind_multi (indicator object with multiple discrete alert values). In prior releases, only the first frame of an animated gif would appear on these objects. A new property named imageAnimatedFlag has been added to each of these objects. This property must be checked (set to true) in order for the animation to occur in the thin client. To avoid excessive CPU usage in the display server, the frame delay in all animated gif images should be 50 msec or larger. If the object's label string overlaps with the image, then in the thin client the string will be obscured by the image. To avoid this limitation, set the labelTextPosY property to Outside Top/Bottom or set the labelTextPosX property to Left or Right. For obj_ind_limits and obj_ind_multi, if the value string overlaps with the image then in the thin client the string will be obscured by the image. To avoid this limitation, set the valueTextPosY property to Outside Top/Bottom or set the valueTextPosX property to Left or Right. This feature is only supported in the thin client. In the builder/viewer, the animation will only update once every two seconds or after a mouse event.


RTView Display Panel

18722: Panel can now be minimized by default in thin client

The rtvDisplayPanel tag in a PANELS.ini file now supports an attribute named minimized. If this attribute is set to true, as in the north panel in the following example, then the panel will initially be hidden in the thin client: <?xml version="1.0" ?> <panels xmlns="www.sl.com" version="1.0"> <rtvLayout title="Panel Example" dividers="true"> <rtvDisplayPanel region="north" minimized="true" display="title.rtv"/> <rtvDisplayPanel region="center" name="main" display="test1.rtv"/> </rtvLayout> </panels> The minimized attribute is only effective if dividers="true" is specified in the rtvLayout tag, as in the above example. The minimized attribute only works in the thin client, it is ignored in the Viewer. A minimized panel can be made visible by clicking in the dark area in the center of its divider bar.


Solution Package

GlassFish Application Server

18834: Corrections to database schema definitions for Server Info table

Two of the columns in the GFS_SERVERINFO table have been adjusted in the database schemas under gfmon\dbconfig\*sql "Server" - This column was removed, as there is no such column in the GfsServerInfo cache that reads/writes to GFS_SERVERINFO "uptime" - The datatype was incorrectly set as a VARCHAR. It has been changed to BIGINT for all databases except for Oracle, which now has it set to NUMBER. If your existing GFS_SERVERINFO table is functioning correctly there is no need to make changes to it. The above changes were corrections, and do not reflect a change in the structure of the data being stored.

IBM Websphere Application Server

18827: New database schema definitions

Previously the database schema definitions under wsm\dbconfig contained errors that made them unuseable. These old files have been deprecated, and new files have been provided. Limitation: The WAS_SERVERSTATS table contains two columns, freeMemory and FreeMemory, that are not supported by the databases SQL Server and MySQL, due to case insensitivity.

Oracle Coherence

18790: Cluster Selection display user experience improvements

The Oracle Coherence Cluster Selection display has been enhanced to provide a more intuitive default sort order for each table.


18797: Readability enhancements to Cluster Views / Overview display

To provide a less cluttered appearance, some data fields on the Cluster Overview display have been re-positioned.

Oracle Database

18702: More results now returned for table space utilization

Queries for table space utilization in oracle were limited to 100 rows (tables). The limit has been raised to 1000.

18703: Corrected calculations in the RAC DB TableSpace Utilizations

The Database Summary screen displays a scrollable list of graphic objects depicting oracle tablespace utilization. The "used tablespace", "free tablespace", and allocated tablespace metrics were previously calculated from different oracle admin views, and occasionally the results were inconsistent (ie, total tablespace did not equal used plus free tablespace). The calculation technique has been changed to yield consistent results.

Oracle Weblogic

18701: Fixed incorrect heap calculations

WlsServerMemoryUsageHigh alert has been fixed to calculate the heap used percentage based on the heap free percentage.

18826: SQL definitions added for optional history tables

Database table schema definitions have been added for those history tables that are disabled in the default configuration. Those tables are: WLS_JMSCONNECTION WLS_JMSCONSUMER WLS_JMSDESTINATION WLS_JMSDESTINATIONTOTALS WLS_JMSDURABLESUBSCRIBER


TIBCO BusinessEvents

18606: Addition of CPU and memory metrics

%cpu used and heap memory used were added to the node summary displays for caches and inference nodes, and to the node records displayed in the cluster table. These metrics are supplied by the JVM data collected by the rtvmgr solution package; hence rtvmgr should be enabled in your EM project is if isn't already . (Look for the line "rtvapm_package=rtvmgr" in your rtview. properties.)

18676: TbeNodeConnectionLoss consistency between Windows and Linux

On Windows, the TbeNodeConnectionLoss alert triggers around one minute after a JMX connection to a Tibco Business Events agent is lost. However, when running EM on linux systems, the same alert triggers anywhere from 3.5 to 5 minutes after the connection goes down. This problem occurs because of the different TCP stack implementations for Windows and Linux. By default, the Windows tcp stack sends out (at most) 3 SYN packets when attempting to connect to a remote jmx port, with a delay of 3 seconds for the second SYN, and 6 for the third. But Linux sends out 6 SYN's per attempt, with exponential backoff so that SYNs are separated by 1, 2, 4, 8, and 16 seconds. So, you can see that the time that windows will spend failing to reconnect per attempt is 3+6=9 seconds, while for linux it is 1+2+4+8+16=31 seconds. Setting the following TCP tuning parameter will eliminate the behavioral difference between Windows and Linux, so that alert timing is similar. sysctl net.ipv4.tcp_syn_retries=2

TIBCO BusinessWorks

18622: Fixed incorrect engine data with two domains on same server

Previously BW Monitor would return an incorrect list of deployments if a user was querying multiple domains on the same server. The list returned would show each domain as having the deployments of both domains. This problem did not occur if the user queried each domain separately. This has been fixed, so that now the list returned will show the correct deployments for each domain.

18717: Engines that are deployed but not active are now shown

If a BW server had engines deployed but none were active, BW Monitor would show no engines at all for that server. This has been corrected.

TIBCO EMS

18528: New alerts for message idle time

Two new alerts EmsQueueProviderIdleTimeHigh and EmsTopicProviderIdleTimeHigh have been added to alert on the provider idle time for queues/topics. These alerts will be triggered when there is no change in the number of incoming messages for each queue and topic for a specified period of time (in seconds).


18721: Fixed calculation of deltas for queues/topics

A bug that caused incorrect calculation of deltas of inboundTotalBytes, inboundTotalMessages, outboundTotalBytes, and outboundTotalMessages for queues and topics has been fixed.

TIBCO Hawk

18649: New solution package TIBCO Hawk monitor (hawkmon)

The new hawkmon solution package displays cpu, process, disk, and network metrics and alerts for hosts running Tibco Hawk, versions 4.8 and 4.9. When used with Tibco Business Works monitoring (bwmon), hawkmon can supply metrics to enhance bwmon displays. The datasource configuration used to specify hosts for bwmon will work for hawkmon, so no additional configuration will be necessary for existing bwmon customers. By default, hawkmon collects CPU and memory statistics. Uncomment the following lines in rtview.properties to collect disk, network, and/or process data. See hawkmon's readme.txt for additional details. #collector.sl.rtview.cache.config=hawk_host_process_cache_source.rtv #collector.sl.rtview.cache.config=hawk_host_storage_cache_source.rtv #collector.sl.rtview.cache.config=hawk_host_network_cache_source.rtv

VMWare vSphere

18666: EM Service Summary now drills down to correct VM host.

Double-clicking a virtual machine (VM) listed on the Service Summary Views -> Service Summary screen should cause the VmWare Virtual Machine Summary screen to show the metrics for the selected VM. This failed in the previous EM version because a necessary index was not sent to the VmWare Virtual Machine Summary screen. This was corrected by adding the index to the CITYPE_DEFS table in the CMDB. Customers who manage their CMDB in Oracle or other third-party databases will need to apply this correction manually. SQL to correct CMDB: DELETE FROM CITYPE_DEFS WHERE CITYPE = 'VMWARE-VM'; INSERT INTO CITYPE_DEFS VALUES('VMWARE-VM','1;2;3;4','connName;name;managedObjectId;hostId','vmw_vm_summary','$vmwConnName;$vmwName;$vmwVmManagedObjectId;$vmwHostManagedObjectId',1,'Infrastructure','Servers','Hosts')

Version 1.3.1 Release Notes

Alerts

18583: RTView alert table displays enhanced

The alerts table displays have been enhanced. Alert Views->RTView Alerts Table has been enhanced as follows: 1. An additional count has been added to Totals, Critical and Warning. The previous count is the number to the left of the /. This number shows the number of alerts in the table which is the number of alerts after all of the filters have been applied. The new count is the number to the right. This shows the count of alerts with only the CMDB and cleared filters applied. None of the other filters are applied to these counts. 2. The popup menu has a new Alerts submenu that contains all of the actions that can be performed on the currently selected alerts. 3. A new menu item, Set Filter Field, has been added to the Alerts submenu in the popup menu. This will set the Field Filter and Search Text fields based on the selected cell in the table. To clear the Field Filter and Search Text fields, click on the Clear button to the right of the Field Filter field. The alert table at the bottom of the following displays has also been enhanced: Service Summary Views->Service By CI Type Service Summary Views->Service Summary Single Area Service Views->Services CI Type Summary Multi Area Service Views->Services CI Type Summary 1. The popup menu has a new Alerts submenu that contains all of the actions that can be performed on the currently selected alerts. 2. The popup menu has 3 new menu items in the Alerts submenu, Details, Options and Annotate. These menu items do the same thing as the corresponding menu items in the RTView Alerts Table. 3. Double-clicking on a row in the alert table will bring up the details display for that alert. 4. The substitution set by the table for the ID columns has changed from $multiplealertId to $multipleAlertIds. The substitution set by the table for the Source column has changed from $multipleAlertSource to $multiplAlertSources. The substitution set by the table for the CompID column has changed from $multipleAlertCompIDs to $multipleCompIDs. This was done so that the rtv_alerts_menu_include.rtv could be shared between rtv_alerts_table_common.rtv and rtv_alerts_table.rtv. This change only impacts users who have customized either rtv_alerts_table_common.rtv or rtv_alerts_table_menus_include.rtv. Users who have customized rtv_alerts_table_common.rtv should use these new substitutions when merging in their changes. Users who have customized the rtv_alerts_table_menus_include.rtv should use these new substitutions in their actionCommand definitions.

18687: Selected index now set correctly for multiple index types

The Tabular Alert Administration display's Index assignment functionality now works as designed. A bug in the prior version made it occasionally difficult to set certain Unassigned Indexes as overrides.

Enterprise RTView

Data Sources

18670: Gaps in extend-by-sql cache data attachment fixed

A bug has been fixed that caused time gaps to appear in data supplied a cache attachment configured as follows: Cache : MyCache Table : history, or history_combo Time Range : <any value larger than the time range of data available in the cache table above> Extend with SQL : on Begin Time: <blank> End Time: <blank> Update Once: off (if Table = history) Update : On Condense or Always (if Table = history_combo) A cache attachment with that configuration will periodically update its listeners, as new data is added to the cache history table. In prior releases, a time gap would eventually appear between the most recent data retrieved by the Extend with SQL query and the oldest data in the cache history table. This is fixed.


18707: Enhance rowExpiredIndexColumns behavior in Mark+Delete mode

The row expiration feature of the cache data source has been enhanced to allow the rowExpiredIndexColumns and the rowExpirationTimeForDelete properties to be used in combination. If a cache is configured as follows ... rowExpirationMode = 3 (Mark + Delete) rowExpirationTime = -1 rowExpirationTimeForDelete = any value > 0 rowExpiredIndexColumns = any subset of the cache's index columns ... then if a row X exists in the cache's current table and that row's values in the columns specified by the rowExpiredIndexColumns are not matched in the data table applied to the cache's valueTable property, the row will be marked as Expired. Subsequently, if row X is not updated again before the time specified by the rowExpirationTimeForDelete property has elapsed then row X will be deleted from the cache's current table.

Display Server

18689: Support updates to drillDownColumnSubs on table

The drillDownColumnSubs property of the table object (obj_table02) can be attached to data. However, in previous releases the thin client only read that property when the display was opened and ignored subsequent updates from the data attachment. This has been fixed.

Platform Support

18746: Table index names shortened for Oracle and Sybase

The historian will now keep index names to 30 characters or less on Oracle and Sybase to avoid "identifier is too long" errors from those databases.

Monitor

18610: Clear no longer removes all content from Alert History Table

In previous releases, the Clear button on the Alert History Table display removed all rows from the Alert History Table when run in the thin client. This has been fixed.

Solution Package

Oracle Coherence

17946: Single Service Summary Display now showing all data

The Cache Services > Single Service Summary display now correctly displays historical data.

18434: Expiration now indicated for Nodes, Caches and Services

Previously, under certain circumstances the All Caches - Current Size Chart display would display incorrect cache totals. This is no longer the case. (Expired Cache nodes are not counted) This has been achieved by implementing Expiry for Nodes, Caches and Services. Expiry affects data elements, UI elements and configuration properties. Expired Data items are represented by the addition of an Expired column in the current table of a cache, where a row in the cache represents the entity in question. For Expired entities Expired will be true. For currently active entities (i.e. non expired) Expired will be false. Expired entities contain the last known data for that entity. Expired entities are indicated in the UI by a dark red color. Expired entities may be shown in aggregates (Tables, Heatmaps) along with non expired entities and individual Expired entities may be displayed on their own displays that represent that entity. Cells in heatmaps that indicate an expired entity will have this dark red color and rows in data tables that represent an expired entity will have a dark red background. Often the last column in the table will be the Expired column, allowing for sorting/grouping of expired and non expired entities Displays that represent an expired entity typically have a drop down selector that selects a particular entity. Expired entities are represented by an appended [X] at the end of the selector dropdown. When an expired entity is selected the display background will be set to dark red to reinforce that this is an expired entity. The display shows the last known values for the entity where available. Typically trend graphs will only show data up the point of expiry of the entity. Expiry currently relies on the absence of previously available data during an update. Some data is required for the update to succeed. Total absence of data means there is no data to update. Expiry behavior is controlled by properties. Previously the user could control time base expiry. Expiry is now event based and must be configured correctly. For new installs the defaults are set correctly and the user need not be concerned. Users migrating from a previous version, or using a properties file from a previous version, need to take care that the following properties are not redefined (so as to take the correct default values) or are explicitly set using the the following values. # Configure to detect expired entities in caches on update, and delete expired entities after a finite time. By Default # Expiry Mode # 3 = Mark + Delete # Mark Expired Entities. Delete Expired Entities. # # Known entities are Nodes, Caches and Cache Services at this point. Consider what Entity a row in a configured cache represents # sl.rtview.sub=$ocmRowExpirationMode:3 # # Detect Expired Entities, by absence, on update, rather than by (implicit assumed) absence after minimum time-out since last updated. # expiration time of -1 means use update mechanism rather than time mechanism. # sl.rtview.sub=$ocmRowExpirationTime:-1 Failure to do so may result in undesired behavior. The user can still control when expired entities are deleted, and thus no longer appear in displays, or are available for selection. By default expired entities are deleted after 24 hours. Users can override this setting if desired: thus # Delete expired entities from caches a finite time after they expire. # Can be used to limit the grown of configured current caches based on the rate of growth/churn # (Creation + Expiry of new entities with unique identifiers) # By default set to 24 hours - ocmRowExpirationTimeForDelete (86400 = 24 hrs) # sl.rtview.sub=$ocmRowExpirationTimeForDelete:86400

18537: Alert indicators added to the overview screen.

A set of six alert indicator lights has been added to the Cluster Views / Overview display. The lights indicate the aggregated status for Memory, Network, Stability, Tasks, Data Quality and "Other" alerts. Green signifies no alert, yellow signifies at least one warning, and red signifies at least one alarm level alert. Clicking within this area will display the Alert Detail Table for more specific information on the alerts.

18651: SQL definitions added for optional history tables

Several changes have been made to the history table SQL schemas. 1) SQL table schema definitions have been added for those history tables that are disabled in the default configuration. Those tables are: OCMCACHESERVICESTATS_TABLE OCMINVOCATIONSERVICESTATS_TABLE OCMCACHESTATS_TABLE OCMSTORAGESTATS_TABLE OCMPROXYSERVICESTATS_TABLE OCMPROXYSERVICETOTALS_TABLE OCMEXTENDCONNECTIONS_TABLE OCMJVMGCINFO_TABLE OCMJVMMEMORYPOOL_TABLE OCMJMXMGMTDATA_TABLE Definitions have also been added for two legacy tables. These tables do not store historical data, but errors may be thrown to the console if they are not found. HISTORY HISTORY_S 2) The max length for VARCHAR columns has been increased across all history tables to 255. Users should not need to modify existing tables.

Version 1.3.0 Release Notes

Alerts

18357: Central and backend notifications implemented

Alert notifications in EM have been enhanced to support notifying in the central alert server. In previous releases, alert notifications were executed in the solution package data servers, but now notifications are done centrally. In order to support this, the previously supported notifications properties are no longer being used. See the upgrade notes section below if you have modified or overridden the values for any of the notification properties. The following properties are defined in rtvapm.properties for notifications: sl.rtview.alert.notifierenabled - Set to true to enable alert notifications. This defaults to true. To disable alert notifications, set this to false. sl.rtview.alert.notifiercommandnew - Set this to the command to execute when a new alert is generated. This defaults to executing the my_alert_actions.bat. To execute my_alert_actions.sh, set the following: sl.rtview.cmd_line=-sub:$scriptEnding:sh. To execute a different script with the same arguments, set the following (where my_script is the name of your script): sl.rtview.cmd_line=-sub:$alertActionScript:my_script sl.rtview.alert.notifiercommandfirstsevchange - Set this to the command to execute the first time an alert changes severity. The default for this is the same as the sl.rtview.alert.notifiercommandnew. sl.rtview.alert.notifiercommandcleared - Set this to the command to execute the when an alert is cleared. By default, no command is configured. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. sl.rtview.alert.notifiercommandchanged - Set this to the command to execute when a column in the alert table changes. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. This must be used in conjunction with the sl.rtview.alert.notifiercolumns property sl.rtview.notifiercolumns - Set this to the name of one or more columns to execute the sl.rtview.alert.notifiercommandchanged notification when they change. For multiple columns, use a semi-colon delimited list. Note that this should be limited to the minimum number of necessary columns, preferably less than 5, as a large number of columns increases the persistence load on the central alert server. You may alternatively execute a custom java command instead of a script for alert notifications. An example of this is provided under RTVAPM_HOME\projects\emsample\custom. To use the sample custom code, you must build it and add the custom package and jar to your application: 1. Run RTVAPM_HOME\projects\emsample\custom\make_classes.bat. This will build the custom handlers and output them in RTVAPM_HOME\projects\emsample\custom\lib\rtvapm_custom.jar. 2. Modify common\conf\custom_handlers.properties to uncomment the sl.rtview.alert. notifiercommandnew line. Also, modify the sl.rtview.cp line to %RTVAPM_HOME%/projects/emsample/custom/lib/rtvapm_custom.jar. You can optionally uncomment the sl.rtview.alert.notifiercommandfirstsevchange, sl.rtview.alert.notifiercommandcleared, sl.rtview.alert.notifiercommandchanged and sl.rtview.alert.notifiercolumns lines if you want those additional notifications to execute your custom java command notification. 3. When you run the central alert server, add the following to the command line: -properties:%RTVAPM_HOME%/common/conf/custom_handlers Persistence ========= In the previous release, notifications were executed on the backend server and the standard alert persistence prevented duplicate notifications from executing after restart or failover. Now that notifications occur in the central alert server, you must enable persistence in the central alert server and also setup a standard alert persistence table named ALERT_PERSIST_TABLE_CENTRAL and a notification persistence table named ALERT_NOTIF_PERSIST_TABLE in your ALERTDEFS database. The schema for the ALERT_NOTIF_PERSIST_TABLE is in %RTVAPM_HOME%\common\dbconfig. To enable persistence, override this property in projects\emsample\conf\emcommon.properties: AlertAggregator.sl.rtview.alert.persistAlerts=true The notifiercommandfirstsevchange notification is not persisted and will execute the first time the severity changes on an unacknowledged alert each time the alert server runs. This means you will get notification a notification the first time it changes on a new alert, and again the first time it changes after the central alert server is restarted or fails over. Note that notification information is persisted to the ALERT_NOTIF_PERSIST_TABLE for each notification that is executed. In order to optimize performance of the central alert server, users should limit the number of columns specified in the sl.rtview.alert.notifiercolumns property to the minimum number of necessary columns, preferably less than 5. The more columns you notify on, the more notifications will need to be written to the database. Upgrade Information The following properties from rtvapm\common\conf\rtvapm.properties have been removed or replaced. If you have modified any of these properties in rtvapm\common\conf\rtvapm.properties or overridden them in your properties file, you will need to make the following modifications. sl.rtview.alert.alertcommand - use sl.rtview.notifiercommandnew instead. Also set the same value on the sl.rtview.notifiercommandfirstsevchange property if you want to receive a notification the first time the severity changes on an alert. If you do not want to receive notifications the first time the severity changes on an alert, set sl.rtview.notifiercommandfirstsevchange to a blank value. sl.rtview.alert.renotificationmode - This property is no longer supported. sl.rtview.alert.renotifyonsevchangedmode - This property is no longer supported. This property previously defaulted to 1. If you set it to 0, set the sl.rtview.notifiercommandfirstsevchange to a blank value. If you set it to 1, set the sl.rtview.alert.notifiercommandfirstsevchange to the same value as sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property to Severity<remove>. With this configuration, you will get a notification the first time the Severity changes. If you want to be notified every time the Severity changes, use the sl.rtview.alert.notifiercommandchanged property and set sl.rtview.alert.notifiercolumns to Severity. sl.rtview.alert.renotificationcommand - This property is no longer supported. sl.rtview.alert.renotficationtime - This property is no longer supported. sl.rtview.alert.commentcommand - This property is no longer supported. To receive notifications when the comment changes, set the sl.rtview.alert.notifiercommandchanged to the value you previously used for the commentcommand property. Set the sl.rtview.alert.notifiercolumns property to Comments. sl.rtview.alert.alertclearedcommand - This property is no longer supported. Use the sl.rtview.alert.notifiercommandcleared property instead.


18450: Alert Detail Table display has been refactored

The Alert Detail Table display has been refactored for optimization. Instead of querying the alerts directly from the central alert server, those alerts are now cached locally. This means a new cache needs to be loaded into the Viewer and Thin Client applications: rtv_alerts_cache_local.rtv This is included in appmon\conf\appmon.properties for all applications that use the AlertClient or AlertCollector property filters: # Local cache of RtvAlertTable AlertClient.sl.rtview.cache.config=rtv_alert_cache_local.rtv # This is needed to support appmon1 mode AlertAggregator.sl.rtview.cache.config=rtv_alert_cache_local.rtv If your Viewer or Thin Client application uses the RTView Alerts Table display and does not use one of those property filters, you will need to add this cache in your properties file. Also, some of the columns in the alert table have been modified. The Last Occurrence column is now named Last Update Time and the Source2 column has been removed. This will have no impact on the built-in displays, but users that have customized the rtv_alerts_table display from previous versions will need to apply their changes to the new version of the rtv_alerts_table instead of using the customized version from a previous release.


18555: rtv_alert_manage.rtv buttons incorrect for number of alerts

In previous releases, the rtv_alerts_manage display that comes up from the Annotate button in the Alert Detail Table showed the buttons for a single selected alert, even when multiple alerts were selected. This has been fixed.

18564: Dual alerts display

The RTView Alerts Table display has been enhanced to include an optional second table. This table shows all of the open (not cleared) alerts owned by the logged in user. The filters selected in the display will not apply to this table. By default, this table is hidden. To show this table, add the following line to the rtview.properties file in the directory where you run the Viewer or Display Server: sl.rtview.sub=$rtvUserShowDualTables:1 This property was added to emsample\servers\central\rtview.properties, but commented out. This can be set on a per-user or per-role basis if the RTView login is enabled and custom users or roles have been defined. See the documentation for information on how to define substitution values for custom users and roles


18565: On tabular alert administration page, move back to alerts button

To afford quicker access, the "Back to Alerts" button has been moved from the Tabular Alert display's upper left corner to its lower right corner.


18599: Alert engine status indicator added to alert table

The alert tables in EM have been enhanced to show the state of the alert engine that is hosting the alert. If the alert engine that is hosting the alert is not connected, not enabled or not initialized, the background of the row will turn gray. The Own, Suppress, Unsuppress, Close, Annotate, Options and Details buttons will also become disabled when this row is selected.


Customization

18465: Allow custom filters to be added to the Alert table

EM has been enhanced to support custom alert filters. This new feature allows users to setup named filters with values for each of the filters that are supported in the RTView Alert Table display (rtv_alerts_table.rtv). These filters are defined in a new table named CUSTOM_ALERT_FILTERS in the ALERTDEFS database which contains the following columns, all of type String: User Key rtvAlertDynFilter rtvAlertDynTextFilter rtvAlertDynTextFilterRegEx rtvClearedFilter rtvAckFilter ownerFilter rtvWarningFilter rtvCriticalFilter rtvOwnerLoc rtvAreaLoc rtvGroupLoc rtvServiceLoc rtvEnvironmentLoc Users upgrading from previous versions must add this table to their ALERTDEFS database. See the schemas in RTVAPM_HOME\common\dbconfig for the correct schema to use for your database. This table has also been added to the database in emsample. The custom filters are defined per user. To add custom filters, add rows to the database with the following values: User - The name of the user who can use this filter. This must correspond to the value specified for the User in the RTView login. Key - The name of the filter. This value will be used in the Custom Filters combo box. rtvAlertDynFilter - The name of a column in the Alert Table to filter on. This corresponds to the value in the Field Filter combo box in the display. This must be the actual column name, which is sometimes different than the displayed column name. Valid values are blank, Time, Last Update Time, Count, ID, Cleared, Acknowledged, Owner, Alert Name, Primary Service, CIName, CIType, Alert Index, Alert Text, Severity, Source, Cleared Reason, AlertClass, CompID, TicketID, TicketGroup and any other custom columns you have added to the alert table. A blank value indicates this filter should not be used. Note that if you specified a column list as described in task 18467, the list of valid values is limited to the values in the specified column list. rtvAlertDynTextFilter - The value that the column in the rtvAlertDynFilter must equal. This corresponds to the Search Text field in the display. rtvAlertDynTextFilterRegEx: 1 to use Regex for the rtvAlertDynFilter/rtvAlertDynTextFilter filter, 0 otherwise. This corresponds to the RegEx checkbox in the display. rtvClearedFilter - Filter on the Cleared column. This corresponds to the All/Open/Closed radio buttons in the display. Valid values are *, which will show both, false which will show only open alerts and true which will show only closed alerts. rtvAckFilter - Filter on the Suppressed column. This corresponds to the Suppressed checkbox in the display. Valid values are *, which will show both, and false which will show only unsuppressed alerts. ownerFilter - Filter on the Owner column. This corresponds to the Owner Filter combo box in the display. Valid values are *, which will show all, blank which will show alerts that are not owned, and the logged in user name which corresponds to the Owned by Me combo box item. rtvWarningFilter - Filter on Severity = 1 (warning alerts). Valid values are blank, which doesn't show warning alerts or 1 which does show warning alerts. rtvCriticalFilter - Filter on Severity = 2 or 3 (critical alerts). Valid values are blank, which doesn't show critical alerts or 2,3 which does show critical alerts. rtvOwnerLoc - Filter on the CMDB owner. This corresponds to the Owner value in the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not want to filter by CMDB owner. rtvAreaLoc - Filter on the CMDB area. This corresponds to the Area value in the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not want to filter by CMDB area. rtvGroupLoc - Filter on the CMDB group. This corresponds to the Group value in the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not want to filter by CMDB group. rtvServiceLoc - Filter on the CMDB servic. This corresponds to the Service value in the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not want to filter by CMDB service. rtvEnvironmentLoc - Filter on the CMDB environment. This corresponds to the Environment value in the CMDB Filter field. Valid values are any owner in your CMDB or * if you do not want to filter by CMDB environment. The Custom Filters combo box will only show up in the Alert Detail Table display if there are custom alerts defined for the logged in user. This combo box will contain all of the Key values specified for that user. When a value is selected from the combo box, that filter will be applied to the display. The corresponding filter fields will show the applied value and the filter will be applied to the table. If any of the filter fields is then changed such that the filter no longer matches the selected custom filter, the Custom Filter value will be cleared.


18467: Allow users to specify alert table columns

RTView EM has been enhanced to allow you to specify which columns will be displayed in the RTView Alerts tables. This impacts the tables in the following displays and any custom displays that include rtv_alerts_table_common.rtv: rtv_alerts_table.rtv (Alert Views->RTView Alerts Table) rtv_service_citype_summary.rtv (Service Summary Views->Service By CI Type) rtv_service_summary.rtv (Service Summary Views->Service Summary) rtv_allareas_allservices_citype_summary.rtv (Multi Area Service Views->Services CI Type Summary) rtv_area_allservices_citype_summary.rtv (Single Area Service Views->Services CI Type Summary - not included in the default navigation tree) By default, the alert table includes the following columns in the following order: Time (Column Label = First Occ) Last Update Time (Column Label = Last Occ) Count ID (hidden by default) Cleared (Column Label=Closed, hidden by default) Cleared Reason (Column Label=Closed Reason, hidden by default) Acknowledged (Column Label=Sup) Owner Alert Name PrimaryService (Column Label=Primary Service) CIName (Column Label=CI) Alert Text AlertClass CompID TicketID TicketGroup You can override the default columns by adding the following property to the properties file used by your viewer application: sl.rtview.sub=$rtvUserAlertTableColumns:'Time:94 Last Update Time:93 Count:50 ID:50 Cleared:40 Cleared Reason:85 Acknowledged:40 Owner:70 Alert Name:134 PrimaryService:150 CIName:117 Alert Text:1000 AlertClass:83 CompID:75 TicketID:69 TicketGroup:86' Replace everything after the "$rtvUserAlertTableColumns:" with the column names and column widths in the order that you want to see the columns. The above example will configure the tables to display the default columns. The value after "$rtvUserAlertTableColumns:" must be enclosed in single quotes and use the following syntax: 'colName:colWidth colName2:colWidth2' Valid column names are Time, Last Update Time, Count, ID, Cleared, Cleared Reason, Acknowledged, Owner, Alert Name, PrimaryService, CIName, CIType, Alert Index, Alert Text, Severity, Source, AlertClass, CompID, TicketID, TicketGroup and any other custom columns you have added to the alert table. The ID, Cleared and Cleared Reason columns are always included, but are hidden by default. To show them, add the following properties to the properties file used by your viewer application: # Show the Closed column in the alert table if set to 1, hide it if set to 0 sl.rtview.sub=$rtvUserShowCleared:1 # Show the Closed Reason column in the alert table if set to 1, hide it if set to 0 sl.rtview.sub=$rtvUserShowClearedReason:1 # Show the ID column in the alert table if set to 1, hide it if set to 0 sl.rtview.sub=$rtvUserShowId:1 If they are included in the $rtvUserAlertTableColumns, they will be shown in the table in the position specified. Otherwise they will be shown after the columns specified in $rtvUserAlertTableColumns. In rtv_alerts_table.rtv ((Alert Views->RTView Alerts Table), you can also toggle the visibility of these columns using the checkboxes at the bottom of the display. The values in $rtvUserAlertTableColumns are also used to populate the Field Filter combo box in the rtv_alerts_table.rtv (Alert Views->RTView Alerts Table). The Field Filter also always contains the ID, Closed and Closed Reason columns whether or not those columns are visible. By default, the alert tables are sorted by the Time column in descending order to show new alerts first. You can override the sort column and whether to sort ascending or descending by including the following in the properties file used by your viewer application: # Set this to the name of the column on which to sort. sl.rtview.sub=$rtvUserAlertTableSortColumn:Time # Set this to 1 to sort ascending or 0 to sort descending sl.rtview.sub=$rtvUserAlertTableSortAsc:0 You can also change the sort column in the display by clicking on the header of the column you want to sort on. Examples of all of these properties are included in the emsample demo in %RTVAPM_HOME%\projects\emsample\servers\central\rtview.properties. All of the above substitutions can be set on a per-user or per-role basis if the RTView login is enabled and custom users or roles are defined. See the documentation for information on how to define substitution values for custom users and roles


Deployment

18468: Support Dual write in Distributed Alert Server deployments

The Own, Suppress, Unsuppress, and Close buttons on the EM alerts displays have been enhanced to support dual write. It is disabled by default. To enable dual write, include the following property in the properties file for the Viewer or Display Server (in projects\emsample, this is the emsample\servers\central\rtview.properties file): sl.rtview.sub=$rtvUserEnableAlertDualWrite:1 When one of these buttons is clicked, it executes the associated command on the selected alerts in the data server(s) that are hosting the selected alerts. There is sometimes a delay in seeing the result of the action in the alert table. This is because the command goes to the data server hosting the alert, that server updates the alert then pushes the updated alert data to the central alert server, then the central alert server pushes the updated alert data to the client hosting the display. This may be slow in deployments where the data server hosting the alerts are not on the same system where the central alert server and client are running. When dual write is disabled (default), the display updates as described above. When dual write is enabled, the action is applied directly to the alert cache in the central alert server before the action is executed on the data server that is hosting the alert. This reduces the delay between executing the action and seeing the result in the alert table, however it will cause the data in the alert table to be temporarily out of sync with the real alert data. There are several limitations to this feature which must be considered before using it. The following limitations apply when dual write is enabled: 1. If an alert is cleared, clicking on Suppress or Unsuppress will update the central alert server cache, but not the actual alert. The suppressed state of an alert cannot change after the alert is cleared. 2. Clicking on the Close button will immediately update the Cleared value in the alert table, but the Cleared Reason value will not update until the server hosting the alert closes the alert and sends an update. 3. If the server hosting the alert sends an update between the time you click on one of the buttons listed and the time that server processes the associated action, the value in the table will toggle between the new value, and the old value. For example, you select an alert and Suppress it. At the same time, the alert severity changes in the backend server. The table will initially update with old severity with Sup set to true, then it will update with the new severity with Sup set to false, then it will update with the new severity with Sup set to true. If you have configured the central alert server to notify when the Sup column changes, you will receive notifications for all 3 of these changes (true, false, true). 4. If the server hosting the selected alert is not connected or not enabled when you click Own, Suppress, Unsuppress or Close, the value in the alert table will update, but this value will not be applied to the real alert. When the server hosting the alert connects again, the value will revert to the previous value. This is not likely to occur because the Own, Suppress, Unsuppress and Close buttons are disabled with the server hosting the selected alert is not connected or is not enabled. However, it is possible that you perform the action just as the server hosting the alert is exiting before the buttons are disabled.


18631: EM .sql files out of sync

Reviewed


Enterprise RTView

Builder

18513: Icon Properties dialog requires Apply or you lose data

A problem has been fixed in the Builder which required the user to click Apply before closing the Icon Properties dialog after configuring a object grid with Icon Class Name = obj_composite and changing the rtvName property value. If the user simply clicked OK in that case, the changes were lost.

18514: Cannot display data for attachment with blank data server sub

A bug has been fixed in the Builder which caused the Display Data dialog to show no data, when a data attachment was selected whose Data Server field was assigned to a substitution whose value was an empty string.

Data Sources

18535: add option to not try ODBC connection for undefined database

In all prior releases, if an sql query or command is executed that references a database name XYZ and there is no definition of XYZ in OPTIONS.ini then RTView attempts to establish an ODBC connection to XYZ. In this release a new coomand-line option has been added to change this behavior: -sqltryodbc:false The option can also be specified in OPTIONS.ini: sqltryodbc false or in a properties file: sl.rtview.sql.sqltryodbc=false If this option is specified and an sql query or command is executed that uses database XYZ and there is no definition of XYZ in OPTIONS.ini, then no ODBC connection attempt will be made and instead the following error message will appear in the console: Undefined SQL database XYZ This option is useful in cases where ODBC connection attempts cause a JVM crash, which has been reported in some JVM versions. Note that RTView will still make an ODBC connection if a database has the "Use ODBC Driver" option checked in the SQL tab of the options dialog, even if the -sqltryodbc:false is specified.


18563: improve perf when incoming data not in time order

The performance of the cache data source has been improved in the case where a cache is configured to keep a history table and the cache's timestamp column is contained in the data tables that are applied to the cache (rather than being added by the cache itself) but the values in that timestamp column are not always in ascending time order in the incoming data tables. The performance improvement is most noticeable when the history table is large, the cache's allowDuplicatesInHistoryFlag property is set to false, and new data is applied to the cache frequently.

18616: synchronization bug when multi-threading is enabled

In the previous release, if the JMX option to Use Multile Threads for Commands and Polled Queries was enabled, a synchronization problem caused data attachments to multiple connections to miss some updates and duplicate others. This has been fixed.

Drill Down

18516: Cannot edit drilldowns with data attachments to functions/vars

A bug in the Builder's Drill Down Properties dialog has been fixed that prevented changes made to existing data attachments from being saved when the user clicked OK.

Functions

18540: Replace function should allow replace with empty string

The eval function replace function should allow an empty string as the second argument, to permit the removal of a character, but in fact this caused an error: Evaluating expression "replace(%str, " ", "")": One string argument and two character arguments are required. This has been corrected.

18569: enhance Set Subs By Lookup to add $ to column names

The Set Substitutions by Lookup function has been enhanced with a new argument, Add Dollar To Column Names. By default, the value is 0 and the function behaves as it did before. If Add Dollar To Column Names is set to 1, each column after the Key column is used to set a substitution regardless of whether or not it starts with $. For columns that do not start with $, a $ is added to the beginning of the column name when it is used as a substitution name.


18589: Combine Multi-Server Tables now keep data after server restart

In previous releases, the table returned by the "Combine Multi-Server Tables" function was cleared when it received the first update from a reconnecting data server, so the table was missing the rows from all the other servers until each of those servers sent another update. This problem has been fixed.

General

18581: cache history query not run if no cache props attached to data

A bug has been fixed that prevented the initial sql query from being run to fill cache history tables in some configurations. The problem occurred if a cache was configured with constant values for all of its properties and either the cache had no current data or the current data was provided indirectly by a Store Table in Cache function rather than a data attachment on the cache's valueTable property.

Object Library

18545: New drilldown select mode to update ddColumnSubs at data update

The drillDownSelectMode property on obj_table02 now supports a new mode of 2 (Element Only + Auto Update) in addition to the existing modes of 0 (Anywhere) and 1 (Element Only). When drillDownSelectMode is set to 2 the table's command is performed automatically when the row selection changes after a data update. The new mode is available only if the table's command property is configured to perform a drilldown to the current display in the current window, and if the table's indexColumns property is set to a nonempty string. The new mode is useful in cases where the substitutions set by the table's drilldown command need to be updated if some of the selected rows in the table are removed by a subsequent data update.


18546: Support deselecting all rows in a table

The table object (obj_table02) now supports a property named clearSelection. When the property is set to a value of 1, all rows in the table are deselected. When the property is set to a value of 2, all rows are deselected and the table's action or its drillDownTarget are invoked. Typically, a table's clearSelection property would be attached to a local variable that is set by a control object on the same display. For example, say you want a to add a Clear Selection button to a display that contains a table that supports multiple row selection. This could be configured as follows: 1. Add a local variable named $clearSelection with an initial value of 0. 2. Create a button object, with these property values: label : "Clear Selection" valueToSet : 1 varToSet : <attached to the $clearSelection variable> 3. Set these table object's properties: clearSelection : <attached to the $clearSelection variable> 4. If the table object has a drilldown command, or a drillDownTarget, add this to its Drill Down Substitutions: $clearSelection : 0 The last step is required to reset value of the $clearSelection variable to zero when the user selects a row in the table.


18554: New option to not display newlines in row data

The table object (obj_table02) has been enhanced to support removing line breaks from the text displayed in the table cells. To enable this feature, turn on the removeLineBreaksFlag property in the Data Format category. This option will only remove line breaks from the table cell, not from the drill down values. For example, if you have your drillDownColumnSubs setup to set a substitution from a cell with a line break, the substitution value will contain the line break regardless of the removeLineBreaksFlag. This works correctly in the Viewer Application. In the Thin Client, the drill down substitution will not contain the line break if the removeLineBreaksFlag is set. See the PAL for 18582 for more information.


Logging

18379: Change the default configuration for EM to use log4j

A new enhancement has been added to easily set log4j as the default log engine. To set log4j as the default log engine: 1. Edit rtvapm/common/conf/rtvapm.properties and rtvapm/projects/emsample/servers/central/central.properties files and uncomment the following lines in both files: #sl.rtview.cmd_line=-logfile: #sl.rtview.cmd_line=-logdir: #sl.rtview.jvm=-Dcom.sl.rtview.useLog4j=true 2. On Unix, comment out the command line for Windows: #sl.rtview.cmd_line=-log4jprops:%RTVAPM_HOME%/common/conf/sl.log4j.properties and uncomment the command line for Unix: sl.rtview.cmd_line=-log4jprops:$RTVAPM_HOME/common/conf/sl.log4j.properties


Monitor

18044: Add one more level to heatmap label depth

A Service Names checkbox has been added to the Group/Region Heatmap display to allow the Service labels to be shown.


18566: Services CI Summary displays duplicate rows if CI's are not sort

A bug has been fixed where the Service Health By CI Type display was creating multiple rows for the same Service under certain conditions. Now it groups all data into Services correctly, generating just one row per Service.

18592: Add "All CI Types" button to Services CI Type Summary display

An "All CIs" button has been added to permit drilldown to Service Summary display with all CITypes selected. Previously the only way to drill down to Services Summary was by selecting one CIType. In practical usage, you often want to drill down and have all CITypes shown - this button provides that pathway.


CMDB Editor

18446: CI name of a component of a Service shouldn't be * never

Fixed error of allowing the creation of a Service with * as the CI Name.

Solution Package

Amazon CloudWatch

18387: acwmon heatmap needs anchoring

This task fixes a cosmetic display defect. The log and label controls for the acwmon heatmap were not anchored to the upper left corner of the window, so they moved around and obscured other display elements when the page was resized. These controls now remain stationary as display is resized.

IBM Websphere MQ

18520: MQ-BROKER and MQ-QUEUE CI Types added

Two new CI Types have been defined for the MQMON package: MQ-BROKER and MQ-QUEUE. Now MQ Brokers and Queues can be added to the CMDB database and alerts associated to MQ Queues will be propagated into the EM heatmaps. Currently there are no default alerts related to QM Brokers.


Oracle Coherence

18297: New alert CacheQueueSize

The alert OcCacheQueueSizeHigh has been added to trigger when the CacheQueueSize for ALL nodes exceeds a threshold.


18298: New alert OcSendQueueSize

The OcSendQueueSize alert has been added to inform the user when a Send Queue exceeds a given threshold.


18322: Add Days of Data on startup..

The new substitution variable $ocmHistoryTimeSpan has been added to rtview.properties to allow the user to set the number of days of history data that is loaded at startup. The value to be set is based in seconds with the default being 1296000 (15 days).

18407: Support new EM alert notifier

Alert notifications in OC Monitor have been enhanced to support easier integration with EM. In order to support this, the previously supported notifications properties are no longer being used. See the upgrade notes section below if you have modified or overridden the values for any of the notification properties. The following properties are defined in rtvapm.properties for notifications: sl.rtview.alert.notifierenabled - Set to true to enable alert notifications. This defaults to true. To disable alert notifications, set this to false. sl.rtview.alert.notifiercommandnew - Set this to the command to execute when a new alert is generated. This defaults to executing the my_alert_actions.bat. To execute my_alert_actions.sh, set the following: sl.rtview.cmd_line=-sub:$scriptEnding:sh. To execute a different script with the same arguments, set the following (where my_script is the name of your script): sl.rtview.cmd_line=-sub:$alertActionScript:my_script sl.rtview.alert.notifiercommandsevincrease - Set this to the command to execute the first time an alert changes severity. The default for this is the same as the sl.rtview.alert.notifiercommandnew. sl.rtview.alert.notifiercommandcleared - Set this to the command to execute the when an alert is cleared. By default, no command is configured. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. sl.rtview.alert.notifiercommandchanged - Set this to the command to execute when a column in the alert table changes. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. This must be used in conjunction with the sl.rtview.alert.notifiercolumns property sl.rtview.notifiercolumns - Set this to the name of one or more columns to execute the sl.rtview.alert.notifiercommandchanged notification when they change. For multiple columns, use a semi-colon delimited list. Note that this should be limited to the minimum number of necessary columns, preferably less than 5, as a large number of columns increases the persistence load on the central alert server. You may alternatively execute a custom java command instead of a script for alert notifications. An example of this is provided under RTVAPM_HOME\ocmon\sample\custom. To use the sample custom code, you must build it and add the custom package and jar to your application: 1. Run RTVAPM_HOME\ocmon\sample\custom\make_classes.bat. This will build the custom handlers and output them in RTVAPM_HOME\ocmon\sample\custom\lib\rtvapm_custom.jar. 2. Modify common\conf\custom_handlers.properties to uncomment the sl.rtview.alert.notifiercommandnew line. Also, modify the sl.rtview.cp line to %RTVAPM_HOME%/ocmon/sample/custom/lib/rtvapm_custom.jar. You can optionally uncomment the sl.rtview.alert.notifiercommandsevincrease, sl.rtview.alert.notifiercommandcleared, sl.rtview.alert.notifiercommandchanged and sl.rtview.alert.notifiercolumns lines if you want those additional notifications to execute your custom java command notification. 3. When you run the data server, add the following to the command line: -properties:%RTVAPM_HOME%/common/conf/custom_handlers Upgrade Information The following properties from rtvapm\common\conf\rtvapm.properties have been removed or replaced. If you have modified any of these properties in rtvapm\common\conf\rtvapm.properties or overridden them in your properties file, you will need to make the following modifications. sl.rtview.alert.alertcommand - use sl.rtview.notifiercommandnew instead. Also set the same value on the sl.rtview.notifiercommandfirstsevchange property if you want to receive a notification the first time the severity changes on an alert. If you do not want to receive notifications the first time the severity changes on an alert, set sl.rtview.notifiercommandfirstsevchange to a blank value. sl.rtview.alert.renotificationmode - This property is no longer supported. sl.rtview.alert.renotifyonsevchangedmode - This property is no longer supported. This property previously defaulted to 1. If you set it to 0, set the sl.rtview.notifiercommandfirstsevchange to a blank value. If you set it to 1, set the sl.rtview.alert.notifiercommandchanged to the same value as sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property to Severity. With this configuration, you will get a notification each time the Severity changes. If you only want to act on increases, add logic to support this to your script or custom command code. sl.rtview.alert.renotficationcommand - This property is no longer supported. sl.rtview.alert.commentcommand - This property is no longer supported. To receive notifications when the comment changes, set the sl.rtview.alert.notifiercommandchanged to the value you previously used for the commentcommand property. Set the sl.rtview.alert.notifiercolumns property to Comments. sl.rtview.alert.alertclearedcommand - This property is no longer supported. Use the sl.rtview.alert.notifiercommandcleared property instead.


18426: Provide Cluster selection in EM deployments

Cluster Selection display added to Oracle Coherence section of EM Nav tree. A new Cluster Selection display has been added to Oracle Coherence section of EM Nav tree. This allows the user to browse between multiple coherence clusters when EM has been configured to use multiple OCM dataservers.


18435: Values in 'Delta' column missing commas

Delta columns in All Caches - Current Activity Table display are now formatted with "," thousands separator The Delta Columns in the "Totals For Each Cache over all Storage Nodes" table in the "All Caches - Current Activity Table" display are now formatted with "," thousands separator like the non delta numeric columns. Additional Delta Columns that are now formatted with "," thousands separator like the non delta numeric columns, can be found in the following displays: "Single Cache - Cache Detail Tables" display Bottom Table labeled "Statistics By Node for Selected Cache" "Proxy / Extend Detail" display Bottom Table labeled "Extend Client Connections"

18436: Proxy Service CPU % now displayed correctly

Previously, the Proxy Service CPU % may have been displayed incorrectly in various Proxy Services displays. This is no longer the case.


18475: Add Nacks to History and the Node History Heatmap.

To aid in troubleshooting communication errors, the data points "Delta Nacks Sent" and "Rates Nacks Sent" have been added to the Node History heatmap display. Both appear in the Metric drop-down list, and both have been added to the tooltips for both heatmaps (Process and Storage Nodes) on that display.

18476: TCMP additional Data.

New Columns added to the OcNodeStats Cache and Database Table New columns that reflect the state of TCMP traffic on a per node basis have been added to the the OcNodeStats Cache and persisted to the corresponding Database Table (OCM_NODESTATS) to enable historical analysis. The Columns contain Delta and Rate information obtained from the raw (incrementing) count value. The new columns are DeltaNackSent, DeltaPacketsResentEarly, DeltaPacketsResentExcess, RateNackSent, RatePacketsResentEarly, RatePacketsResentExcess.

18490: Departed Nodes not correctly being displayed

The Departed Nodes indicator on the Cluster Overview display, and the Departed Nodes table on the Cluster Stability Metrics display, were inaccurate in their reporting of departed nodes. This has now been fixed, and required a change to the ocmRowExpirationTimeForDelete property in the rtview.properties file. This property is now set to 86400, which allows the OCMonitor to wait 24 hours before removing records of expired nodes.

18492: New alerts for Cache status

Two new alerts, OcEndangeredCache and OcNodeSafeCacheTwo, have been added to allow for notification when StatusHA values become NODE-SAFE and ENDANGERED.


18541: Add new alerts to show the # of nodes falling below a threshold

Three new alerts have been added to trigger when node counts dip below their respective thresholds: OcLowTotalNodeCount, OcLowStorageNodeCount, OcLowClientNodeCount. The three alerts are disabled by default.

Oracle Database

18456: History now displayed correctly for all trend charts

The "read-thru" cache access to historical data was misconfigured for oramon historical data, with the result that history displays were limited to data currently residing in the cache. This has been corrected so that history plots now scroll smoothly back in time to show all available data.


Oracle Weblogic

18568: Missing table: WLS_SERVERTOTALSBYCLUSTER

See RN of TN18570.

18570: Database schema updates

The sql schemae for table creation have been updated to account for the latest changes on cache configuration. All strings have been expanded to 255 chars size.


TIBCO BusinessEvents

18495: BE process not showing up properly

The BE Clusters Table now shows all configured BE connections, even when the BE node (process) is not running. The previous display behavior was no entries in the table for nodes that were down when EM starts. This change ensures that you see problems independently of when EM starts.

TIBCO BusinessWorks

18406: Integrate new EM alert notifier

Alert notifications in BW Monitor have been enhanced to support easier integration with EM. In order to support this, the previously supported notifications properties are no longer being used. See the upgrade notes section below if you have modified or overridden the values for any of the notification properties. The following properties are defined in rtvapm.properties for notifications: sl.rtview.alert.notifierenabled - Set to true to enable alert notifications. This defaults to true. To disable alert notifications, set this to false. sl.rtview.alert.notifiercommandnew - Set this to the command to execute when a new alert is generated. This defaults to executing the my_alert_actions.bat. To execute my_alert_actions.sh, set the following: sl.rtview.cmd_line=-sub:$scriptEnding:sh. To execute a different script with the same arguments, set the following (where my_script is the name of your script): sl.rtview.cmd_line=-sub:$alertActionScript:my_script sl.rtview.alert.notifiercommandsevincrease - Set this to the command to execute the first time an alert changes severity. The default for this is the same as the sl.rtview.alert.notifiercommandnew. sl.rtview.alert.notifiercommandcleared - Set this to the command to execute the when an alert is cleared. By default, no command is configured. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. sl.rtview.alert.notifiercommandchanged - Set this to the command to execute when a column in the alert table changes. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. This must be used in conjunction with the sl.rtview.alert.notifiercolumns property sl.rtview.notifiercolumns - Set this to the name of one or more columns to execute the sl.rtview.alert.notifiercommandchanged notification when they change. For multiple columns, use a semi-colon delimited list. Note that this should be limited to the minimum number of necessary columns, preferably less than 5, as a large number of columns increases the persistence load on the central alert server. You may alternatively execute a custom java command instead of a script for alert notifications. An example of this is provided under RTVAPM_HOME\bwmon\sample\custom. To use the sample custom code, you must build it and add the custom package and jar to your application: 1. Run RTVAPM_HOME\bwmon\sample\custom\make_classes.bat. This will build the custom handlers and output them in RTVAPM_HOME\bwmon\sample\custom\lib\rtvapm_custom.jar. 2. Modify common\conf\custom_handlers.properties to uncomment the sl.rtview.alert. notifiercommandnew line. Also, modify the sl.rtview.cp line to %RTVAPM_HOME%/bwmon/sample/custom/lib/rtvapm_custom.jar. You can optionally uncomment the sl.rtview.alert.notifiercommandsevincrease, sl.rtview.alert.notifiercommandcleared, sl.rtview.alert.notifiercommandchanged and sl.rtview.alert.notifiercolumns lines if you want those additional notifications to execute your custom java command notification. 3. When you run the data server, add the following to the command line: -properties:%RTVAPM_HOME%/common/conf/custom_handlers Upgrade Information The following properties from rtvapm\common\conf\rtvapm.properties have been removed or replaced. If you have modified any of these properties in rtvapm\common\conf\rtvapm.properties or overridden them in your properties file, you will need to make the following modifications. sl.rtview.alert.alertcommand - use sl.rtview.notifiercommandnew instead. Also set the same value on the sl.rtview.notifiercommandfirstsevchange property if you want to receive a notification the first time the severity changes on an alert. If you do not want to receive notifications the first time the severity changes on an alert, set sl.rtview.notifiercommandfirstsevchange to a blank value. sl.rtview.alert.renotificationmode - This property is no longer supported. sl.rtview.alert.renotifyonsevchangedmode - This property is no longer supported. This property previously defaulted to 1. If you set it to 0, set the sl.rtview.notifiercommandfirstsevchange to a blank value. If you set it to 1, set the sl.rtview.alert.notifiercommandchanged to the same value as sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property to Severity. With this configuration, you will get a notification each time the Severity changes. If you only want to act on increases, add logic to support this to your script or custom command code. sl.rtview.alert.renotficationcommand - This property is no longer supported. sl.rtview.alert.commentcommand - This property is no longer supported. To receive notifications when the comment changes, set the sl.rtview.alert.notifiercommandchanged to the value you previously used for the commentcommand property. Set the sl.rtview.alert.notifiercolumns property to Comments. sl.rtview.alert.alertclearedcommand - This property is no longer supported. Use the sl.rtview.alert.notifiercommandcleared property instead.


TIBCO EMS

18405: Integrate with new EM alert notifier

Alert notifications in EMS Monitor have been enhanced to support easier integration with EM. In order to support this, the previously supported notifications properties are no longer being used. See the upgrade notes section below if you have modified or overridden the values for any of the notification properties. The following properties are defined in rtvapm.properties for notifications: sl.rtview.alert.notifierenabled - Set to true to enable alert notifications. This defaults to true. To disable alert notifications, set this to false. sl.rtview.alert.notifiercommandnew - Set this to the command to execute when a new alert is generated. This defaults to executing the my_alert_actions.bat. To execute my_alert_actions.sh, set the following: sl.rtview.cmd_line=-sub:$scriptEnding:sh. To execute a different script with the same arguments, set the following (where my_script is the name of your script): sl.rtview.cmd_line=-sub:$alertActionScript:my_script sl.rtview.alert.notifiercommandsevincrease - Set this to the command to execute the first time an alert changes severity. The default for this is the same as the sl.rtview.alert.notifiercommandnew. sl.rtview.alert.notifiercommandcleared - Set this to the command to execute the when an alert is cleared. By default, no command is configured. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. sl.rtview.alert.notifiercommandchanged - Set this to the command to execute when a column in the alert table changes. To execute a script, copy the notifiercommandnew line and replace $alertActionScript with the name of the script you want to execute. To execute a custom java command, see the example in common\conf\custom_handlers.properties. This must be used in conjunction with the sl.rtview.alert.notifiercolumns property sl.rtview.notifiercolumns - Set this to the name of one or more columns to execute the sl.rtview.alert.notifiercommandchanged notification when they change. For multiple columns, use a semi-colon delimited list. Note that this should be limited to the minimum number of necessary columns, preferably less than 5, as a large number of columns increases the persistence load on the central alert server. You may alternatively execute a custom java command instead of a script for alert notifications. An example of this is provided under RTVAPM_HOME\emsmon\sample\custom. To use the sample custom code, you must build it and add the custom package and jar to your application: 1. Run RTVAPM_HOME\emsmon\sample\custom\make_classes.bat. This will build the custom handlers and output them in RTVAPM_HOME\emsmon\sample\custom\lib\rtvapm_custom.jar. 2. Modify common\conf\custom_handlers.properties to uncomment the sl.rtview.alert. notifiercommandnew line. Also, modify the sl.rtview.cp line to %RTVAPM_HOME%/emsmon/sample/custom/lib/rtvapm_custom.jar. You can optionally uncomment the sl.rtview.alert.notifiercommandsevincrease, sl.rtview.alert.notifiercommandcleared, sl.rtview.alert.notifiercommandchanged and sl.rtview.alert.notifiercolumns lines if you want those additional notifications to execute your custom java command notification. 3. When you run the data server, add the following to the command line: -properties:%RTVAPM_HOME%/common/conf/custom_handlers Upgrade Information The following properties from rtvapm\common\conf\rtvapm.properties have been removed or replaced. If you have modified any of these properties in rtvapm\common\conf\rtvapm.properties or overridden them in your properties file, you will need to make the following modifications. sl.rtview.alert.alertcommand - use sl.rtview.notifiercommandnew instead. Also set the same value on the sl.rtview.notifiercommandfirstsevchange property if you want to receive a notification the first time the severity changes on an alert. If you do not want to receive notifications the first time the severity changes on an alert, set sl.rtview.notifiercommandfirstsevchange to a blank value. sl.rtview.alert.renotificationmode - This property is no longer supported. sl.rtview.alert.renotifyonsevchangedmode - This property is no longer supported. This property previously defaulted to 1. If you set it to 0, set the sl.rtview.notifiercommandfirstsevchange to a blank value. If you set it to 1, set the sl.rtview.alert.notifiercommandchanged to the same value as sl.rtview.notifiercommandnew and set the sl.rtview.alert.notifiercolumns property to Severity. With this configuration, you will get a notification each time the Severity changes. If you only want to act on increases, add logic to support this to your script or custom command code. sl.rtview.alert.renotficationcommand - This property is no longer supported. sl.rtview.alert.commentcommand - This property is no longer supported. To receive notifications when the comment changes, set the sl.rtview.alert.notifiercommandchanged to the value you previously used for the commentcommand property. Set the sl.rtview.alert.notifiercolumns property to Comments. sl.rtview.alert.alertclearedcommand - This property is no longer supported. Use the sl.rtview.alert.notifiercommandcleared property instead.


18527: New alerts for low producers/consumers of topics

Two new alerts for EMSMON have been added: EmsTopicsConsumerCountLow and EmsTopicsProducerCountLow. These alerts are triggered when consumerCount and subscriberCount metrics from topics reached a defined minimum threshold.


18531: Small column size defined for name in EMS_DURABLES table

Dbconfig schemae have been updated to increase the size of the string type to 255 characters. Since the change has been an increase in the size of strings, there is no possible loss of data. To upgrade and keep previous history data available, you should perform the following steps: 1. Rename tables to tableName_prev. E.g. EMS_DURABLES to EMS_DURABLES_prev 2. Load the new schemae 3. Copy all rows from tableName_prev to tableName. E.g. Copy all rows from EMS_DURABLES_prev to EMS_DURABLES

18533: create alert for INACTIVE EMS Servers in EMSMON

A new alert, EmsServerNotStarted, has been added to EMSMON to inform about servers not being properly started.


Version 1.2.5 Release Notes

Enterprise RTView

Alerts

18553: Custom object properties and event attributes are now restored

In previous releases, persisted custom event attributes and alert object properties were not restored correctly. This has been fixed.

18577: Timing problem with persisting disabled state during terminate

After the addition of task 18308, the alert engine sometimes incorrectly persisted the alert engine state as disabled during terminate or fail-over. This has been fixed.

Functions

18591: Last table rows function returns incorrect value, may deadlock

In 6.2.0 the Last Table Rows function returned an extra row if the Index Column Names argument was blank. If the function was used in certain cache configurations, it could also deadlock. Both problems are fixed.

18602: Mark Time Gaps func throws array bounds exception.

A bug in 6.2.0 has been fixed that caused the Mark Time Gaps function to throw an ArrayOutOfBoundsException if a time gap was found in an integer data column.

Platform Support

18587: Support for Solaris 10

On Solaris 10, certain executable scripts need to be modified to use the bash shell. This will now be done automatically by fixperms.sh. In this case the script will print: fixperms.sh: modify the following scripts to use bash ... rtvapm_common.sh rtvapm_ports.sh start_rtv.sh status_rtv.sh stop_rtv.sh unix_run_apm_builder.sh unix_run_apm_database.sh unix_run_apm_dataserver.sh unix_run_apm_displayserver.sh unix_run_apm_historian.sh unix_run_apm_viewer.sh fixperms.sh: done.

Version 1.2.4 Release Notes

Configuration

18471: Clarify database configuration

Updated dbconfig schemas to minimize the need to edit the files.


Distribution

18209: Enhance fixperms.sh to avoid dos2unix issues

The script fixperms.sh would fail if dos2unix was not found or if it was found but expected more than one argument. This has been fixed.


RTView Core

Data Sources

18441: Queue browser fix when msgs have inconsistent props or fields

In previous releases, data attachments to the Queue Browser would throw an exception and fail to return data if all of the messages in the queue did not use the exact same properties and fields. This has been fixed.

Layouts

18409: Enhanced anchor property to support anchor objects

The anchor property has been enhanced to support anchoring to anchor objects and also to supporting floating within the extent of anchor objects. The anchor property is applied when the window containing the display is resized only if the Resize Mode is set to Layout. The Resize Mode is set in the Background Properties dialog. It is also applied to objects in the composite display when a composite is resized and its resizeMode is set to Layout. Otherwise, this property is ignored. By default, objects are not anchored and they float within the extent of the display. For example, if the display is 100 pixels wide and objX is 50, when you resize the display to be 200 pixels wide, the object's objX will move to 100. You can also select an anchor object to float inside. In this case, the object will float within the specified anchor object maintaining its relative position within the anchor object's extent. The object's center must be inside the anchor object's extent and the list of available anchor objects in the Float Inside list in the Anchor Property Dialog is limited to the anchor objects with extents that contain this object's center point. When an object is anchored, you may select an anchor for the top, bottom, left and right sides of the object. If you select Display, that side of the object will be anchored to the corresponding side of the display. When the display resizes, the number of pixels between the specified side of the object and that side of the display remain constant. If an object is anchored on opposite sides (ie. Top and Bottom or Left and Right), the object will be stretched to fill the available space. If you select an anchor object, that side of the object will be anchored to the center of the specified anchor object. When the display resizes, the number of pixels between the specified side of the object and the center of the anchor object remain constant. Only objects that support the objWidth and objHeight properties support anchoring on opposite sides. If an object has the dock property set, the anchor property is ignored. Circular anchor references are not allowed. An object cannot anchor to itself directly or indirectly. To make an object available for use as an anchor object, select the isAnchorObject property for that object. When Anchor Property Dialog is open, all of the available anchor objects in the display will show a tooltip displaying their name. Since an anchor object is referenced by name when anchoring to an object or floating inside an anchor object, you must not have multiple anchor objects with the same name. This could potentially happen when using include files. This can be avoided by assigning a unique value to the objName property of objects in an include file. For example, you might append "_Header" to the name of each object when building an include file named Header.rtv.

Solution Package

TIBCO BusinessWorks

17735: Show Business Works Version in Engine Display

The All BW Servers table and All BW Engines table have been enhanced with the addition of a column showing the version of TIBCO BusinessWorks in use on each BW server.


18130: Create scripts to manage multiple configurations of servers

RTView has been enhanced with the addition of commands to start, stop, and get the status of multiple processes (servers and clients) that are managed together. For any type of deployment there is a set of RTView processes to manage; we will refer to this set of processes as a ?configuration?. Configurations are specified in a simple text file in your project settings directory named rtvservers.dat. (See note about project settings directories below.) Here is an example file: default . dataserver rundata default . historian runhist -ds default . displayserver rundisp -ds default . database rundb Each line has four fields: ? The configuration name (?default? in this case). This may be any name you choose. ? The location of the project settings directory, relative to the location of the rtvservers.dat file (?.?, or current directory, in this case) ? The property filter which identifies the server (specifically, the property filter under which the server?s JMX port is defined). By default this is the server name: dataserver, displayserver, historian, etc. ? The command line used to start the process. Typically you will use one of the following commands: Command Process started rundata Data Server runhist Historian rundisp Display Server rundb Database (HSQLDB) runv Viewer The command line may include additional arguments such as -properties and ?propfilter. *NOTE: the commands listed above may also be used directly in a command prompt or shell window. On Windows you may type the commands as shown; on Unix systems you must add .sh to each command, e.g. rundata.sh, runv.sh, etc. *NOTE: you may write the paths using forward-slash notation on both Windows and Unix systems. For example if your project settings directory were located in a sub-directory below the location of your rtvservers.dat file, you would write the path as ./subdirectory on both Windows and Unix. The above example is for a web application deployment. In the case of a desktop deployment you would not start the Display Server, and you would start the Viewer desktop application; in this case the rtvservers.dat file could look like this: default . dataserver rundata default . historian runhist -ds default . viewer runv -ds default . database rundb Here are the three commands that, together with the rtvservers.dat file, enable you to manage your configurations: Command Description start_rtv Starts servers and clients using the run command line stop_rtv Stops servers and clients using their defined JMX ports status_rtv Displays status of servers and clients using their defined JMX ports *NOTE: On Windows you may type the commands as shown; on Unix systems you must add .sh to each command, e.g. start_rtv.sh, stop_rtv.sh, etc. Each command used without arguments will give a usage message and list the available configurations: > start_rtv Usage: start_rtv config [server] or 'all' Available configs: default As indicated, each command may take: ? the name of a configuration, in which case the action will apply to all the servers or clients specified in the configuration ? the keyword all, in which case the action will apply to all configurations in the file ? the name of a configuration followed by the name of a server, in which case the action will apply only to that server (or client) as specified in the configuration In addition the start_rtv command may take: ? an optional argument ?console (or ?c). Normally the processes are started without a command window (on Windows) or standard output to the console (Unix); this argument changes this behavior and is useful for testing. ? Other optional arguments to be included in the run command line. *NOTE: On Windows the HSQLDB server (if used) will always run with a command window and cannot be stopped via the stop_rtv command. You may stop it by typing ctrl-C in its command window. Here are some examples using the default configuration. *NOTE: since there is only one configuration in the default file, the following commands could specify all as well as default for the configuration. > start_rtv default Start default: dataserver: Executing rundata -bg displayserver: Executing rundisp -ds -bg historian: Executing runhist -ds -bg database: Executing start/min rundb > status_rtv default Status default: dataserver: Running PID 4696 Uptime 000:00:01:47 CPU 00:00:02 Heap 0.7% Clients 2 displayserver: Running PID 6340 Uptime 000:00:01:45 CPU 00:00:01 Heap 1.0% Displays 0 historian: Running PID 6108 Uptime 000:00:01:42 CPU 00:00:01 Heap 1.3% Connected true database: Running PID 6848 Uptime 000:00:01:39 CPU 00:00:00 Heap 0.4% Note the Data Server reports two clients: those are the Display Server and Historian, both of which were started with the ?ds argument, telling them to connect to the Data Server. Note also the Historian reports it is connected to the database > stop_rtv default dataserver Stop default: dataserver: Stopped PID 4696 via JMX port 3368 > status_rtv default Status default: dataserver: Running PID 6256 Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 displayserver: Running PID 2216 Uptime 000:00:02:48 CPU 00:00:00 Heap 1.1% Displays 0 historian: Stopped database: Running PID 6848 Uptime 000:00:10:57 CPU 00:00:00 Heap 0.6% Note that with the Historian stopped, the Data Server has only one client. > start_rtv default Start default: historian: Executing runhist -ds -bg Note the start_rtv command only tries to start processes it determines to be stopped. The status_rtv command will report if a configured port is in use but the process using it does not appear to belong to RTView: dataserver: Data port xxx in use by PID yyy displayserver: JMX port xxx in use by PID yyy If no JMX port is configured the stop_rtv command will just report : dataserver: No JMX port configured; must kill PID xxx by system command. If the port is in use but the PID is not available (HP-UX, some Linux systems) then the stop_rtv and status_rtv command will report the PID as ?????, for example: dataserver: Running PID ??? Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 dataserver: Stopped PID ??? via JMX port 3368 Finally, please note the following. If multiple configurations are specified in the rtvservers.dat file with different locations for the project settings directory, the all argument will cause them all to be processed. However if they are specified with the same startup directory they are considered alternative configurations and only the first one will be processed. For example you might have two installed RTView monitors and want to start them both: bwmon ./bwmon dataserver rundata bwmon ./bwmon historian runhist -ds bwmon ./bwmon displayserver rundisp -ds bwmon2 ./bwmon2 dataserver rundata bwmon2 ./bwmon2 historian runhist -ds bwmon2 ./bwmon2 displayserver rundisp ?ds In this case the all argument would cause both configurations to be processed. On the other hand you might want to have alternative configurations for one RTView monitor, such as desktop deployment and browser deployment: desktop ./bwmon dataserver rundata desktop ./bwmon historian runhist -ds desktop ./bwmon viewer runv -ds browser ./bwmon dataserver rundata browser ./bwmon historian runhist -ds browser ./bwmon displayserver rundisp -ds In this case the all argument would cause only the first configuration to be processed. The second configuration could be processed by referring to it explicitly, e.g. start_rtv browser.


18460: UPTIME value mismatch in displays

The values for BW Engine Uptime displayed in the All Engines table were incorrectly formatted, and were inconsistent with the (correct) values on the Engine Summary page. This has been fixed.

18473: Solaris Sparc support

The EM scripts use to start, stop, and run processes, would fail on Solaris 11 systems. This has been corrected. On Solaris 10 systems the scripts are not compatible with "sh" (which is a strict Bourne shell). As a workaround you can edit the scripts to specify a different shell. The shell "bash" is recommended, but if it is not available "ksh" may be used instead. Edit the following files in $RTVAPM_HOME/common/bin and change the first line from "#!/bin/sh" to "#!/bin/bash": rtvapm_common.sh rtvapm_ports.sh start_rtv.sh status_rtv.sh stop_rtv.sh unix_run_apm_builder.sh unix_run_apm_database.sh unix_run_apm_dataserver.sh unix_run_apm_displayserver.sh unix_run_apm_historian.sh unix_run_apm_viewer.sh


TIBCO EMS

17891: Support for Queue and Topic browsing

The EMS Monitor has been enhanced to support queue and topic browsing. To browse the contents of a queue, navigate to EMS Destinations->Single Queue Summary (ems_queue_summary.rtv), select the queue you would like to browse and click the Browse button. By default, the queue browser is limited to showing 100 messages. To increase this limit, override the following properties in rtview.properties: collector.sl.rtview.jms.maxQueueMsgCount=100 To browse the contents of a topic, navigate to EMS Destinations->Single Topic Summary (ems_topic_summary.rtv), select the topic you would like to browse and click the Browse button. Users running EMS Monitor as a solution package in EM who are upgrading from a previous release will need to uncomment this line in rtview.properties: # Include the EMSMON solution package rtvapm_package=emsmon


18129: Create scripts to manage multiple configurations of servers

RTView has been enhanced with the addition of commands to start, stop, and get the status of multiple processes (servers and clients) that are managed together. For any type of deployment there is a set of RTView processes to manage; we will refer to this set of processes as a ?configuration?. Configurations are specified in a simple text file in your project settings directory named rtvservers.dat. (See note about project settings directories below.) Here is an example file: default . dataserver rundata default . historian runhist -ds default . displayserver rundisp -ds default . database rundb Each line has four fields: ? The configuration name (?default? in this case). This may be any name you choose. ? The location of the project settings directory, relative to the location of the rtvservers.dat file (?.?, or current directory, in this case) ? The property filter which identifies the server (specifically, the property filter under which the server?s JMX port is defined). By default this is the server name: dataserver, displayserver, historian, etc. ? The command line used to start the process. Typically you will use one of the following commands: Command Process started rundata Data Server runhist Historian rundisp Display Server rundb Database (HSQLDB) runv Viewer The command line may include additional arguments such as -properties and ?propfilter. *NOTE: the commands listed above may also be used directly in a command prompt or shell window. On Windows you may type the commands as shown; on Unix systems you must add .sh to each command, e.g. rundata.sh, runv.sh, etc. *NOTE: you may write the paths using forward-slash notation on both Windows and Unix systems. For example if your project settings directory were located in a sub-directory below the location of your rtvservers.dat file, you would write the path as ./subdirectory on both Windows and Unix. The above example is for a web application deployment. In the case of a desktop deployment you would not start the Display Server, and you would start the Viewer desktop application; in this case the rtvservers.dat file could look like this: default . dataserver rundata default . historian runhist -ds default . viewer runv -ds default . database rundb Here are the three commands that, together with the rtvservers.dat file, enable you to manage your configurations: Command Description start_rtv Starts servers and clients using the run command line stop_rtv Stops servers and clients using their defined JMX ports status_rtv Displays status of servers and clients using their defined JMX ports *NOTE: On Windows you may type the commands as shown; on Unix systems you must add .sh to each command, e.g. start_rtv.sh, stop_rtv.sh, etc. Each command used without arguments will give a usage message and list the available configurations: > start_rtv Usage: start_rtv config [server] or 'all' Available configs: default As indicated, each command may take: ? the name of a configuration, in which case the action will apply to all the servers or clients specified in the configuration ? the keyword all, in which case the action will apply to all configurations in the file ? the name of a configuration followed by the name of a server, in which case the action will apply only to that server (or client) as specified in the configuration In addition the start_rtv command may take: ? an optional argument ?console (or ?c). Normally the processes are started without a command window (on Windows) or standard output to the console (Unix); this argument changes this behavior and is useful for testing. ? Other optional arguments to be included in the run command line. *NOTE: On Windows the HSQLDB server (if used) will always run with a command window and cannot be stopped via the stop_rtv command. You may stop it by typing ctrl-C in its command window. Here are some examples using the default configuration. *NOTE: since there is only one configuration in the default file, the following commands could specify all as well as default for the configuration. > start_rtv default Start default: dataserver: Executing rundata -bg displayserver: Executing rundisp -ds -bg historian: Executing runhist -ds -bg database: Executing start/min rundb > status_rtv default Status default: dataserver: Running PID 4696 Uptime 000:00:01:47 CPU 00:00:02 Heap 0.7% Clients 2 displayserver: Running PID 6340 Uptime 000:00:01:45 CPU 00:00:01 Heap 1.0% Displays 0 historian: Running PID 6108 Uptime 000:00:01:42 CPU 00:00:01 Heap 1.3% Connected true database: Running PID 6848 Uptime 000:00:01:39 CPU 00:00:00 Heap 0.4% Note the Data Server reports two clients: those are the Display Server and Historian, both of which were started with the ?ds argument, telling them to connect to the Data Server. Note also the Historian reports it is connected to the database > stop_rtv default dataserver Stop default: dataserver: Stopped PID 4696 via JMX port 3368 > status_rtv default Status default: dataserver: Running PID 6256 Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 displayserver: Running PID 2216 Uptime 000:00:02:48 CPU 00:00:00 Heap 1.1% Displays 0 historian: Stopped database: Running PID 6848 Uptime 000:00:10:57 CPU 00:00:00 Heap 0.6% Note that with the Historian stopped, the Data Server has only one client. > start_rtv default Start default: historian: Executing runhist -ds -bg Note the start_rtv command only tries to start processes it determines to be stopped. The status_rtv command will report if a configured port is in use but the process using it does not appear to belong to RTView: dataserver: Data port xxx in use by PID yyy displayserver: JMX port xxx in use by PID yyy If no JMX port is configured the stop_rtv command will just report : dataserver: No JMX port configured; must kill PID xxx by system command. If the port is in use but the PID is not available (HP-UX, some Linux systems) then the stop_rtv and status_rtv command will report the PID as ?????, for example: dataserver: Running PID ??? Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 dataserver: Stopped PID ??? via JMX port 3368 Finally, please note the following. If multiple configurations are specified in the rtvservers.dat file with different locations for the project settings directory, the all argument will cause them all to be processed. However if they are specified with the same startup directory they are considered alternative configurations and only the first one will be processed. For example you might have two installed RTView monitors and want to start them both: emsmon ./emsmon dataserver rundata emsmon ./emsmon historian runhist -ds emsmon ./emsmon displayserver rundisp -ds emsmon2 ./emsmon2 dataserver rundata emsmon2 ./emsmon2 historian runhist -ds emsmon2 ./emsmon2 displayserver rundisp ?ds In this case the all argument would cause both configurations to be processed. On the other hand you might want to have alternative configurations for one RTView monitor, such as desktop deployment and browser deployment: desktop ./emsmon dataserver rundata desktop ./emsmon historian runhist -ds desktop ./emsmon viewer runv -ds browser ./emsmon dataserver rundata browser ./emsmon historian runhist -ds browser ./emsmon displayserver rundisp -ds In this case the all argument would cause only the first configuration to be processed. The second configuration could be processed by referring to it explicitly, e.g. start_rtv browser.

18303: Added alert for connection count on a server

A new server alert EmsServerConnectionCountHigh has been added to EMS Monitor. This alert will be triggered when the number of connections to the server reaches the specified thresholds.

18369: EmsServerStaleData alert fixed

The EmsServerStaleData alert now works as intended; it fires for active servers but does not trigger for fault-tolerant servers

18472: Solaris Sparc support

The EM scripts use to start, stop, and run processes, would fail on Solaris 11 systems. This has been corrected. On Solaris 10 systems the scripts are not compatible with "sh" (which is a strict Bourne shell). As a workaround you can edit the scripts to specify a different shell. The shell "bash" is recommended, but if it is not available "ksh" may be used instead. Edit the following files in $RTVAPM_HOME/common/bin and change the first line from "#!/bin/sh" to "#!/bin/bash": rtvapm_common.sh rtvapm_ports.sh start_rtv.sh status_rtv.sh stop_rtv.sh unix_run_apm_builder.sh unix_run_apm_database.sh unix_run_apm_dataserver.sh unix_run_apm_displayserver.sh unix_run_apm_historian.sh unix_run_apm_viewer.sh


18519: Alert levels incorrect on EMS Server Table

A bug in the All Servers Table has been fixed that prevented the Alert Level lights from being updated with alert behavior.

VMWare vSphere

18458: drill-down to VM summary from All VMs table is broken

In previous release, some upgrades to the All VM's tabular display broke drill-down from a selected table row to the summary description for the selected VM. This has been fixed, so that it is no longer necessary to re-select the VM via the combo control.

Version 1.2.3 Release Notes

Configuration

18415: OCMON added as dataserver to emsample

OCMON has been added as a dataserver to the emsample directory. The example OCMON dataserver is defined as a dataserver named OCMON-LOCAL as configured in the emsample/servers/central/central.properties file The example OCMON dataserver is not enabled by default . The example OCMON dataserver is not configured (to connect to a coherence cluster) by default . To configure the OCMON dataserver (to connect to a coherence cluster) you will have to edit the emsample/servers/ocmon/rtview.properties file The example OCMON dataserver has the config "ocmon" as defined in the emsample/servers/rtvservers.dat file To enable the example OCMON dataserver (for use with start_rtv) you will have to uncomment the ocmon dataserver line in the emsample/servers/rtvservers.dat file e.g. before: #ocmon ./ocmon dataserver rundata -propfilter:maincollector after: ocmon ./ocmon dataserver rundata -propfilter:maincollector You will then be able to start the ocmon dataserver in emsample, implicitly , by using the "all" config e.g. start_rtv all or explicitly e.g start_rtv ocmon dataserver


Monitor

18392: Added WLS-CLUSTER and WLS-CLUSTAPP to emsample

Two new CI Types, WLS-CLUSTER and WLS-CLUSTERAPP have been added to the rtvapm\projects\emsample RTVCONFIG database (DATA/rtvconfig.script). Now WebLogic Clusters and WebLogic clustered applications will be selectable from the CI table of the CMDB Admin display under their CI Type selector.


Solution Package

Oracle Coherence

17248: ObjectCountDelta*Cache now only triggers for back of near-cache

Both the ObjectCountDeltaUpCache and ObjectCountDeltaDownCache alerts have been modified to ensure that no alerts are generated due to object count changes in the front of the near cache. Alerts will only reflect activity in the back portion of a near cache.

17399: History Heatmap for Extend Connections

A History Heatmap has been added that allows for the selection of a proxy node and exposes the Extend Client information. It can be navigated to via Proxy Services / Extend Connections History


17931: Supress unwanted error messages in dataserver logs

Spurious ERROR message no longer occurs Previously, under certain circumstances the proxyServiceConnectionManagerData3_RTDelta function would generate ERROR messages regarding invalid columns. This is no longer the case.

17968: Provide new metrics for the All Node History heatmap

Two new metrics have been added to the All Nodes History Heatmap display. These are: DeltaPacketsSent and DeltaPacketsReceived.


17969: Provide new metrics in the All Caches History display

Five new metrics have been added to the All Caches History Heatmap display. These are: StoreFailures (Delta) StoreReads (Delta) StoreReadMillis (Delta) StoreWrites (Delta) StoreWritesMillis (Delta)


17988: Integrate OCM alerts into the EM framework

The existing set of OCM alerts has been updated to work within the new EM framework.


18014: Integrate OCM custom functions into RTView EM

OCM custom functions are available in EM CSP ocmon. The OCM custom functions are available in the EM CSP ocm by use of the package ocmon and the jar file rtvapm_ocmon.jar

18051: All Caches current size display obscures conn OK light

An indicator light was obscured by a button on the Current Size display. The button has been moved so that the indicator light is now visible.

18165: Cache Summary - Add Delta/Rate Selection

Delta/Rate Selection added to the "Single Cache - Summary" Display A new "Use Rates" Checkbox has been added to the "Single Cache - Summary" display that allows the user to select either Delta values or Rate Values to be used in the display for Trend Graphs and "Activity - Current" Values. Delta/Rate Selection added to the "Single Service - Summary" Display A new "Use Rates" Checkbox has been added to the "Single Service - Summary" display that allows the user to select either Delta values or Rate Values to be used in the display for Requests And Messages Trend Graphs and "Current" Value displays.


18182: Support global alert notification definitions

The alert notification functionality has been enhanced. The changes include: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. Alert notification is now setup through property files, rather than by editing .rtv files. - To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that can now be set: sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand Further information can be found in the alert documentation.


18201: Rename cache names to be consistent with EM naming conventions

All Cache names have changed and been given an OC prefix.

18219: Alert when JMX connections drop

The alert OcNoJmxConnection has been added which will execute after sensing that JMX connection has been disconnected for a set amount of time. By default the alert is set to ON and the default time value is 60 seconds..


18220: OCM Processing Time Alert.

A new alert - OcJmxProcessingTime - will trigger when the sum of the data collection tIme (sum of the JMX Queries) and the data processing Time (sum of all the functions) is greater than the JMX Period * the threshold. The threshold defaults are 80% for warning, 90% alarm. The alert duration default is 0 and the alert is disabled by default.


18221: StoreFailures alert.

An OcStoreFailure alert has been added which can trigger when the DeltaStoreFailures on the CacheTotals Stats exceeds a specified threshold.


18238: Create a Proxy Node History heatmap.

A History Heatmap has been added that displays the sent and received statistics for each of the Proxy nodes. It can be navigated to via Proxy Services / Proxy Nodes History


18416: Update database schemas

The database schema files have been updated, and are now under rtvapm\ocmon\dbconfig.

18421: OcEndangeredAllCaches alert only triggers now for ENDANGERED

OcEndangeredAllCaches alert now only triggers when StatusHA is ENDANGERED. It no longer triggers when StatusHA is NODE-SAFE.


Oracle Database

18438: Update dbconfig files

Dbconfig files for oramon have been updated with table indexes and type columns for all tables.


Oracle Weblogic

18390: Enhance WLM to collect, cache, and display Cluster configuration

A new display "All Clusters Table" has been added to the WebLogic Servers section. This display presents a table of all WebLogic clusters discovered by WLM in all Domains being monitored. Servers that are not defined in a cluster will have a blank cluster name. Additionally, the All Servers Table and Heatmap displays have been enhanced to provide a drop-down selector to filter the servers shown by the cluster to which they belong. Also these two displays now show the Cluster name to which each server belongs and group and sort the servers by Domain and Cluster.


18391: Define WLS Cluster alert for Percent Servers Not Running

A new alert type has been added to WLM: WlsClusterServersPercentNotRunningHigh. This alert will fire whenever the percentage of not-RUNNING servers that are in any cluster exceeds the specified threshold values.


18404: Reworked WLM caches for granularity and performance options

The WLM default data collection behavior has been modifed for performance reasons. Now, by default, the WLM will collect only Server-related metrics, such as Server JVM statistics, Thread Pool statistics, and JDBC statistics. In the sample project supplied with the WLM solution package either stand-alone or under EM, the rtview.properties contains a section of commented out properties that can be selectively configured. These provide granular control over other metrics related to WebLogic applications. Application Servlet and Session statistics can be selectively collected on a per-application or per-server basis. It is typical in applications that use WebLogic for clustered applications to be deployed on a cluster of servers often with a standard naming pattern. The following property may be included multiple times to specify a number of different applications and servers using a wildcard JMX pattern. It is important that the query be as specific as possible to minimize data collection overhead on the Admin Server. The following is an example pattern: sl.rtview.cache.config=wls_servlet_cache_source.rtv $wlsServletPattern:ApplicationRuntime=estore,ServerRuntime=estore* This will collect data for an application named "estore" running on all servers whose name begins with "estore". Multiple entries can be provided for the wls_ servlet_cache_source property. Also in the sample rtview.properties are several additional lines that enable the collection of other metrics. They can be commented out as needed: wls_workmgr_cache.rtv - WorkManager metrics for all apps wls_auxilary_cache.rtv - Miscellaneous data, like JTA stats wls_jmsserver_cache.rtv - JMS Server and Destination stats wls_jmsbridge_cache.rtv - JMS Bridge stats wls_jmspstore_cache.rtv - JMS Persistent Store stats Note: Some of these data sets could be large, and will consume a lot of cpu in collection. Verify performance in your environment.


18427: Provided Clustered App caches and displays

The WLM has been enhanced to provide two new data caches and two new displays for showing Clustered Application data. WebLogic applications that are deployed in a cluster will have a servlet running on each of the servers in the cluster. The Cluster Apps Table display shows a list of all Applications organized by the cluster they are contained in and the aggregate metrics for the entire cluster (total sessions, e.g.) Drilling into one of the Cluster Applications will take you to the Cluster App Summary page, showing a breakdown of activity on the app across each server in the cluster as well as a trend of the aggregate metrics. The two new caches behind these displays are WlsServletTotalsByClusterApp and WlsSessionStatsByClusterApp containing, respectively, servlet totals and session statistics across the entire cluster


18432: Auto-creation of WLS and WLS-APP CI entries

Server and Application data from WebLogic can be now automatically populated to the CMDB. To do so, one first should add the following line to the central.properties file under emsample\servers\central directory: ConfigCollector.sl.rtview.cache.config=rtv_cmdb_source_wls_autocreate.rtv and then enable the collection of application data by commenting out the following line in the rtview.properties file under emsample\servers\wlm directory: sl.rtview.cache.config=wls_servlet_cache_source.rtv $wlsServletPattern:ApplicationRuntime=*,ServerRuntime=*


Version 1.2.2 Release Notes

Enterprise RTView

Data Server

18366: Speed improvement for row delta calculation in data server

The performance of the Data Server and its clients has been improved when tracking and applying changes to large data tables.

Data Sources

18367: Property updateListenersImmedFlag added to cache object

A property named updateListenersImmedFlag has been added to the cache table object (obj_cache table). The property is in the Cache category and is checked by default. In very specific conditions, the property can be unchecked to improve the performance of the Data Server. If updateListenersImmedFlag is checked, then each time new data is stored in the cache the updated contents of the cache's tables are immediately applied to any listeners attached to those tables. This is the default behavior and is appropriate for most caches. If updateListenersImmedFlag is unchecked, the updated contents of the cache's tables are not applied to the listeners immediately after new data is stored in the cache. Instead the listeners are updated on the next RTView update cycle. (The default rtview update interval is 2 seconds). This is more efficient in the case where raw event-driven data is frequently stored in the cache (for example high-frequency event data from a JMS, RV, or RtvAgent data attachment) and the cache's current table or history table can grow large (more than 25k rows) and the cache is maintained in a data server.


18375: Improved row expiration performance

The performance of the cache data source and data server have been improved when rows with random timestamps expire and are removed from the current table of a cache.


Functions

18368: Buffer Rows function no longer loses rows

A bug in the Buffer Rows function has been fixed which made it possible for some rows in the buffer to be lost before the downstream function was updated with those rows.

Version 1.2.1 Release Notes

Solution Package

Oracle Database

18332: Support for Oracle RAC

The caches and top-level drill-down screens for the Oracle db solution package have been re-organized to support RAC databases. The top level screen is a list of databases. Clicking on a database leads to a summary screen, which includes space utilization and a list of instances which host the database. Non-RAC databases are handled the same as RAC databases; the difference is that non-RAC databases have a single instance. A click in the summary screen takes you to a table of instances, which in turn leads to an instance summary. The Reports display is now customizable to include user SQL for additional reports. Customers may add SQL and associated formatting for display columns to the ora_reports.xml file, which can be found in the oramon/projects/sample directory. For use in EM, copy this file to the customized EM project folder for your installation (which should be something like emsample/servers/central). It is not necessary to restart EM after adding new reports to this file. Simply navigate to the Reports screen, and new entries should be immediately available.

Oracle Weblogic

18324: Accomodated for more than one ComponentName per application

Previously, Server Summary trends behaved erratically when there was more than one ComponentName per application. This has been fixed.

18325: Improve metrics going to the all apps summary display

A new metric, New Sessions, has been added to the table. Also time stamp has been formatted to European format.

18326: Add new alert for New Sessions Low

A new alert WlsServerNewSessionsLow has been added to the set of WLM alerts.

18333: wls_allapps_summary trends now always shows history data

Trend graphs have been fixed to plot the whole range of data, which was not the case previously.

18334: Display state of WebLogic server as UNKNOWN if no connection

Expired server state is now shown as UNKNOWN.

18343: Added standard color in All Servers table for expired rows

Expired or inactive servers will appear with gray background to discriminate them easily from the active ones.

18350: Show correct state of all servers, even if not RUNNING

All WLS servers now are displayed in the All Servers Heatmap and Table whether or not they are RUNNING. If the server changes state, the correct state will be reflected in these displays.

18356: Show CPU metric for all WebLogic Servers

The CPU metric now shows up properly for WebLogic servers that use the Oracle SUN JVM. Previously, these servers would always show a value of 0 for the cpu metric.

18360: Add new alert WlsAppNewSessionsRateLow

A new alert has been added to the WLM package, WlsAppNewSessionsrateLow. This alert will fire whenever the rate of new sessions is below the specified warning and alarm thresholds. Overrides may be specified for specific named Applications.


18365: Provide Domain Filter for All Servers Heatmap/Table

A Domain filter has been added to the All Servers Heatmap and Table displays, as well as a checkbox to control whether Inactive servers are shown in the display.

TIBCO BusinessWorks

18327: Server Free Memory MB no longer reported as 0 for linux servers

The BW Monitor metric Server Free Memory MB would be reported as 0 if the Hawk Agent was running on UNIX. This has been corrected.

TIBCO EMS

18330: Alerts fired for standby servers

FT standby servers on EMSMON don't trigger alerts now.

VMWare vSphere

18355: Added sql schemae of history

Example database schemae for our supported databases have been added.

Version 1.2.0 Release Notes

18101: Modify Service Summary to add CI Type filter drop down

A drop-down menu was added to the service summary page, to allow the users to filter the table of CI's by CI type. When drilling down from the Service Summary By CIType display, the CI type filter will be set to the selected CI type


Alerts

18047: Line breaks removed from the Alert Text column

Alerts Table now removes all line breaks from the Alert Text column before displaying it, so all rows in the table use the same space.


18065: Enable user to extend alert enrichment

EM now supports user alert enrichment which allows users to add their own information to RTView alerts in the central alert server. To add a new column to the alert table, add a Custom Alert Definition property to your properties file using the following syntax: sl.rtview.alert.custom_alertdef_prop=name=MyColumnName dataType=string Valid dateTypes are string, boolean, integer and double. To set the value for any column in the alert table, extract rtv_alerts_source_user_include.rtv from RTVAPM_HOME\appmon\lib\rtvapm_appmon.jar. The stdAlertTableEnriched function contains the alert table with the standard alert enrichment applied. Modify the userAlertEnrichedTable function to return your enriched table. To create your enriched table, apply one or more functions to the stdAlertTableEnriched. The last table in the function chain must be userAlertEnriched Note that you are responsible for persisting the information you apply in the userAlertEnrichedTable so that when the central alert server restarts, that information is available.


18066: Allow alert filtering by Owner, Area, and Group

The EM Alerts Table has been enhanced to support filtering alerts based on all of the selected CMDB values. Previously, alerts were filtered by the selected CMDB Service and Environment only. This enhancement adds support for also filtering on the selected CMDB Owner, Area and Group. The Alerts Table view has been enhanced to show the applied CMDB filters. The Service Filter and Env fields and the All button have been replaced by the CMDB Filter field and Clear CMDB Filter button. The CMDB Filter field shows the selected Owner, Area, Service, Group and Environment filters. To clear all CMDB filters, click on the Clear CMDB Filter button. This will only clear the filter on the Alert Table view and will not affect any other displays. To apply CMDB filters to the Alert Table view, open the Alert Table from any of the Views under Multi Area Service View (click on the ! in the yellow triangle). Selecting elements from the heatmaps and tables in these views will set the CMDB filter on the Alert Table view. The displays under All Management Areas will also set the CMDB filters on the Alert Table view. Note that the Alert Table view opened from the navigation panel will only have the Environment filter applied. Users that have made custom displays using the following global variables may need to modify their displays: $rtvOwner, $rtvArea, $rtvGroup, $rtvService. Previously, these variables were initialized to - and now they are initialized to *. Displays that contained logic depending on the - value to mean no filter should change that logic to look for a value of * instead. The behavior when only an Environment filter is applied has changed. Previously, the Environment filter was only applied if there was also a Service filter. The had the effect of showing rows with an empty Primary Service when there was an Environment filter and no Service filter. Now, the Environment filter is applied if the Environment filter is not * regardless of whether or not there is a Owner, Area, Group or Service filter. Since the Environment filter is always applied if it is not *, rows with no Primary Service will not show if there is a non-star Environment filter and no Owner, Area, Group or Service filter.


18109: Custom user alert fields no longer removed during enrichment

In previous releases, user defined custom alert event attributes and custom alert definition properties values were lost during the alert enrichment process. This has been fixed. To prevent the custom alert event attribute values from being lost, you must add a substitution named $rtvAlertCustomEventAttrs to your properties file and it must contain a semi-colon delimited list of your custom alert event names in the order they were specified. To prevent custom alert definition property values from being lost, you must add a substitution named $rtvAlertCustomAlertDefs to your properties file and it must contain a semi-colon delimited list of your custom alert definition property names in the order they were specified. For example: # Add custom alert definition properties and custom alert event attributes to the alert table sl.rtview.alert.custom_alertdef_prop=name=MyNewColumn dataType=string sl.rtview.alert.custom_event_attr=name=TicketRequested dataType=boolean sl.rtview.alert.custom_alertdef_prop=name=TicketStatus dataType=String # This must contain all of the custom_alert_def_prop names in the order # specified above. sl.rtview.sub=$rtvAlertCustomAlertDefs:'MyNewColumn;TicketStatus' # This must contain all of the custom_alert_def_prop names in the order # specified above. sl.rtview.sub=$rtvAlertCustomEventAttrs:'TicketRequested'


18154: Need to filter out the alerts of unwanted packages

A substitution $rtvAlertPackageMask has been added to filter out alerts from unwanted packages in the alert admin display. The default value is blank, to allow all alerts to be managed. The value shuld be a regular expression, for example, the following line will allow alerts whose names start with "Wls" or "Jvm": sl.rtview.sub=$rtvAlertPackageMask:^Wls|^Jvm


18175: Go To CI button is not disabled when multiple alerts selected

A bug has been fixed in the alert table, where if multiple alerts were selected, the Go To CI button remained enabled. It should be disabled.

18215: Provide Aggregate Service alert which fires once for sub-alerts

This task is connected with TN18216. Here we describe the mechanism needed for these special alerts. RTVRULES is the package that needs to be run for this feature. Otherwise, the alerts wouldn't be triggered. It's located under rtvapm\projects\emsample\servers\rtvrules. The alerts are defined in the rtv_emservice_alertdefs.rtv file under appmon\src\rtfiles and are two: RtvEmServiceAlert (A Service has one or more alerts on any of its CIs) and RtvEmServiceAlertImpactHigh (A Service has an Alert Impact higher than the specified threshold on any of its CIs). Let's assume you already have a relationship among services, otherwise, use the RBT on TN18216 to do so. Next, one needs to execute all the needed servers from an initialized command window. 1. Initialize a command window: cd rtvapm rtv_init.bat cd rtvapm\projects\emsample\servers rtvapm_user_init.bat 2. copy under rtvapm\emsample\servers\emsmon and rtvapm\emsample\servers\wlm the corresponding sl.properties located in rtvapm\emsmon\src\rtfiles and rtvapm\wlm\src\rtfiles respectively. 3. modify rtvapm\projects\emsample\servers\rtvservers.dat by adding the text -properties:sl to the end of the line that starts emsmon and wlm dataservers. 4. start the em servers cd to rtvapm\projects\emsample\servers and type start_rtv all this will start the databases the config server, display server, and alert and directory servers 5. in the same directory as before, start the back-end data servers start_rtv [pckg] dataserver, where pckg={emsmon, wlm} 6. start rtvrules start_rtv rtvrules you'll see in the Architecture->System Overview the rtvrules, emsmon, and wlm dataservers in green 7. Perform the RBT of TN18216.


18216: New SERVICE CIType allows references to other services

A new CI Type to associate services has been created. This new CI Type would allow alerts triggered in the associated services to be seen in the belonging service.


18217: Implement Alert Impact aggregation by Component Criticality

An improved formula to compute the Alert Impact of a Service has been developed. It also takes into account the Alert Impact of dependent services.


18227: Service filter on alerts now applied and cleared correctly

Previously, the Service filter was not applied consistently to the Alert Table display and clearing the Service filter on the Alert Table also incorrectly cleared it on other displays. This has been fixed. The new behavior is as follows: - When the alert table is opened by clicking on the ! in a triangle button from any display, the service filter is applied to that window. If the service filter is changed in the main window, that filter will be applied to the open alert window. - When the alert table is opened in the main window or by click on the ^ button in the alert table in the main window, the service filter will not be applied to that display. - When the All button is clicked in any alert table display, it will only clear the service filter on itself. This clear will not apply to other displays.


18242: Provide a view of Alert History

A new display to track alert history has been added. Alerts can be filtered by Alert Name using regular expressions optionally. There is the possibility to chose the time range to inspect. Alerts are indexed by ID and Alert Name. The ID is a unique value provided by the back-end data server. Thus, multiple IDs can exist for different data servers. In this display, on the rightmost side of the table, the Cleared Reason is shown, which can be a DATA UPDATE (the metric has returned to normal thresholds) or MANUAL (one user has cleared/closed the alert manually)


18251: Support for alert notifications in EM

EM has been enhanced to support alert notifications. Notifications are supported in the rtvrules server and in the data collector servers. By default, alerts are configured to execute my_alert_actions.bat whenever a new alert is generated and the first time the severity changes. This script (and a .sh version) is located in RTVAPM_HOME\common\bin. The script contains a commented out line to print alert information to the console. To use this script, do the following: 1. copy my_alert_actions.bat (for windows) or my_alert_actions.sh (for unix) to the directory where you are running the rtvrules or data collector. 2. uncomment the echo line at the bottom of the script 3. if you are on unix, add this line to your rtview.properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh Run the rtvrules or data collector server. When an alert fires, you should see the echo from the my_alert_actions script in the console or log file for that server. You may modify this script as necessary to execute your custom action or specify a different script to execute by adding this property to rtview.properties: sl.rtview.cmd_line=-sub:$alertActionScript:my_script_name You may alternatively execute a custom java command instead of a script for alert notifications. An example of this is provided under RTVAPM_HOME\projects\emsample\custom. To use the sample custom code, you must build it and add the custom package and jar to your application: 1. Run RTVAPM_HOME\projects\emsample\custom\make_classes.bat. This will build the custom handlers and output them in RTVAPM_HOME\projects\emsample\custom\lib\rtvapm_custom.jar. 2. Modify common\conf\custom_handlers.properties to uncomment the sl.rtview.alert.alertcommand line. Also, modify the sl.rtview.cp line to %RTVAPM_HOME%/projects/emsample/custom/lib.rtvapm_custom.jar. 3. When you run the rtvrules or data collector server, add the following to the command line: -properties:%RTVAPM_HOME%/common/conf/custom_handlers When an alert fires, you will see something like this in the console or log file: Custom alert command executed: DOMAINNAME=SLDOMAIN ALERTNAME=JvmNotConnected ALERTINDEX=localhost~SOME_DATASERVER ALERTID=1000 ALERTSEVERITY=2 ALERTTEXT=Server disconnected You may modify this custom command to implement your custom action. The source code is in RTVAPM_HOME\projects\emsample\custom\src\com\sl\rtvapm\custom\RtvApmCommandHandler.java. Modify or replace the outputAlertString function with your custom action. The custom command handler api is described in the RTView Classic documentation under Customization->Custom Functions and Customization->Customization API.


18273: Filters no longer apply to Service Summary views

In previous releases, the alert table in the following views were filtered based on the filters selected in the Alert Table view: Service Summary Views->Service By CI Type Service Summary Views->Service Summary Single Area Service Views->Services CI Type Summary Multi Area Service Views->Services CI Type Summary This has been fixed so that the alert table in the Service Summary views always shows all open, unsuppressed alerts regardless of the filter on the Alert Detail view.


18274: CMDB-driven Alert Viewer added

EM has been enhanced to support an Alert Viewer. This shows the CMDB hierarchy in a tree view in the left panel and the Alerts Table in the main panel. The Alerts Table is filtered to show only the alerts related to the selected node in the CMBD hierarchy tree. For example, when you click on an Area, the alerts are filtered to only show alerts related to the Services in the selected area. To clear the filter on the Alerts Table, click Clear CMDB Filter. The CMDB hierarchy tree is filtered by the Owner, Area, Group and Environment combo boxes at the top of the panel. Each node in the tree has an indicator that is green to indicate no associated alerts or red to indicate one or more associated alerts. The labels for the Services in the tree have the Environment and number of alerts appended to the service name. To run it in the viewer, use the -panelconfig:rtv_alert_panels.xml command line argument. It is already pre-configured for you in the projects\emsample\servers. In that directory, run start_rtv alert-viewer The emsample contains a webapps directory for deploying in the thin client. To run the Alert Viewer, modify webapps\index.html to replace rtv_appmon_panels.xml with rtv_alert_panels.xml, then rebuild and redeploy the war file as usual. When you view this page, the Alert Viewer will be used instead of the regular viewer.


18294: delay sync of central server alerts after backend server restart

The central alert server has been enhanced to delay the synchronization of alerts after a backend server restart until after the backend server has finished initializing its alerts. When a backend alert server exits, its alerts remain in the central alert server table. After it starts back up, the alerts in the central alert server table are synchronized with those in the backend server. Previously, this synchronization occurred before the backend alert server finished initializing the alert table. This resulted in all of the alerts for that server being removed from the central alert server and added back in again. Now, the synchronization is delayed until after the backend server's alert table is initialized.

Configuration

18169: Add option to do indexing for the historian and varchar max

Two new options have been added to control how the Historian creates the database tables: -charlimit:NNN and -index_history_tables:true -charlimit defines the max string length to use in VARCHAR column types. Default is 50 in RTView but it has been set to 255 on rtvapm applications. # # Define the default size of varchar columns in RTVHISTORY database # historian.sl.rtview.historian.charlimit=255 -index_history_tables defines whether indices should be created for new tables, to improve time response when displays are trying to access historical data. It creates one index by the TimeStamp column, and another index for the cache index columns, followed by the TimeStamp column. Default is false in RTView, but it has been set to true for rtvapm applications. # # Add indices when creating tables in RTVHISTORY database # historian.sl.rtview.historian.index_history_tables=true


18173: Implement expiration behavior for the CMDB caches

The Enterprise Monitor CMDB behavior has been improved so that Owner, Area, Group, or Service entries that are deleted will be immediately reflected in the heatmaps and tables that are driven by the CMDB contents. Previously it was necessary to stop the Config Server and restart before these changes would take effect. NOTE:if a custom "CMDB Source" is used, a small modification will be required to append one additional column to the RtvCmdbCITable. This additional column must be named "Source" and contain an entry that uniquely identifies each separate source of CMDB data. This column value must not start with "RTV_"


18189: Provide dos to unix conversion utility for Unix users

RTView APM packages now include a utility to convert text files from DOS to unix format for systems that don't provide "dos2unix" or "d2u" in the form of a script file named "dos2unix.sh" in $RTVAPM_HOME/common/bin. It takes one argument, a filename, and will convert that file and replace it with the converted version.


18299: Provided unix version of make scripts for wars

In emsample/webapps are shell scripts to remake the war files for the rtvagent, rtvdata, rtvdisplay, and rtvquery servlets.


Deployment

18246: Modify CIMap collector to query one DataServer

The rtv_cimap_source.rtv file is used in the EM central.properties file to create a CIMap by searching for CIs of a specified type in a specified DataServer. The previous version was mistakenly configured to query from ALL DataServer, resulting in some performance degradation. The default version of rtv_cimap_source.rt vhas been changed to query from only one DataServer, identified with a $rtvDataServer substitution in its config line. A copy of the older version, which queries all DataServers, has been provided with the name rtv_cimap_source_all.rtv, to be used in case a customer deployment was dependent on this capability.


General

18228: Criticality Level can be 6 when Criticality is empty

A bug has been fixed where when the criticality was blank it was assigned a value of six for purposes of calculating alert impact.

18265: Provided an example of HA in emsample

To avoid loss of data, High Availability (HA) has been implemented. There are three steps involved on configuring HA: 1. Use of the Config Server to reference ALERTDEFS and enable Alert Persistence 2. Take into account the use the newly added ha.properties file in the back-end data servers 3. use two machines to be configured as the PRIMARYHOST and the BACKUPHOST by setting these environment variables. An example of this has been provided in projects\emsample: Properties are contained in a separate properties file. servers/center includes central-ha.properties. For each individual data server there is a separate ha.properties in each dataserver (SP) directory. Also in emsample/server there is a version of rtvservers.dat called rtvservers-ha.dat. This contains all the properties and filter settings for HA support. If you want to use this dat file you have to rename rtvserver-ha.dat to rtvservers.dat. If you use rtvserver-ha.dat, you can start primaries as normal (start all supported). For the backup servers you have to start each server individually. Backup servers are started with start_rtv central-backup. Each individual SP backup dataserver needs wlm-backup, emsmon-backup, etc.


18315: $rtvOwnerMask and $rtvAreaMask now applied to all views

Previously, the $rtvOwnerMask and $rtvAreaMask were not applied correctly to all displays. This has been fixed.


Monitor

18043: Selection of alert in Service Summary remainswhen filters change

There used to be an error where the alert action buttons remained functional after the selected alerts disappeared from the table (for instance, because the user changed the filters). Now buttons will get disabled when selected alerts are not in the table.

18046: Drill down to specific area from CDR heatmap

When drilling down from the Area Table or Heatmap, the Area where the user has clicked will be selected in the next display. In previous versions of the product, only the Owner was selected, but the display showed all Areas. Now the context menu has two new options: Drill Down to Area and Drill Down to All Areas, allowing the user to choose between the old and the new behaviors.


18048: Custom alert detail screens now resize properly in thin client

Custom alert detail drill downs now resize properly in the thin client.


18069: Option to hide data server column on the Service Summary Page

A substitution $rtvShowDataServerColumn has been added to control visibility of DataServerName column in Service Summary display. Set it to 1 or true in your properties or command-line options to show that column. Set it to 0 or false to hide it. Default is 1.


18084: CDR Heatmap - Only shows all environments

The Environment drop-down in Area Table and Heatmap displays used to show the "All" option only. It now shows all Environments like the other CMDB displays.

18099: Add Service Health State heatmap

A new display Service Heatlh Heatmap has been added to the Service Summary Views of EM applications. This display shows a heatmap of different metrics for each CI of a selected Service.


18100: Add Service Summary by CIType table

A new display Service By CI Type has been added to the Service Summary Views of EM applications. This display shows a table with summary alert metrics by CI type.


18102: Enhance Multi/Single Area Service/Group tables

Cosmetic changes to displays: rtv_allareas_allservices_table.rtv rtv_area_serviceinfo_table.rtv rtv_area_table.rtv


18115: Corrected assignment of Crit Level and Criticality

An error has been corrected where the Criticality shown in the heatmap tooltip of the All Areas By Owner heatmap was not always correct. Now the All Areas By Owner table has a Criticality column instead of Criticality Level.


18141: Change Default Area / Service drilldowns to goto CIType Summary

Also, a new substitution has been defined to control the drill-down behavior of heatmaps and tables in the CMDB displays. Set $rtvNavAppRightClickActionFlag to 0 allow drilldown with a single-click. Set it to 1 to enable drilldown on double-click and to prevent drilldown on single click and just set subs. Default is 0. As before, the substitution $rtvNavAppDisplayName defines where to drill down from the area heatmaps and table displays. The default has been changed to rtv_service_citype_summary.rtv


18171: Enhanced Data Server summary under Architecture

The Data Server Summary display has now two additional columns in table: Runtime and Status


18174: Add all services by CI type summary display

A new display Service Health By CI Type has been added to EM. It shows a two-dimensional table of light icons. Columns are CI Types and rows are Services. For each Service in the selected Group, a light icon will describe the maximum alert severity for each CI Type. If there are no CIs for the CI Type, the cell will remain blank; otherwise, the light will be green, yellow, or red depending on the maximum alert severity of all alerts in CI's of that type. The background color of the cells denote the alert impact for that service and CI Type. The lower alert table shows all alerts for the selected combination of Service and CI Type selected.


18193: Improve performance of drop down menus in CMDB displays

Previously, in a browser deployment, the drop down menus in all CMDB displays would take a noticeable time to refresh when the owner dropdown was changed by the user. The times should now have improved significantly.


18243: New Service Status History Heatmap display

A new display to track the history of alerts has been added. Go to the Alert Views->Alerts History Table to track alerts back in time by selecting the appropriate time range and date. Multiple IDs of a given alert in the table indicates that the same alert occurred several times.


18290: Commands in Alert Table work for alerts from multiple servers

In previous releases, the Own, Suppress and Unsuppress buttons on the Alerts Table view did not apply the command correctly when alerts from multiple backend servers were selected. This has been fixed.


CMDB Editor

18104: Allow users to add new services in the CMDB editor

A new display to manage CIs under a hierarchical CMDB structure has been included.


18105: Improve CMDB Admin page so updates/deletes don't require restart

The CMDB Admin page has been enhanced so that updates or deletes to any entry no longer require the Config Server to be restarted. The change will be immediately reflected in the heatmaps and tables affected by the CMDB (the EM Area and Service views)


Scripts

18259: Enhanced EM start\stop\status scripts

The scripts used to start and stop and get status of EM servers have been enhanced as follows: (1) Each command may now take optional arguments such as additional property files or propfilters. *NOTE: To use additional arguments you must either specify a specific server or 'all' to apply the additional arguments to all servers in a given configuration (or all configurations) (2) The usage message has been enhanced to list the servers within each config (as well as to reflect enhancement 1). For example: Usage: start_rtv config or 'all' [server or 'all'] [args...] Available configs: default dataserver historian displayserver database .


18260: Start/stop/status scripts now work on Solaris 11

The EM scripts use to start, stop, and run processes, would fail on Solaris 11 systems. This has been corrected. On Solaris 10 systems the scripts are not compatible with "sh" (which is a strict Bourne shell). As a workaround you can edit the scripts to specify a different shell. The shell "bash" is recommended, but if it is not available "ksh" may be used instead. Edit the following files in $RTVAPM_HOME/common/bin and change the first line from "#!/bin/sh" to "#!/bin/bash": rtvapm_common.sh rtvapm_ports.sh start_rtv.sh status_rtv.sh stop_rtv.sh unix_run_apm_builder.sh unix_run_apm_database.sh unix_run_apm_dataserver.sh unix_run_apm_displayserver.sh unix_run_apm_historian.sh unix_run_apm_viewer.sh


Solution Package

18225: CUSTOM: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

18247: RTVMGR: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand


Amazon CloudWatch

17919: Not all Amazon instances are displayed in acwmon

Amazon made a change in the way data is collected and returned by the CloudWatch interface, and this change broke acwmon collection. In addition to the usual data (%cpu, disk reads, etc), CloudWatch returns metadata for each instance (StatusCheckFailed). The data and metadata are individually timestamped, but the timestamps for the metadata do not match the data timestamps. The datasource adapter attempts to create a row of tabular data for each instance by matching timestamps. Since the metadata timestamps did not correlate, the adapter could not build a complete row, so no data was returned. The adapter now discards metadata, and only the data is returned.

18118: Incorrect table column names

The column names in the All Amazon Instances display have been fixed to match the data in the column.

18119: Accordian nav tree broken

Issues that resulted in "cannot open file ..." popups when clicking on the Alert Views, and Administration nodes of the ACWMon navigation tree have been fixed.

18120: Update Heatmap and summary screen to common EM

To conform with solution pack standards, some cosmetic changes were made to acwmon display screens. When data expires, the background color will change on the Instance Summary screen to reflect a data quality issue. The Instance Heatmap now includes a "labels" switch to optionally label the heat map boxes with the instance ID.

18121: Integration of alerts with EM

Amazon CloudWatch alerts are now disabled by default when the solution pack is first installed. They can be enabled using the Alert Administration display.

18176: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

18197: Provide a property for poll rates

This enhancement allows you to set the CloudWatch polling rate as a property in conf\rtvapm.acwmon.properties file; the substitution $acwQueryInterval sets the rate at which CloudWatch is queried for metrics. By default, we set this rate so that displays will update within 30 seconds of a change in CloudWatch's Basic or Detailed Monitoring metrics. Decreasing $acwQueryInterval will decrease display latency at the cost of increased RTView server and network utilization.

GlassFish Application Server

18180: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand


IBM DB2 Database

18122: Adjusted connections to conform to EM standards

The file names for configuring caches in rtview.properties were changed to conform with best practices. In order to configure a connection to a new database, add the following lines to your rtview.properties: # include following line once for each db2 instance (any database connection defined on # collector.sl.rtview.sql.sqldb line) Using a distinct database name is recommended, # as for example <connectionName> = vhost.db2inst1.sample #collector.sl.rtview.cache.config=db2_cache_source_instance.rtv $dbconn:<connectionName> # include following lines for each db2 database. One connection per database is required. #collector.sl.rtview.cache.config=db2_cache_source_database.rtv $dbconn:<connectionName> #collector.sl.rtview.sql.sqldb=<connectionName> <user> <password> jdbc:db2://<host-or-IP>:50001/<database> com.ibm.db2.jcc.DB2Driver - false false

18123: Updated heatmaps to EM conventions

The size controls have been removed from the All Instances and Database Partitions heatmap displays. Previously, a "Size Metric" combo allowed the user to select a metric from a list to determine the relative size of boxes on these displays. This proved awkward in practice, especially when some metric values were zero (resulting in no box displayed). Hence, the size is now defaulted to a metric that changes rarely (so that boxes are not repositioned on every update) and intuitively reflects physical database size.

18124: Integration of alerts with EM

The following changes were made to conform with solution pack standards for alerts: Names of alert definitions now start with Db2 instead of "db2". Alerts are now disabled by default. Package name has been changed from db2mon to DB2. Displays now use the alert cache from the dataserver to show alert status.

18125: Navigation to displays sometimes not populated with data

Previously the DB2 displays would sometimes fail to load data. This problem has been corrected.

18126: Accidental test query error removed

A test query that was used during development has been removed. This query was in a cache config file used to populate caches, and was found when a data connection to a database was deleted and the connection name used in the data attachment was no longer valid. The invalid connection name caused sql errors to appear in the console window, but did not result in any display failures because the query output was not bound to a cache or any displays.

18127: Changed "Connected" LED to a checkbox on summary display

In conformance with solution pack standards, the "Connected" status on the database summary page is now a checkbox instead of an LED.

18178: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

IBM Websphere Application Server

18187: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

IBM Websphere MQ

18181: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand


Oracle Database

18142: History plots now show gaps when there is a connection outage

The plots in the Oracle Database Summary screen did not correctly depict intervals in which monitoring data was not collected. When data is missing in a historic time sequence, the solution pack standard behavior is to use the Mark Time Gaps function to insert marker rows in the sequence which causes the plot to show a gap. The previous incorrect behavior was to draw a line to bridge the range of missing data points.

18143: Heatmap display added

Heatmaps are a standard display for EM Solution Packages. The first version of EM shipped without this feature. A heatmap for all Oracle databases has been added for this version of EM.

18144: Integration with EM

ORAMON was updated by this task to conform with evolving best practices for solution pack development. Most of the work involved code refactoring with no changes to the displays. Hence, oramon should function as before with no apparent visual changes. However, a file-level substitution variable name was changed; this will impact datasource declarations in rtview.properties. When updating your configuration, please note the rename of a substitution variable: $databaseName to $oraDatabaseName.

18145: Changed "Connected" LED to a checkbox on summary display

In conformance with solution pack standards, the "Connected" status on the database summary page is now a checkbox instead of an LED.

18146: Corrected port for HSQLDB

The TCP port used by hsqldb was set to the wrong port number in server.properties. This was changed so that hsqldb runs on the standard port for stand-alone solution packs, port 9102.

18183: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable, or add "./" to your $alertActionScript in conf/rtvapm_oramon.properties as follows. sl.rtview.cmd_line=-sub:$alertActionScript:./my_alert_actions Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

Oracle Weblogic

18078: Compaction added to all WLM caches with history

JMS caches now have compaction configured. By default, the names of the tables storing historical data of JMS caches are disabled. To enable them, go to rtview.properties file and comment out the following lines: sl.rtview.sub=$WLS_JMSCONSUMER_TABLE:'' sl.rtview.sub=$WLS_JMSPRODUCER_TABLE:'' sl.rtview.sub=$WLS_JMSCONNECTION_TABLE:'' sl.rtview.sub=$WLS_JMSDESTINATION_TABLE:'' sl.rtview.sub=$WLS_JMSDESTINATIONTOTALS_TABLE:'' sl.rtview.sub=$WLS_JMSDURABLESUBSCRIBER_TABLE:''


18080: Update trend graphs with advanced filtering

WLM trend graphs now show historical data properly.

18186: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable. Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

TIBCO BusinessEvents

18147: New TIBCO BusinessEvents Solution package

This is the initial release of the VMWMON solution package for monitoring VMWare hosts and virtual machines via connections to vSphere vCenter and ESXi servers. Limitations: 1. This release of TBEMON was developed and tested using Tibco Business Events 4.x and 5.x. Earlier versions have not been tested, so compatibility is not known at this time. 2, When configuring connections to monitored BE processes, you must explicitly configure for either BE version (4.x or 5.x). If the versions that are deployed are upgraded, you must update the connection configuration (see rtview.properties file). 3. TBEMON uses JMX to collect all BE metrics. In general, applications that use JMX to monitor java processes on a server with the server's firewall enabled may experience connection problems. The JMX protocol allows initial contact on a known port, but subsequent communications may occur over a second randomly chosen port. Version 5 of Tibco Business Events has a fix that allows the follow-on communications to occur over the same port. However, BE version 4.0 does not have this fix. BE 4.0 installations should use a local agent to push the necessary mbean data to the central RTView dataserver, or use a "premain agent" as described in https://blogs.oracle.com/jmxetc/entry/connecting_through_firewall_using_jmx Requirements: 1. Java 1.6


18185: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable, or add "./" to your $alertActionScript in conf/rtvapm_tbemon.properties as follows. sl.rtview.cmd_line=-sub:$alertActionScript:./my_alert_actions Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

VMWare vSphere

18148: New VMWare vSphere solution package

This is the initial release of the VMWMON solution package for monitoring VMWare hosts and virtual machines via connections to vSphere vCenter and ESXi servers. Limitations: 1. This release of VMWMON was developed and tested using vSphere 4.1. Other versions have not been tested, so compatibility is not known at this time. 2, Only hosts and virtual machines are supported. Storage, interfaces, and other resources are not supported. 3. vSphere alerts are not supported. RTView alerts may be enabled for collected host and VM metrics. Requirements: 1. For best performance, the system clocks of the rtview dataserver and all monitored resources should be synchronized to the same NTP source. 2. Java 1.6


18188: Support global alert notification definitions

Alert notification is now user-configurable via properties. The defaults are: - The alert command is my_alert_script.bat. - The alert command executes for new alerts and on the first severity change. To configure notification, you no longer need to modify the .rtv files, just set properties and customize the alert handler script to your needs. - (Windows) To use my_alert_actions.bat, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. - (Linux) To use my_alert_actions.sh, copy it from common\bin to your project directory and modify the end of the script to do the appropriate action. Add your project directory to the start of your path environment variable, or add "./" to your $alertActionScript in conf/rtvapm_vmwmon.properties as follows. sl.rtview.cmd_line=-sub:$alertActionScript:./my_alert_actions Also, add this to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:sh - To use a different script, add it your project directory and add the following to your properties file: sl.rtview.cmd_line=-sub:$alertActionScript:my_custom_script where "my_custom_script" is the name of your script. If it does not use the .bat extension, also add the following to your properties file: sl.rtview.cmd_line=-sub:$scriptEnding:XX where "XX" is the extension for your script. - To use a different command, add the following property to your properties file: sl.rtview.alertCommand=XX where XX is the command to execute. This can be any RTView command string. See the documentation for the alertCommand property on any of the alerts for more information on this. There are also several properties that the user can now set that were not previously documented. You can get more info on these from the alert documentation on the Global Notifications app option tab. At the time this rn was written, the global notifications hadn't been added to the docs yet, but the concepts can be found in Alerts->Alert Types->Limits in the descriptions for these properties: reNotificationMode, reNotificationTime, reNotifyOnSevChangedMode, reNotificationCommand, alertClearedCommand, commentAddedCommand. sl.rtview.alert.renotificationmode sl.rtview.alert.renotificationtime sl.rtview.alert.renotifyonsevchangedmode sl.rtview.alert.renotficationcommand sl.rtview.alert.commentcommand sl.rtview.alert.alertclearedcommand

18196: Provide a property for poll rates

This enhancement allows you to set the polling rate as a property in conf\rtvapm.vmwmon.properties file; the substitutions $vmwQueryInterval and $vmwQueryIntervalSlow set the rate at which vSphere servers are queried for host and virtual machine metrics. The default rate of 20 seconds matches the default rate at which vSphere servers update "real-time" metrics. Hence, these substitutions should not be changed unless the rate is changed for your vSphere configuration.

Version 1.1.1 Release Notes

Alerts

18006: Alert action audits do not capture the user login

An error occurred where the user credential were not passed to the alert action audit table, leaving the User column blank. This error has been corrected.

Deployment

18004: New scripts to manage multiple configurations of servers

RTView has been enhanced with the addition of commands to start, stop, and get the status of multiple processes (servers and clients) that are managed together. For any type of deployment there is a set of RTView processes to manage; we will refer to this set of processes as a ?configuration?. Configurations are specified in a simple text file in your project settings directory named rtvservers.dat. (See note about project settings directories below.) Here is an example file: default . dataserver rundata default . historian runhist -ds default . displayserver rundisp -ds default . database rundb Each line has four fields: ? The configuration name (?default? in this case). This may be any name you choose. ? The location of the project settings directory, relative to the location of the rtvservers.dat file (?.?, or current directory, in this case) ? The property filter which identifies the server (specifically, the property filter under which the server?s JMX port is defined). By default this is the server name: dataserver, displayserver, historian, etc. ? The command line used to start the process. Typically you will use one of the following commands: Command Process started rundata Data Server runhist Historian rundisp Display Server rundb Database (HSQLDB) runv Viewer The command line may include additional arguments such as -properties and ?propfilter. *NOTE: the commands listed above may also be used directly in a command prompt or shell window. On Windows you may type the commands as shown; on Unix systems you must add .sh to each command, e.g. rundata.sh, runv.sh, etc. *NOTE: you may write the paths using forward-slash notation on both Windows and Unix systems. For example if your project settings directory were located in a sub-directory below the location of your rtvservers.dat file, you would write the path as ./subdirectory on both Windows and Unix. The above example is for a web application deployment. In the case of a desktop deployment you would not start the Display Server, and you would start the Viewer desktop application; in this case the rtvservers.dat file could look like this: default . dataserver rundata default . historian runhist -ds default . viewer runv -ds default . database rundb Here are the three commands that, together with the rtvservers.dat file, enable you to manage your configurations: Command Description start_rtv Starts servers and clients using the run command line stop_rtv Stops servers and clients using their defined JMX ports status_rtv Displays status of servers and clients using their defined JMX ports *NOTE: On Windows you may type the commands as shown; on Unix systems you must add .sh to each command, e.g. start_rtv.sh, stop_rtv.sh, etc. Each command used without arguments will give a usage message and list the available configurations: > start_rtv Usage: start_rtv config [server] or 'all' Available configs: default As indicated, each command may take: ? the name of a configuration, in which case the action will apply to all the servers or clients specified in the configuration ? the keyword all, in which case the action will apply to all configurations in the file ? the name of a configuration followed by the name of a server, in which case the action will apply only to that server (or client) as specified in the configuration In addition the start_rtv command may take: ? an optional argument ?console (or ?c). Normally the processes are started without a command window (on Windows) or standard output to the console (Unix); this argument changes this behavior and is useful for testing. ? Other optional arguments to be included in the run command line. *NOTE: On Windows the HSQLDB server (if used) will always run with a command window and cannot be stopped via the stop_rtv command. You may stop it by typing ctrl-C in its command window. Here are some examples using the default configuration. *NOTE: since there is only one configuration in the default file, the following commands could specify all as well as default for the configuration. > start_rtv default Start default: dataserver: Executing rundata -bg displayserver: Executing rundisp -ds -bg historian: Executing runhist -ds -bg database: Executing start/min rundb > status_rtv default Status default: dataserver: Running PID 4696 Uptime 000:00:01:47 CPU 00:00:02 Heap 0.7% Clients 2 displayserver: Running PID 6340 Uptime 000:00:01:45 CPU 00:00:01 Heap 1.0% Displays 0 historian: Running PID 6108 Uptime 000:00:01:42 CPU 00:00:01 Heap 1.3% Connected true database: Running PID 6848 Uptime 000:00:01:39 CPU 00:00:00 Heap 0.4% Note the Data Server reports two clients: those are the Display Server and Historian, both of which were started with the ?ds argument, telling them to connect to the Data Server. Note also the Historian reports it is connected to the database > stop_rtv default dataserver Stop default: dataserver: Stopped PID 4696 via JMX port 3368 > status_rtv default Status default: dataserver: Running PID 6256 Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 displayserver: Running PID 2216 Uptime 000:00:02:48 CPU 00:00:00 Heap 1.1% Displays 0 historian: Stopped database: Running PID 6848 Uptime 000:00:10:57 CPU 00:00:00 Heap 0.6% Note that with the Historian stopped, the Data Server has only one client. > start_rtv default Start default: historian: Executing runhist -ds -bg Note the start_rtv command only tries to start processes it determines to be stopped. The status_rtv command will report if a configured port is in use but the process using it does not appear to belong to RTView: dataserver: Data port xxx in use by PID yyy displayserver: JMX port xxx in use by PID yyy If no JMX port is configured the stop_rtv command will just report : dataserver: No JMX port configured; must kill PID xxx by system command. If the port is in use but the PID is not available (HP-UX, some Linux systems) then the stop_rtv and status_rtv command will report the PID as ?????, for example: dataserver: Running PID ??? Uptime 000:00:00:37 CPU 00:00:01 Heap 1.3% Clients 1 dataserver: Stopped PID ??? via JMX port 3368 Finally, please note the following. If multiple configurations are specified in the rtvservers.dat file with different locations for the project settings directory, the all argument will cause them all to be processed. However if they are specified with the same startup directory they are considered alternative configurations and only the first one will be processed. For example you might have two installed RTView monitors and want to start them both: bwmon ./bwmon dataserver rundata bwmon ./bwmon historian runhist -ds bwmon ./bwmon displayserver rundisp -ds emsmon ./emsmon dataserver rundata emsmon ./emsmon historian runhist -ds emsmon ./emsmon displayserver rundisp ?ds In this case the all argument would cause both configurations to be processed. On the other hand you might want to have alternative configurations for one RTView monitor, such as desktop deployment and browser deployment: desktop ./bwmon dataserver rundata desktop ./bwmon historian runhist -ds desktop ./bwmon viewer runv -ds browser ./bwmon dataserver rundata browser ./bwmon historian runhist -ds browser ./bwmon displayserver rundisp -ds In this case the all argument would cause only the first configuration to be processed. The second configuration could be processed by referring to it explicitly, e.g. start_rtv browser. Note about project settings directories: The project settings directories are created during installation by taking a copy of a sample directory from the distribution. They contain the properties files that specify the configuration and are located outside the distribution directory tree (i.e. rtvapm?) so that they are not overwritten when the distribution is updated. In the case of a standalone monitor (BW, EMS, ...) there will be a single directory copied from the projects/sample directory in the distribution. This will include the example rtvservers.dat file described above. In the case of Enterprise Monitor with multiple Solution Packs, there will be several directories, including one for each solution pack and one named ?central? for the EM servers. In this case the project setings directory may be created by taking a copy of the directory projects/emsample/servers, which might contain the following: bwmon (folder) central (folder) emsmon (folder) rtvmgr (folder) rtvservers.dat (file) In the case the rtvservers.dat file will refer to the subdirectories, for example: ### CENTRAL # # Central Database central ./central database rundb # Central Servers with Config and Alert Servers central ./central ConfigServer rundata_configserver central ./central AlertServer rundata_alertserver central ./central DisplayServer1 rundisp_appmon #central ./central AlertHistorian runhist_appmon ### RTVMGR # rtvmgr ./rtvmgr dataserver rundata #rtvmgr ./rtvmgr historian runhist -ds ### EMSMON # emsmon ./emsmon dataserver rundata #emsmon ./emsmon historian runhist -ds ### BWMON # bwmon ./bwmon dataserver rundata -propfilter:receiver #bwmon ./bwmon historian runhist -ds In the case the command start_rtv all would start the all the configurations, whereas start_rtv bwmon would start only BW Monitor, etc.


Monitor

18042: Drilldown on the Regional Heatmap incorrect

Drilling down from the Regional heatmap has been corrected to take into account the area of the selected service

Solution Package

Oracle Weblogic

18077: Enhance JDBC display to include history trends

The JDBC Summary dashboard has been enhanced with a set of trend graphs that show the main metrics of the selected JDBC module.

Version 1.1.0 Release Notes

Alerts

17321: Alerts added to RTVMGR

A few alerts about JVM metrics have been added: JvmCpuPercentHigh JvmStaleData JvmNotConnected JvmGcDutyCycleHigh JvmMemoryUsedHigh


17626: DBCONFIG schemas updated and moved to common\dbconfig

In previous releases, the schemas in dbconfig were out of date. This has been fixed. They are now located in common\dbconfig.

17818: Multiple index types now populate unassigned indexes correctly

A bug in the Tabular Alert Administration display has been fixed. Previously, if an alert had multiple index types defined, selecting anything other than the first item from the Index Types list would not populate the Unassigned Indexes table properly. This has been fixed.


17898: Added context menu items to alert table displays

The Alerts Table view has been enhanced so that the following menu items are available in the context menu when you right-click on a row in the alert table: Details Own Suppress UnSuppress Close Annotate Go To CI Options The Single Host Summary display has been enhanced so that the following menu items are available in the context menu when you right-click on a row in the alert table: Own Suppress Close Details These items do the same action as the corresponding buttons.


17934: Common/dbconfig alert schemas updated

In previous releases, the alert database schemas did not use a large enough field size for text fields. This has been fixed.


17967: Go To CI button on alert displays fixed

In previous releases, the Go To CI button on the alert views sometimes brought up a blank display. This has been fixed.


Customization

18031: New format available for custom commands

APM packages can now use the newer format for custom commands. The function signature now supported is: public GmsRtViewCommandStatus invokeCommand (GmsRtViewCommand cmd) This provides access to the GmsRtViewCommand object, applications should get the information they need through this object, rather than relying on global data.


General

17352: Enhance common custom handler to work with multiple packages

Custom function, command, and RTView handlers for multiple packages are available in the same project


17470: DisplayDerver default PNG compression factor set to 3

The default Display Server png image compression factor has been set to "3" instead of "9". This reduces the time taken to generate many common displays by a factor of at least 2. This value can be controlled in the rtvapm/common/conf/rtvapm.properties file: displayserver.sl.rtview.cmd_line:-pngcompress:3


17622: Enhance rtvmgr to support Tomcat 7.0

The RTVMGR package has been enhanced to support the modified MBean names in Tomcat version 7.0


17715: Change Common date format for international usage

The format of date in the header of all diaplays has changed to avoid ambiguity in an international context. months are represented with three letters and year is shown with four digits.


18020: Updated rtvmgr project under emsample

The rtvmgr project under emsample has been configured to monitor the central EM servers (config server, alert server, and display server) It references the central.properties to get the JMX connections for the central servers. This is done by adding a reference to central.properties files in custom_setup.bat and .sh. The user can specify additional servers by adding JMX connections to the rtview.properties file


18022: Rename EMS CI Type to EMS-SERVER

The CIType EMS has been renamed to EMS-SERVER


Navigation

17314: RTVMGR navtree now hasTomcat in its own section

A Tomcat section has been added to the default navtree for RTVMGR. Four displays are provided showing a heatmap and table of all servers as well as a heatmap of all applications and an application summary page


Scripts

18009: Provide separate log files for EM data servers

The emsample application has been set up so that the config dataserver and the alert dataserver output to different files (config_dataserver.log and alert_dataserver.log respectively). Previously the dataservers were trying to write to the same file.

Solution Package

Amazon CloudWatch

17864: Network Out field on acwmon's Instance Summary fixed

The network out variable name for the EC2 datasource binding had an extra character appended. Correct value is displayed after fixing the name spelling.


IBM DB2 Database

17701: Modify Summary page to use Db2Summary cache instead of snap

If the login account used for monitoring a DB2 database server does not have adequate privileges, the sql queries used by db2mon will fail. This can be demonstrated by installing DB2, creating a new user for the sample database, and setting up an RTView datasource connection to the sample database using the new user. The default privileges will not be sufficient for all sql queries to succeed, although the Connected flag will be true for the datasource. Perform the following steps to add the privileges necessary for the user. Note that under linux, db2 uses linux accounts and passwords for login. 1. create a linux group "rtv_monitor", and add the user ids that should get monitoring privilege; then in a bash shell, $ db2 update dbm cfg using sysmon_group rtv_monitor $ db2cc 2. expand "All Databases", expand database to be monitored, expand "User and Group Objects", click on "DB Users" folder, click the "Add New User" link, and add a new user with "Connect to database" authority. 3. right click on user name used for monitoring and select "Change...", click Function tab, and set execute permission for the following table functions: SYSPROC.MON_GET_CONNECTION SYSPROC.MON_GET_INDEX SYSPROC.MON_GET_PKG_CACHE_STMT SYSPROC.MON_GET_TABLE SYSPROC.MON_GET_UNIT_OF_WORK 4. restart db2 $ db2stop $ db2start


17702: Modified to use filtered current data

Db2mon was modified to use filtered current data. Instead of transferring the entire contents of a cache from dataserver to client, the dataserver now applies the filter and sends the reduced table to the client, thereby improving performance. A minor cosmetic change was made on "Database Status" screen. The opaque-fill rectangles for "Memory" and "Connections" portlets were deleted; this allows the Data Quality fill color to be seen as background color in these areas. Also, the Start Time and Up Time fields on the Database Summary screen are blanked when a datasource does not connect (previous behavior was to display "zero" time in seconds since 1970, 12/31/1969 23:59:59)


17809: Updated db2mon to support partitioned databases.

The first version of db2mon supported non-partitioned databases. This release supports databases with up to 1000 partitions spread across potentially as many virtual or physical hosts, called members. Each named "instance" of a DB2 server can support any number of databases. If partitions are created for the instance, then the "create database" statement will create a database that spans all available partitions by default, or the partitions specified in a named partition group. Db2mon will display status of instances, members, databases, and partitions, using tabular views, grids, heatmaps, and a new reports module. Report module is user extensible by simply adding queries and formatting details to an XML file.


Oracle Weblogic

17866: Enhance alerts for Server and App categories

Alert WlsMemoryUsageHigh has changed its name to WlsServerMemoryUsageHigh. It also has been added a new alert category to capture misbehavior at the application level. There has been added one alert on that level: WlsAppOpenSessionsHigh.


17867: Added Application indicator alert in the server summary display

A new category indicator for Application Alerts has been added to the Server Summary display.


 

 
SL, SL-GMS, GMS, RTView, SL Corporation, and the SL logo are trademarks or registered trademarks of Sherrill-Lubinski Corporation in the United States and other countries. Copyright © 1998-2013 Sherrill-Lubinski Corporation. All Rights Reserved.
 
 
 

JMS, JMX and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. They are mentioned in this document for identification purposes only.

 
 
 

Third Party Notice Requirements