RTView® Enterprise - Release Notes

Version 5.3.0 Release Notes

Alerts

RE-30986: Alert Overrides: Allow adding overrides filtering out indexes by pattern

The Alert Overrides Admin display now allows multiple selection in the table. Multiple rows can be selected to create/edit/remove overrides to many rows at once. NOTE: Even if RTViewCentral is version 5.3 or above, multiple selection will not work against RTViewDataServer installations older than 5.3. The Alert Overrides Admin display now contains a pattern/RegEx filter to manage the contents of the table. The search string or RegEx is applied against the concatenation of all indexes shown in the table. That means a pattern or RegEx can be designed to search on all the index columns at once. For instance, rows containing 'conn1' in the first index and 'abc' in the second index can be found with the pattern '*conn1*abc*' or the RegEx 'conn1.+abc'.

RE-32861: Reduced PK_alertdef key index size for SQL Server

The VARCHAR limit of the ALERTINDEX column for the ALERT_LEVELS database table has been lowered from 2000 to 700 for SQL Server, which has a maximum key length of 900 for clustered indexes.

RE-33825: Enhanced alert interface to allow override for duration period

Alerting has been enhanced to support overriding the alert duration time per alert index. In previous releases, this was only settable at the top level of the alert and applied to all indexes. With this enhancement, each index can be assigned a different duration. To override the duration for an alert index, select the alert in the Alert Administration page and click on Override. For alert indexes that were overridden in previous releases before duration override was supported, the override duration is set to -1. This value indicates that the index will use the top level alert duration. Even if RTViewCentral is version 5.3 or above, duration overrides will not work against RTViewDataServer installations older than 5.3.

RE-33896: Alert Override Admin table rows now limited to one per overridable item

In Alert Admin Overrides display, the table used to show one row per CI, regardless of the override type selected by the user. That caused duplicated rows when the override index count was less than the alert index count. This has been fixed and now the table has been limited to show one single row for each unique combination of the overridable indexes.

RE-33901: Alert event type now transmitted in RTVE SNMP alert notifications

RTView Enterprise snmp alert notifications have been enhanced to include a new field named rtviewAlertNotifType. This contains one of the following strings which identifies the notification type: NEW_ALERT CLEARED_ALERT RENOTIFY_ON_TIMER FIRST_SEV_CHANGE Upgrade Notes ============ The MIB definition in rtvapm\common\lib\SL-RTVIEW-EM-MIB.txt has changed to include the new field. If you are upgrading from a previous release that sent snmp notifications, you will need to update the MIB in your snmp receiver.

Component Displays

RE-34815: Data Server lookup in HTML UI now includes servers that don't yet have data

The dropdown list of data servers that support a specific CI type will now include servers that support that type but don't yet have any data in the caches for that type. In previous versions, those servers were omitted. Note that DataServers which will not be configured to monitor data for a given CI type can be excluded from appearing in the drop down lists by either removing the unused Solution Package from the Data Server configuration, or by exclude those CI's from being sent to the Central Server configuration (under the EM Integration tab).

Configuration

RE-33399: Added controls for securing data server connections using ssl without certs to the Configuration Application

The Security tab in the Configuration Application has been enhanced to include options for securing the client and receiver ports via SSL. When enabled, these ports are secured via SSL and all data is encrypted using an anonymous cipher. However, no certificate is used to perform SSL authentication and therefore the client and server do not verify each other's identities. RTViewCentral does not open a receiver port and therefore only has the option to secure the client port.

Customization

RE-34048: New Custom Display Designer (CDD)

RTViewCentral and SolacePubSubMonitor have been enhanced to include the Custom Display Designer (CDD). The CDD allows you to quickly design and deploy custom displays with your monitor. To access the CDD, open the RTView Configuration Application and click on the CUSTOM DISPLAYS button at the top. In the CDD, click on the help (?) button above the Display List for information on how to get started.

RE-34516: Support for user defined custom alerts

RTView was enhanced to support user defined custom alerts against any single solution package metric. Alerts are defined in json files located in projects\custom\alerts. See the documentation for details.

Deployment

RE-30829: LDAP integration supported

RTView Enterprise and Solace PubSub+ Monitor now include integration between the HTML UI using Tomcat and an LDAP directory. When a user logs into RTView it is located in the directory and authenticated using the given password. Users can be located by a direct name-to-DN association or by searching for a specified attribute. You can search using the credentials of the given user or supply a connectionName and connectionPassword and search using those credentials. Once authenticated, the user is associated with an RTView role according to the entries in a configuration file.

Distribution

RE-33169: Updated jackson libraries to 2.11.0

The Solution Package for TIBCO FTL has been updated to use v2.11.0 of the Jackson libraries. Previously this solution package used v2.9.9 The Solution Package for Solace Monitor and the deliverable for Solace PubSub Monitor have been updated to use v2.11.0 of the Jackson libraries. Previously this deliverable used v2.9.9

RE-33880: Updated apache tomcat to 8.5.56

The bundled version of Apache Tomcat has been updated to v8.5.56 (was 8.5.41)

Key Metrics

RE-33804: New service model flow diagrams

RTView Enterprise has been enhanced to support service diagrams. This feature allows you to define the flow between components in a service which are then displayed in a flow diagram. To access the service diagrams, select a service in the Services tree to bring up the CI Stats Table. Click on the arrow next to CI Stats Table and select Service Diagram. If you are logged in as rtvadmin, you can define relationships between the nodes by clicking on the Link button to the right of the toolbar, then saving your changes. Default layout options are configurable in the RTView Configuration Application and users can save customized diagram layouts to their local browser storage. Upgrade Notes ============ In order to support the service diagrams, 2 new columns were added to the RTVMCDB database: DisplayName and Children. You must update the table structure of the RTVCMDB table by executing the following alter table SQL sentences in your selected database administrative tool: DB2: ALTER TABLE "RTVCMDB" ADD "DisplayName" VARCHAR(15); ALTER TABLE "RTVCMDB" ADD "Children" VARCHAR(2000); SQL Server: ALTER TABLE [RTVCMDB] ADD [DisplayName] VARCHAR(15); ALTER TABLE [RTVCMDB] ADD [Children] VARCHAR(2000); MySQL: ALTER TABLE "RTVCMDB" ADD "DisplayName" VARCHAR(15); ALTER TABLE "RTVCMDB" ADD "Children" VARCHAR(2000); Oracle: ALTER TABLE "RTVCMDB" ADD ("DisplayName" VARCHAR(15), "Children" VARCHAR(2000)); SyBase: ALTER TABLE "RTVCMDB" ADD "DisplayName" VARCHAR(15) NULL, "Children" VARCHAR(2000) NULL; These 2 columns have also been added to the RTViewCmdbCITable cache. The cache source (.rtv) files that are included in the distribution to populate the CMDB have been modified to add these columns if they are not included in the incoming CMDB data. If you have created your own cache source .rtv file that calls a Store Table In Cache function or have developed an application to modify the RtvCmdbCITable cache or RTVCMDB database, you will need to add these 2 columns. Contact SL Technical Support for more information.

Platform Support

RE-33550: Added support for AdoptOpenJDK 8

RTView now supports AdoptOpenJDK 8

RE-33660: Support added for MS SQL Server 2019

RTView now supports using MS SQL Server 2019 for storing historical data, as well as the alert and central configuration database tables for RTView Enterprise and the standalone Monitoring products. The Solution Package for MS SQL Server now also supports monitoring MS SQL Server 2019. Note that the user account used in the connection string must have the View Server State permission assigned to them in the server properties. See your MS SQL Server documentation for more information on this setting. NOTE: SQL Server 2008 and 2014 are no longer officially supported.

RTVMGR

RE-34013: JVM heatmap now groups by Host instead of Source

JVM Heatmap is now arranged by Host rather than Source.

Service Model

RE-34342: HTML CMDB Admin edit interface improved

Some layout errors in the CMDB Admin page have been fixed.

Solution Package for Apache Kafka

RE-33592: Corrected sawtooth graph seen when single dataserver collects from multiple systems.

Previously, when a single RTViewDataServerKafka was configured to collect data from a kafka installation running on multiple systems, the Broker and Topic summary displays showed a sawtooth graph where (approximately) every other data point is 0. This has been corrected.

RE-33863: Support for Confluent Kafka

RTView has been successfully tested with Confluent Community Version 5.4

RE-34450: Kafka monitoring now catches Zookeeper connection failure

The Kafka Monitor now reports failure to connect to a Zookeeper, e.g. ERROR: failed to connect to Zookeeper at 192.168.200.225:1000

RE-34575: New Kafka Topic displays with counts per time interval

There are two new displays in the Topics section, Kafka Topic Counts by Broker and Kafka Topic Counts by Cluster that show any one of the three metrics across hour, day and week periods. The first is per topic and per broker and the second is per topic and summed across the brokers. Two cache tables have been added to Kafka Monitor containing totals for the topic metrics BytesIn, BytesOut and MessagesIn over hour, day and week periods. The cache KafkaServerTopicCounts has these total counts per topic and per broker, while the cache KafkaTopicCounts has the same metrics per topic and summed across the brokers. There are two new history tables for these caches, KAFKA_SERVER_TOPIC_COUNTS and KAFKA_TOPIC_COUNTS.

Solution Package for IBM Websphere MQ

RE-33823: Provide ability to set Queue Manager level alerts

All IBM MQ Queue alerts have now a new index containing the name of its Queue Manager, which can be used to define alert overrides by this column. Queue Manager names no longer contain spaces.

RE-33824: New MQ Queue alerts

Added new alerts: MqQueueMgrDisconnected The queue manager is disconnected MqQueueMgrNotRunning The queue manager is disconnected MqQueueMgrConnectionCountHigh The queue manager has reached the maximum connection count MqQueueOpenInputCountHigh The open input count of a queue has reached the threshold MqQueueOpenOutputCountHigh The open output count of a queue has reached the threshold

RE-33900: Added the Queue Manager column to the Queue Summary display

A Queue Manager column has been added to the IBM MQ Queue Summary display.

RE-34445: Fixed issue in defining alert overrides caused by spaces in alert indexes

Alerts such as MqTopicSubscriberTotalsMessageRateHigh and MqTopicSubscriberTotalsMessageRateLow were failing to define overrides when the subscriber names contain multiple consecutive spaces. This has been fixed.

RE-34521: Added Queue Mgr name and Queue name override for MQ Queue alerts

A new Override Type has been added to all MQ Queue alerts, which allows users to define overrides by both Queue Manager and Queue name.

Solution Package for Solace PubSub+

RE-31555: Solace Monitor now comes with required JAXB jars to run under Java 9+

Previously Solace Monitor would not run under Java 9+, due to the removal of JAXB from the default java runtime. This is no longer the case due to the addition of the required JAXB runtime to the Solace Monitor.

RE-31853: "OS Version" field added to Broker Provisioning Display

The field "OS Version" has been added to the Broker Provisioning display.

RE-33054: Spaces in the Broker connection string no longer prevents alert overrides

Previously a space in a connection name would prevent the user from configuring an alert override against that connection. This has been fixed.

RE-33479: Fixed bar graphs in Broker Capacity Summary

On the Broker Capacity summary page the bar graphs for Ingress/Egress Msgs/s and Ingress/Egress Bytes/s now show percentages relative to the corresponding high-water mark value.

RE-33966: Changed names of Egress columns for Solace Broker Table

In the Solace Brokers Table the following columns have been renamed; Total Sent Discards to Total Egress Discards Sent Discarded Msgs/S to Egress Discarded Msgs/s

RE-34015: Default Max Heap Size for Solace monitoring deliverables has been increased to 4 Gigabytes

The Default Max Heap Size for the Solace Dataserver has been increased to 4 Gigabytes. This applies to both the SolacePubSubMonitor and RTViewDataServerSolace.

RE-34035: Corrected values for some columns in Broker Capacity table

The following columns in the Broker Capacity table now have correct values: Ingress Flow Count % Topic Subscriptions on Queue Used % Current Spool Usage % Connections Used %

RE-34042: Unused "max-ingress/egress" columns removed

The following columns have been removed from the Message Router Capacity Table: Ingress\nMsgs/sec Max Egress\nMsgs/sec Max Ingress\nBytes/sec Max Egress\nBytes/sec Max Ingress\nMsgs/sec % Egress\nMsgs/sec % Ingress\nBytes/sec % Egress\nBytes/sec % Ingress\nMsgs/sec HWM % Egress\nMsgs/sec HWM % Ingress\nBytes/sec HWM % Egress\nBytes/sec HWM % The following fields have been removed from the classic Message Router Capacity Summary display in the % Utilization (current/HWM) section: Egress Msgs/s Ingress Bytes/s Egress Bytes/s Transacted Sessions

RE-34085: Solace SEMP Schemas now loaded from brokers that support that capability

In previous versions, connections would fail for brokers with a later schema version that the most recent supported version in the release. Now with the ability to query schemas from the brokers themselves, this is no longer the case

RE-34316: Bridges Icon now opens connection to Solace Broker when systems have multiple IPs

In previous versions, the "Launch Pub Sub Manager" label on a Solace Broke Icon in the Bridges Diagram display may not have opened a connection to the Solace Broker in an environment where multiple IPs were in use. This is no longer the case.

RE-34345: Support added for broker schema SEMP v9.5

Solace SEMPv1 schemas for Solace Appliance and SW Broker with version 9.5 have been included.

RE-34351: Solace Clients summary page now shows both Client and ACL profiles

On the Solace Brokers Clients Table the column "Profile" has been renamed to "Client Profile". On the Clients Summary both "Client Profile" and "ACL Profile" are now available.

RE-34371: Toolbar enhancements to Bridges Diagram and CSPF Neighbors Diagram displays

Two enhancements have been made to the Bridges Diagram and the CSPF Neighbors Diagram displays. 1) The "alert pill" at the top right corner of the display is now functional. On the Bridges diagram, it now shows the number of alerts with category of Bridge, On the Neighbors diagram, it now shows the number of alerts with category of Appliance, Appliance-Pair, VPN, ApplianceCapacity, Client, Bridge, or Endpoint. On either diagram, a click on the alert pill will navigate to the Alerts Table by Component display with the filter set to the aforementioned category or categories. In previous versions, the alert pill always read "No Alerts" and a click navigated to the component alert display but with with filter incorrectly set to filter out all alerts. 2) The toolbar at the top of the diagram now supports several additional features, described below. View Options: (Globe icon): Toggle the visibility of the overview panel. (+ icon): Zoom in on the diagram by 25% (- icon): Zoom out on the diagram by 25% The overview on/off option is pesistent for a browser session. For example if you toggle the overview on it will remain on even if you navigate to another display and then back to the diagram later. The zoom level is not persistent, it is reset to 100% each time you navigate to a the diagram display. Neither the overview toggle or the zoom level are saved with the diagram layout options (described below). Layout Options: (Layout dropdown list): Select a layout type to apply to the diagram. A brief description of each type is given in the paragraph below. You can also click and drag the nodes to lay them out manually. (Recycle icon): Apply the selected layout type. This is useful to restore the layout after clicking and dragging the nodes, e.g. if you want to start over. (Horiz tree icon): Use a horizontal flow (applies to tree and graph layout only). (Vert tree icon): Use a vertical flow (applies to tree and graph layout only). (Save icon): Save the layout options including the positions of any manually moved nodes to the local browser storage. This will be used instead of the default layout whenever you view this diagram in the browser where it was saved.  (Reload icon): Restore the layout options in the toolbar to the locally saved layout if there is one, otherwise to the selected layout. (Trashcan icon): Delete the locally saved layout options, if any. The tree and graph layouts are useful on diagrams where the flow (links) between nodes go mostly in one direction, from one or more root nodes to child nodes, then to grandchild nodes, etc. The graph layout attempts to keep the nodes arranged neatly in rows or columns, the tree layout will pack the nodes more closely together. The net layout can be useful for diagrams where the flow between nodes goes in multiple directions. The circle layout can be useful for diagrams where the flow is mostly in one direction but where there are also links from the deepest child nodes back to top level nodes. Another minor change in this version is that the black outline has been removed from the nodes. Otherwise, the node and link appearance and coloring is unchanged from previous releases.

RE-34424: Added "CPU Cores" metric to the Solace Brokers Table display

The "CPU Cores" metric has been to the Solace Brokers Table display This metric is retrieved by the "show system" SEMP request. UPDATE NOTE: This SEMP request has been added to the supplied pollers_sl.xml and groups_sl.xml files. Users may need to merge these updates with any changed versions of these files.

RE-34425: Solace Syslog Event Summary Display has been added

A Solace Syslog Event Summary Display has been added to display the contents of a Syslog Event. A Syslog Event can be selected from the Solace Syslog Events Table, and drilled down to in the Solace Syslog Event Summary

RE-34434: Corrected alert descriptions of SolClientInboundByteRateHigh and SolClientInboundMsgRateHigh

The descriptions for the following alerts have been corrected to say "inbound" instead of "outbound" SolClientInboundByteRateHigh SolClientInboundMsgRateHigh

Solution Package for TIBCO BusinessWorks

RE-31864: Fixed expiration in BW6 caches

If a BW AppNode is stopped the corresponding row in the AppNode table should be marked expired after the configured interval. This was not working correctly: the row would cycle between expired and not expired every update.

RE-32031: Additional memory and CPU usage data added to BW6 Container displays

Additional columns for CPU and memory usage have been added to the All Containers Table, and a new section of trends labeled "Resources" has been added to the Container Summary.

RE-33048: "App Space:" labels should be "AppSpace:" for all AppNodes displays

The label "App Space" has been corrected to "AppSpace" in the following TIBCO BusinessWorks displays: Applications Heatmap Application Summary Application Nodes Table Application Nodes Heatmap Application Node Summary

RE-34055: Implemented workaround for issue related to BW 6.4.2 "null engine info" bug

The BW OSGi plugin has been adjusted so that applications running in a BW 6.4.2 environment, which is exhibiting the "null engine info" bug, are not incorrectly identified as container deployments

RE-34343: Support for multiple targets added to BW osgi plugin

The RTView BW OSGi plugin has been enhanced with the ability to send to multiple targets. The plugin property "sl.rtview.rtvagent.target" can now take a comma-separated list of receivers, in which case the plugin will send to multiple targets. For example: sl.rtview.rtvagent.target=receiver1:3272,receiver2:3272,receiver3:4272

Solution Package for TIBCO FTL

RE-33516: Fixed Client drop down in the FTL Client Summary display

In the TIBCO FTL Client Summary display the Client dropdown will now correctly select a client and thus the client's data will be properly displayed. Note the ID selector has been removed from that page.

RE-34421: Added LD_LIBRARY_PATH note to FTL Connections UI

The following note has been added to the Classpath section of the FTL Connections UI: In order to connect to TIBCO FTL on Unix systems, you must also add this directory to LD_LIBRARY_PATH.

Version 5.2.1 Release Notes

Configuration

24648: Restore scroll position after closing dialog in Config UI

The Configuration Application has been enhanced to restore the scroll position after opening a dialog on the following pages: - Alerts - Databases - Security - Apache Kafka CONNECTIONS - Solace CONNECTIONS

24688: Default text now editable in Configuration Application

The behavior of the default value in text entry fields in the Configuration Application has been enhanced. Text entry fields that are set to the default value show the default value in gray to indicate that it is the default. When you click on it, the text now becomes editable to make editing default values easier. To return to the default, delete the edited text.

24713: Miscapitalization in classpath description

In the Configuration Application, the word "containing" had been capitalized in certain instances, where no capitalization was required. This has been fixed.

24795: rest api for setting properties works again with Tomcat

The rest-api for updating properties was not accessible in version 5.2.0 when the rtvadmin servlet was deployed on Tomcat. This has been fixed.

24796: Enhanced sample app for editing properties

The sample application for editing properties (rtvapm/sampleapps/propeditor) has been enhanced for ease of use. The host, port and path variables can now be set from environment variable and the installation process has been simplified. See the README.txt in the sample application's directory for more details.

General

24723: Added export to excel and copy cell value options to common cache viewer

The common cache viewer has been enhanced to support Export to Excel and Copy Cell Value options on the table. The common cache viewer is hosted in Jetty at http://localhost:XX70/common where XX is the port prefix for your data server.

24736: Table on System Overview now fills available vertical space

The table of data servers on the System Overview display will now grow vertically if there is space available. Previously its height was fixed at 200 pixels.

24737: Cache Table display no longer breaks after changing server

In prior releases the Cache Table display (Components/Other/Common/System/Cache Table) became unresponsive if the user sorted or filtered the lower table on the display, and then selected a server from the Data Server list on which the previously selected cache did not exist.

RTView Core Functionality

24604: Format the alert text to at most 2 decimal digits

The Alert Text in the Alert Table has been enhanced to format decimal values to 2 decimal digits.

Alerts

24756: Log message when alert table limit is exceeded

The alert engine was enhanced to print a warning when the alert count limit is exceeded. In previous releases this warning was only printed when logging was enabled.

Data Historian

24767: Improved Historian insertDataIntoDbTable performance for prepared statements

The performance of the historian has been improved. It now performs commits on batches of inserts, as defined by the historian's cache_size property, rather than one commit per insert. This reduces overhead in some databases. Also, in verbose mode a message is logged for each such commit as follows: ... committing the following number of records from cache: <N>, msec = M This matches the behavior of the historian before prepared statements were supported in release 4.2.

24768: Historian continues writing to database after connection is lost and restored

A problem has been fixed which sometimes caused the historian to stop storing data after the database connection was lost and then restored.

Data Sources

24707: New database ping feature added to SQL data source

An option named "dbping" has been added to the SQL data source. It can be used to specify a simple SQL query to be run periodically on a specified database connection. This is intended to keep the database connection alive on systems where idle connections are closed, for example by a firewall between the host running RTView and the database server's host. Typically a simple database vendor-specific query would be used for this purpose. For example: Oracle: SELECT 1 FROM DUAL SQL Server: SELECT COUNT(*) FROM SYSOBJECTS MySQL: SELECT 1 The dbping option is specified in an RTView properties file as follows: sl.rtview.sql.dbping=name=N;interval=I;query=Q where: N = the database connection name (required) I = ping interval in seconds (optional, default = 300) Q = sql query for ping (required) For example: sl.rtview.sql.dbping name=MyOracleDB;interval=600;query=SELECT 1 FROM DUAL As with all periodic sql queries in RTView, the query is not guaranteed to be performed at the exact interval specified but within a few seconds. In RTView Enterprise, the dbping property can be added on the CUSTOM PROPERTIES tab of the Configuration Application. For example, the following could be specified for use on the RTView history database connection for an Oracle database: Name: sl.rtview.sql.dbping Value: name=RTVHISTORY;interval=600;query=select 1 from DUAL Filter: dataserver

General

24706: Pinger feature added to rtvquery servlet

The rtvquery servlet will now ping the data server after 5 minutes of inactivity. (The connection is inactive when no web clients are actively sending queries to the servlet). The ping is intended to keep the servlet's connection to the data server alive on systems where idle connections are automatically closed, for example by a firewall between the host running tomcat and the data server's host. If the interval needs to be changed, add the following property to the rtvquery.properties file: PingerIntervalSec=N where N is the desired interval in seconds, or 0 (zero) to disable the ping feature.

Solution Package

TIBCO BusinessWorks

23810: Hawkmon now shows NAS and SAN mount points

Hawkmon has been enhanced to get its storage metrics using the method getByFileSystem which returns many logical filesystems in addition to the physical storage previously displayed. The customer may specify what filesystem types to include in the displays by setting the substitution variable $hawkFileSystemTypes to a pattern. The default is collector.sl.rtview.sub=$hawkFileSystemTypes:'^ext.' which gives the same result as previously. To display all filesystem types use collector.sl.rtview.sub=$hawkFileSystemTypes:'*'

Solution Package for Apache Kafka

24207: Reduced excessive "Table structure has changed" errors in log

The logfile for a data server collecting from a zookeeper previously had multiple entries of: ERROR: function <kafkaZookeeperSA1>, Table structure has changed; cannot save data., type:DELTARATEROWS This message now only appears once (benignly) at startup.

Solution Package for Solace PubSub+

24861: Increased precision of some columns in Broker Capacity table

The number of decimal places has been increased for the following columns in the Broker Capacity table: Ingress Flow Count % Ingress Flow Count HWM % Spool Files Used % Spool Files Used HWM %

24116: Dynamic connection updates via rest API now supported for StatsPump DS

The StatsPump data collection now supports updating connection properties via rest api. A sample application that shows how to use the rest api is available under rtvapm\sampleapps\propeditor. See the README.txt in that directory for instructions on using the rest api. You can also refer to the "Property Editor REST API" section of the User Guide for more details. LIMITATION: Connections that are removed will not consistently display as Expired in all displays, particularly the Brokers and Capacity screens. Removed items will be reliably deleted in all screens according to the configured Delete Time.

24341: Msg ingress/egress alerts switched from %utilization to Msg/s

SolMsgRouterMsgEgressUtilHigh and SolMsgRouterMsgIngressUtilHigh alerts have been removed from the list of available alerts, as they incorrectly assumed a hardcoded maximum value in order to compute a percentage of utilization. Two new alerts, SolBrokerEgressMsgRateHigh and SolBrokerIngressMsgRateHigh, have been introduced to alert on the ingress and egress message rates. The units of these two new alerts are messages per second. Upgrade Notes: - To remove the unused alerts from the Alert Admin page, remove all entries for SolMsgRouterMsgEgressUtilHigh and SolMsgRouterMsgIngressUtilHigh from the ALERTDEFS ALERTLEVELS database table. Configure thresholds and overrides for the new alerts in the Alert Administration. - If you have enabled alert persistence, remove SolMsgRouterMsgEgressUtilHigh and SolMsgRouterMsgIngressUtilHigh from the ALERT_PERSIST_TABLE and ALERT_PERSIST_TABLE_CENTRAL or you will see errors about these alerts in the log file at startup. Also note that if you have stored alert history, the old alert will be in the alert history. It is up to user discretion whether to keep the old alerts in history or not.

24469: Support filtering by Topic Endpoint or by Queues

A new drop down for filtering out Solace Queues and Topic Endpoints has been added to the Endpoints Table display.

24499: Fixed missing Provisioning info for hardware brokers

A bug in displaying the hardware provisioning details (Chassis serial number, BIOS version) for hardware message routers has been fixed. Due to the changes made on the SEMP schemas for software brokers, the hardware information will show blank for software brokers. For additional information, refer to Solace documentation.

24518: Addressed collision of Topic Endpoint and Queue Endpoint with same name

The SolEndpoints and SolEndpointStats have been fixed to account for Queue and Topic Endpoints with the same name. If that case occurs, then the Queue name will remain the same and the suffix "-TE" will be concatenated to the Topic Endpoint name to resolve the similarity. This will only take effect when the Queue and the Topic Endpoint belong to the same broker and VPN. No upgrading instructions are required.

24558: Differentiate unexpired endpoints in the 'Broker Summary' page

The Solace Broker Summary display has been enhanced to show Unexpired / Total Endpoints instead of only the Total Endpoints.

24612: Remove HA pair specification from Solace Connection properties

The Solace connections have been enhanced to remove the HA connection type. HA connections from previous versions will automatically be split into 2 standalone connections. The primary server from the HA connection will use the same name as the HA connection. The backup server from the HA connection will use the same name as the HA connection with a -B appended.

24639: Hardware metrics now correctly reporting for older schemas

A bug in the directory structures of the supported SEMP schemas was causing information (BIOS version, chassis product number, chassis revision, and chassis serial.) about some Solace Hardware Message Routers running older schemas (< 9.3) to be missing. This has been fixed.

24643: Capacity metrics adjusted to not use default values as a benchmark

The following estimates that were used to compute percentages of utilization for capacity displays have been deleted: qt-subscriptions-max max-ingress-per-sec max-egress-per-sec max-ingress-byte-per-sec max-egress-byte-per-sec Similarly, the spool disk size is now being collected from the 'show message-spool detail' SEMP request. LIMITATION On the Broker Capacity Summary display, Egress and Ingress Bytes/s, and Egress and Ingress Msgs/s, now appear in tooltips as the actual rates and not the percentage of utilization calculated from an estimated maximum rate. This change causes the bars on the Broker Capacity Summary display, which expect a value of 0 to 100, to be visually misleading.

24667: Corrected endpoints column in the "Solace Broker Table" page

The current number of endpoints per Solace broker in the Brokers Table display is now correct.

24671: SolSparseMessageSpoolFile alert improved to account for boundary conditions

The SolSparseMessageSpoolFile alert has been adjusted to use a different metric to compute the sparse ratio. The metric current-persist-usage-mb has been replaced by current-disk-usage. Moreover, the metrics involved in this alert have been converted from long to double to account for reduced spool utilization that can deliver a ratio above 3 but are below 1MB and therefore missed when the metrics are converted from blocks to MB.

24735: StatsPump datasource performance optimized

The Solace PubSub+ Monitor's datasource has been enhanced to reduce contention and improve throughput of messages from the statspump, leading to better GC (Garbage Collection) behavior and performance in the "consumer - producer" relationship between statspump and the datasource. It has also been enhanced to tune individual statspump parameters by means of system properties (that can be set as custom properties in the Configuration UI for the data server). STATS_PUMP.MISSED_SEMP_POLL_LIMIT STATS_PUMP.MAX_POLLER_RUN_LIMIT_FACTOR STATS_PUMP.HOSTNAME_POLLER_INTERVAL_SEC STATS_PUMP.REDUNDANCY_POLLER_INTERVAL_SEC STATS_PUMP.VPN_DETAIL_POLLER_INTERVAL_SEC STATS_PUMP.MSG_SPOOL_POLLER_INTERVAL_SEC STATS_PUMP.REACHABLE_POLLER_INTERVAL_SEC STATS_PUMP.BLOCKING_QUEUE_TOTAL_CAPACITY Reducing the Queue Size, controlled by the STATS_PUMP.BLOCKING_QUEUE_TOTAL_CAPACITY system property has been found to be beneficial in reducing memory usage and GC issues. For example, setting the property sl.rtview.jvm to the value -DSTATS_PUMP.BLOCKING_QUEUE_TOTAL_CAPACITY=1000 with the filter collector via the config UI would reduce the internal queue length to 1000 and result in the following entry in the project.properties collector.sl.rtview.jvm=-DSTATS_PUMP.BLOCKING_QUEUE_TOTAL_CAPACITY=1000

24741: SolMsgRouterSwapUsedHigh alert now disabled for hardware appliances

SolMsgRouterSwapUsedHigh alert is now exclusively enabled for SW Brokers and it will not execute for HW Brokers.

24742: Blank brokers now appear in the brokers table

A bug that prevented brokers from appearing in the All Brokers Table display when they were all blank brokers (no clients, bridges, vpns and endpoints) has been fixed.

24747: SolMsgRouterSubscriptionUtilHigh alert refined for queue subscription utilization

The SolMsgRouterSubscriptionUtilHigh alert has been reworked to compute the percentage of queue topic subscription utilization from the max-queue-topic-subscriptions configured value of each broker instead of using a global maximum estimated value. The max-queue-topic-subscriptions is obtained from 'show message-spool detail' SEMPv1 request. The following table column names have been changed: Message Router Capacity Table Old: Queue / Topic Subscriptions Used Queue / Topic Subscriptions Used % Queue / Topic Subscriptions Used HWM % Subscriptions HWM Transacted Sessions % Utilization Transacted Sessions HWM % Utiliztion New: Topic Subscriptions on Queue Used Topic Subscriptionson Queue Used % Topic Subscriptions on Queue Used HWM % Topic Subscriptions on Queue Used HWM Transacted Sessions Used % Transacted Sessions Used HWM % Message Spool Table Old: Queue/Topic Subscriptions Used Max Queue/Topic Subscriptions New: Topic Subscriptions on Queue Used Max Topic Subscriptions on Queue

24757: SolGuaranteedMsgingHbaLinkDown alert fixed

Fixed a bug in the firing of the SolGuaranteedMsgingHbaLinkDown alert. it should now correctly be triggered.

24759: SolGuaranteedMsgingMatePortDown alert now supports both HW and SW brokers

SolGuaranteedMsgingMatePortDown alert has been reworked to account for HW and SW Solace Brokers. The alert will execute when the broker is configured for Guaranteed Messaging and the ADB Link to Mate is down. Initially this alert used "show hardware details" to obtain the information regarding the mate link however this command is not supported on SW Brokers from SEMPv1 8.13 onwards. Limitation: This alert will not clear until a failover occurs.

24762: Updated event definitions for 9.4.0.78

The Solace Event Module has been updated to work with the syslog messages from the 9.4.0.78 Solace release.

24765: SEMP v9.4 schemas

Solace SEMPv1 schemas for Solace Appliance and SW Broker with version 9.4.0 have been included.

24774: Byte ingress/egress alerts switched from %utilization to Byte/s

SolMsgRouterByteEgressUtilHigh and SolMsgRouterByteIngressUtilHigh alerts have been removed from the list of available alerts, as they incorrectly assumed a hardcoded maximum value in order to compute a percentage of utilization. Two new alerts, SolBrokerEgressByteRateHigh and SolBrokerIngressByteRateHigh, have been introduced to alert on the ingress and egress message rates. The units of these two new alerts are messages per second. Upgrade Notes: - To remove the unused alerts from the Alert Admin page, remove all entries for SolMsgRouterByteEgressUtilHigh and SolMsgRouterByteIngressUtilHigh from the ALERTDEFS ALERTLEVELS database table. Configure thresholds and overrides for the new alerts in the Alert Administration. - If you have enabled alert persistence, remove SolMsgRouterByteEgressUtilHigh and SolMsgRouterByteIngressUtilHigh from the ALERT_PERSIST_TABLE and ALERT_PERSIST_TABLE_CENTRAL or you will see errors about these alerts in the log file at startup. Also note that if you have stored alert history, the old alert will be in the alert history. It is up to user discretion whether to keep the old alerts in history or not.

24778: Syslog alerts created/cleared at the same time no longer reappear

In previous releases, Cleared SolEventModule alerts were sometime regenerated. This has been fixed.

24789: Caches now have consistent delete behavior

Information on Appliances that are no longer monitored will now be removed from the displays after a user specified delay. Prior to the advent of dynamic (appliance) connections, Appliance caches did not need delete behavior, as Appliance connections were only added at startup for a given dataserver run. With the advent of dynamic connections, (appliance) connections may be added and removed at run-time. The consistent application of delete behavior ensures that (current) cache rows will be removed after the Delete Time has passed since the last data update. Removing an appliance connection will stop its associated data from updating and thus will be removed from caches after the Delete Time has passed since the last data update. Thus information on Appliances that are no longer monitored will be removed from the displays. The Delete Time can be specified in the Config UI The Delete Time should be longer than the expiry time. LIMITATION: Connections that are removed will not consistently display as Expired in all displays, particularly the Brokers and Capacity screens. Removed connections will be reliably deleted from all screens according to the configured Delete Time.

24797: Solace Event Module - Additional Fields are no longer parsed incorrectly

In previous releases of the Solace Event Module, the Additional Fields values were parsed incorrectly. This has been fixed.

24806: in sol_allvpns_heatmap.html, every choice for "Show" dropdown shows all the VPNs

The "show expired/unexpired" dropdown on the VPNs Heatmap display now correctly selects expired or unexpired VPNs

24812: Corrected column name for "Client Control Msgs Sent"

In the Solace Broker Clients Table there were two columns named "Client Control Msgs Rcvd". The second one has been corrected to "Client Control Msgs Sent".

24814: Increased precision of "Transacted Sessions Util %" in Broker Capacity Table

Columns "Transacted Sessions Util %" and "Transacted Sessions HWM Util %" in the Broker Capacity Table are now displayed with 4 decimal places

24815: Corrected Connection Max value in Brokers Table and Broker Capacity Table

The Max Client Connections values in the Brokers Table and the Connections Max values in Broker Capacity Table now correctly reflect the configured value for an appliance.

24817: Spool-disk-size column in Broker Capacity Table corrected

The column Spool Disk Allocated in the Broker Capacity Table has been renamed to Spool Size Max MB and is now displaying correct data.

24818: Removed Reserved columns from Broker Capacity Table

The following columns have been removed from the Broker Capacity Table: Connections Reserved Subscriptions Reserved Spool Reserved

24819: [Solace Event Module ] Reduced logging level of non-critical message parsing and regex errors

The logging for the Solace Event Module has been enhanced to reduce the logging level for the following errors: - Failed to create/enqueue message... This message is printed to the log when the event module receives a message that is not a syslog message. Since only syslog messages are supported in the event module, these messages are discarded. In previous releases, this was logged at the error level along with a stack trace. It is now logged at the debug level since it is not a critical error. - Failed to match regex, additional fields for message will be empty... This message is printed when the additional fields of the syslog message cannot be parsed due to an unexpected message format or an unexpected character in one of the additional fields. This error does not prevent the message from getting into the SolEventModuleEvents cache. This error may or may not impact alerting on this message. In previous releases, this was logged at the error level. It is now logged at the warn level.

24821: Corrections to metric used for Topic Subscriptions on Queue Used HWM %

The column Topic Subscriptions on Queue Used HWM % in the Broker Capacity table no longer shows incorrect zero values.

24843: Broker Capacity table Spool Size Max MB corrected

The Spool Size Max MB column now returns more accurate information. Also, the following columns in the Broker Capacity table: Cur Spool Usage MB Current Spool Usage HWM have been renamed to: Current Spool Usage MB Current Spool Usage MB HWM

24847: Current Spool Usage HWM % no longer zero in Broker Capacity Table

In the Broker Capacity table the column Current Spool Usage HWM % no longer shows zero values even when the corresponding Current Spool Usage % has data.

24860: Memory usage for state storage used by DELTA functions in solmon is now set to expire

The DELTA functions store internal state to perform their necessary calculations. Previously state was stored for all unique indices encountered. Now stored state is expired (and thus reclaimed) after they have not been updated for a period. The period matches that of the deletion period of the caches they populate. Thus their total memory usage is bounded in a manner similar to the current rows of the caches they populate.

Solution Package for TIBCO ActiveSpaces 2

24378: Fixed problem with Show/Hide toggle in Auth Password field

A bug with the Authentication Password field in the ActiveSpace 2 Configuration Application connection dialog has been fixed. Previously, if you created a new connection with an Authentication Password, toggled the view so the password was in plain text, saved it then edited it, typing a new password in the Authentication Password field showed plain text instead of asterisks. This has been fixed.

Version 5.2.0 Release Notes

Alerts

24264: Null pointer in RTViewCentral alert persistence

In previous releases, the RTViewCentral alert persistence sometimes threw a NullPointerException at startup and some notifications were lost. This has been fixed.

24406: RTViewCentral rtview-manager project now generates alert notifications

In previous releases the RTViewCentral rtview-manager project didn't execute alert notifications. This has been fixed.

20770: Corrected schemas for ALERT_PERSIST_TABLE_(CENTRAL/RTVRULES)

In previous releases, the schemas for the following persistence tables for the RTViewCentral servers were missing some columns: ALERT_PERSIST_TABLE_CENTRAL ALERT_PERSIST_TABLE_RTVRULES The schemas have been fixed and now contain all required columns.

24225: Ease of use enhancements for Alert notifications

A drop-down list of $alertValues was added to the Subject and Body fields of the email alert notification dialog in the Configuration Application.

24385: Changes to alert notification Java Commands were not saved the first time

A change was made to ensure that alert notifications using the default Java type do not contain blank entries in the properties file.

24654: ArrayIndexOutOfBoundsException with 20,000+ alerts

A problem has been fixed which sometimes caused the data server to throw an ArrayIndexOutOfBoundsException, and then grow unresponsive, when removing rows from a cache table.

Configuration

23789: Support Secure Connections to Solace in Configuration Application

The Configuration Application has been enhanced to support connections to secure Solace Brokers. For connections to Cloud Brokers, use an https url in the Connection dialog. For connections to non-Cloud Brokers, turn on the SSL Connection toggle in the Connection dialog. Then go to the Security tab and fill in the SSL Credentials section with the appropriate truststore and truststore password values for your Brokers.

23948: Enhanced EM Integration tab

The EM Integration tab in the Configuration Application has been enhanced to make it easier to use.The following changes were made: - The help text was expanded and improved - The RTView Data Server Host was removed. This field was not directly used by the configuration, but instead was used to generate the RTView Data Server Connection and RTView Data Server Query URL values. - The order of the fields was rearranged to make the critical fields more visible. - The default value of the RTView Data Server Connection was changed to ipaddress:port - The default value of the Announce this RTView Data Server to the Central Server has been changed to true and the field has been moved to the bottom of the page. Upgrade Notes ============ Users upgrading from previous versions who set the RTView Data Server Host will not lose their changes. That field value will be used to generate the RTView Data Server Connection and RTView Data Server Query URL values which will be saved the next time changes are saved from the Configuration Application. The user does not need to do anything to make this work. Users upgrading from previous version who enabled EM Integration, but left Announce this RTView Data Server to the Central Server as false will need to go into the Configuration Application and set it to false again as the default has changed from false to true.

24284: Support for configuring secure jmx ports and SSL secure connections in Configuration Application

The RTView Configuration Application has been enhanced with a new SECURITY tab to support the configuration of secure JMX ports on RTView processes and also to support the configuration of RTView Manager and Kafka connections to SSL secured processes. Previously, this was done by entering properties on the CUSTOM PROPERTIES tab.

24285: Merge memory and jmx jvm arguments instead of appending them

The jvm argument handling has been enhanced to produce a simpler command line output. In previous releases, both the default and the project specific values for the following jvm arguments were included in the command line: -Xmx -Xms -Dcom.sun.management.jmxremote.* This did not cause any functional changes as the last (right-most) value in the command line takes precedence. However, it made the command output confusing to users who were trying to determine which jvm argument values were in use based on the process command. The jvm argument handling has been enhanced so that only one value (previously, the right-most value) is output for the above jvm arguments.

24317: Automatically enable receiver properties in RTViewDataCollector

The argument -propfilter:receiver has been added to the start command for the RTViewCollector dataserver. This has the effect of opening by default the rtvagent port. Customers using the RTViewDataCollectorTIBCO distribution to monitor BusinessWorks using the RTView OSGi Plugin were instructed to add this argument to their start_collector command. This is no longer necessary as it will be done automatically.

24334: Added soleventmodule configuration to Config UI

The Configuration Application for Solace has been enhanced to include the Solace Event Module configuration. In previous releases, this configuration was read from the rtvapm/solmon/soleventmodule/config/soleventmodule.properties files. Those properties are now stored in the project properties. Upgrade Notes Upgrading customers will not need to do anything to transfer their properties from the old soleventmodule.properties file to the project properties. During upgrade, copy your old soleventmodule.properties into the rtvapm/solmon/soleventmodule/config/soleventmodule.properties directory in the new installation, then run as usual. The first time the Configuration Application is used, these properties will be tranfered over to the project properties. After that, the soleventmodule.properties file will no longer be used.

24394: Improved wording of Solace PubSub+ Event Broker toggle in Config UI

Text describing the Solace PubSub+ Event Broker as service toggle in the Configuration Application was enhanced for clarity.

24536: Moved central.properties out of projects\rtview-server

The central.properties file in RTViewCentral/projects/rtview-server has been moved to the rtvapm/appmon/conf directory. This file controls the settings for the central servers and should not be modified. This was done as part of a larger project to make upgrading easier in version 5.0+ by limiting user changes to files under the projects directory. Upgrade Notes Users upgrading from previous versions who have modified the RTViewCentral/projects/rtview-server/central.properties file should not modify the central.properties under rtvapm/appmon/conf. Those properties should be added in the Configuration Application CUSTOM PROPERTIES tab instead.

24537: soleventmodule log4j2.properties moved to projects\rtview-server\soleventmod.log4j2.properties

The rtvapm\soleventmodule\config\log4j2.properties file, which controls the logging settings for the SolEventModule, is now included under the projects\rtview-server directory and has been renamed to soleventmod.log4j2.properties. In previous releases, this file was only available under rtvapm\soleventmodule\config and users were instructed to modify it there. As of this release, changes to the SolEventModule logging must be configured in the projects\rtview-server\soleventmod.log4j2.properties file, not in rtvapm\soleventmodule\config\log4j2.properties This was done as part of a larger project to make upgrading easier in version 5.0+ by limiting user changes to files under the projects directory. Upgrade Notes For upward compatibility, if the projects\rtview-server\soleventmod.log4j2.properties file is not found, the rtvapm\soleventmodule\config\log4j2.properties file will be used instead. However, users upgrading from previous versions who have modified the logging settings should apply their logging changes to the soleventmod.log4j2.properties file in projects\rtview-server in order to make it easier to upgrade to future releases.

24538: sl.log4j.properties copied to projects

The sl.log4j.properties file, which controls the logging settings, is now included under the projects directory. In previous releases, this file was only available under rtvapm\common\conf and users were instructed to modify it there or to copy it to their project directory. As of this release, changes to the logging must be configured in the projects\sl.log4j.properties file, not in rtvapm\common\conf\sl.log4j.properties. This was done as part of a larger project to make upgrading easier in version 5.0+ by limiting user changes to files under the projects directory. Upgrade Notes For upward compatibility, if the projects\sl.log4j.properties file is not found, the rtvapm\common\conf\sl.log4j.properties file will be used instead. However, users upgrading from previous versions who have modified the logging settings should apply their logging changes to the sl.log4j.properties file in projects instead of the copy under rtvapm\common\conf in order to make it easier to upgrade to future releases.

24551: Enhanced update_wars with option to secure rtvquery servlet

If the update_wars scripts are called with the new argument "-secure" then the rtvquery war will be updated with security enabled. (A version of the web.xml file with the security section uncommented will be used).

Customization

23816: Added getExtendedSolEventAlertInfo to example custom command

The custom java command handler for alert notifications has been enhanced to include an example of how to get additional information about SolEventModule alerts from the SolEventModuleAlerts cache. To enable this sample code: 1. Edit projects\custom\src\com\sl\rtvapm\custom\RtvApmCommandHandler.java to uncomment the if statement that calls getEventModuleInfo at the end of the outputAlertNotification method and also uncomment the getEventModuleInfo method. 2. Edit projects\custom\src\make_all.bat or make_all.sh to add RTVAPM_HOME/rtvapm/solmon/lib/rtvapm_solmon.jar to the CP 3. Run make_all.bat or make_all.sh to rebuild the jar 4. In the RTView Configuration, configure your alert notifications to execute a java command - this will generate a message in the data server log file for each alert notification. For SolEventModule alerts, there will be a second message containing the information from the corresponding row in the SolEventModuleAlerts cache.

Deployment

24425: Removed HSQLDB runtime error

A spurious "unable to getSchema" error generated by the HSQLDB database has been suppressed.

Distribution

24576: RTView Manager application refreshed

The RTView Manager application in SolacePubSubMonitor and RTViewCentral has been updated as follows: 1. The classic user interface has been replaced with the html user interface. The url is now host:port/rtview-manager and it requires login. You can login as rtvadmin (rtvadmin) or rtvuser (rtvuser). 2. In SolacePubSubMonitor, connections to components that are no longer included in the deliverable have been removed. 3. In SolacePubSubMonitor, the RTView Manager used to share a database and rtvservers.dat script with the solace monitor. It now has it's own database and rtvservers.dat script. 4. In RTViewCentral, the rtvservers.dat file has changed and custom_setup.bat and custom_setup.sh have been added. Upgrade Notes ============ The rtview-manager directory is not typically customized in RTViewCentral or SolacePubSubMonitor. In the case where this directory was customized, upgrading users should re-apply their changes to the new rtview-manager project and not just override the directory with the old version of the rtview-manager directory.

General

24115: Support form-based auth in HTML UIs

The user login mechanism has been enhanced: 1) The login prompt now uses a page with product branding, rather than the generic popup window. 2) The user can now logout without closing the browser. The appearance of the top banner on the login page varies by product: - For rtview-central and rtview-manager, the banner is dark blue and contains the SL logo and text "RTView© Login" - For rtview-*-rtvadmin (Config UI), the banner is dark blue and contains the SL logo and text "RTView© Project Configuration - Login" - For Tibco-branded UIs (rtview-emsmon, rtview-bwmon, rtview-tdgmon), the banner is medium blue and contains the text "TIBCO(tm) RTView©" - For rtview-solmon, the banner is a black-gray gradient and contains the Solace logo and text "PubSub+ Monitor" In all cases the browser tab title is simply "Login" with no favicon. Logout is performed by clicking on the user name in the top right corner of the UI and then confirming in a popup window. After logging out, a page appears containing the text "Logged out" and a link to return to the login page. Note that closing the browser tab does not perform a logout, so navigating to the UI in another tab afterwards in the same browser will not result in a login prompt. This is by design. If the UI is deployed using tomcat, and if you log in to the rtview UI (e.g. rtview-central) in one tab as rtvuser and then open the configuration tool (e.g. rtview-central-rtvadmin) in a second tab, you'll see the following: You don't have the required role to view this page. Click here to login as a different user. This occurs because the configuration tool requires the rtvadmin role. If you click the link, you'll be logged out in all tabs and can then log back in as a user with the rtvadmin role.

24631: Occasional NullPointerException error during connection of DataServers to Central Server

In previous releases, the CentralServer log sometimes showed this exception at startup: system cust add_spserver_conn - [rtview] java.lang.NullPointerException This has been fixed.

Navigation

24514: Improved visibility of button to hide navigation panel

The background color of the "<<" button in bottom left corner of the UI (which hides the navigation panel) is now a darker gray color than the nav panel's background, to make it more obvious when it overlaps with items in the navigation tree.

RTVMGR

24435: New HTML user interface for RTView Manager

The RTView Manager dashboard has been updated to a new HTML UI. The new UI is available at: http://HOST:3070/rtview-manager (jetty) http://HOST:8068/rtview-manager (apache tomcat)

RTView Core Functionality

: Support for Oracle 12c

Oracle 12c is now supported by the Solution Package for Oracle Database, and it is supported for storing RTView tables (historian and alerts).


24450: Deprecate support for Sybase database

RTView no longer supports Sybase database.

Data Historian

18764: Historian now creates table dynamically when other catalog/schema has table of same name

Previously, under certain circumstances, the historian would not correctly dynamically create tables for historical data. With a JDBC driver jar that supports Java 1.7+ and implements Connection.getSchema() for the database in use, this is no longer the case. Note: if you cannot obtain a JDBC driver jar that supports Java 1.7+ and implements Connection.getSchema() for the database in use, using the provided SQL scripts to create tables for a SP (Solution Pack), removes the need for the historian to dynamically create tables.

General

24496: Fixed deadlock in Display Server

In previous releases, the RTViewCentral display server occasionally deadlocked on startup when connected to multiple RTViewDataServers. This has been fixed.

RTView Manager

24484: Upgraded Tomcat caches to support Tomcat 7 and 8, drop support for Tomcat 6

The Tomcat caches have been enhanced to support monitoring Tomcat 8 and to drop support for Tomcat 6. The following columns in the TomcatWebModuleStats and TomcatWebModuleTotals caches are not supported for Tomcat 8. They will show 0 for Tomcat 8 connections, but will show correct data for Tomcat 7: desiredEntryAccessRatio maxAllocateIterations spareNotFoundEntries The state column in the TomcatWebModuleStats and TomcatWebModuleTotals caches is not supported for Tomcat 7 or 8, but was left in for upward compatibility. It will always show a value of 1. The xmlNamespaceAware column was removed from the TomcatHostInfo cache and the bufferSize and maxSpareThreads columns were removed from the TomcatConnectorInfo cache. These columns are not supported for Tomcat 7 or 8 and removing them will not impact upward compatibility.

24554: Support connections to password-secured central or data servers

The RTView Manager in RTViewCentral has been enhanced to support connections to password secured RTViewDataServers.

Scripts

22858: Classpath fields now check if path ends with .jar before adding /*

The Configuration Application has been enhance to handle .jar file names in the Classpath Directory fields for all solution packages. In previous releases, these were incorrectly used as directory names.

24384: Fix to make_classes script in RTViewDataServer*

In previous releases, the custom\src\make_all scripts failed when executed on the RTViewDataServer deliverables. This has been fixed.

Solution Package

24077: VARCHAR limits in "name" columns increased in database schemas

The VARCHAR limits of "name" columns in the database schemas have been increased from 100 to 255 to allow more flexibility with long names. Users do not need to make any changes to their existing database records.

24318: SolGuaranteedMsgingNoMsgSpoolAdActive improvements

The SolGuaranteedMsgingNoMsgSpoolAdActive alert has been fixed to be associated per Message Router. This alert will now be triggered on the two brokers that are redundancy configured as an HA pair when the operational status of their message spool is not AD-Active on any of the two brokers. This alert now correctly has a CI Type, and drilling down on this alert will load the Solace Broker Spool Table.

Solution Package for Apache Kafka

24206: Pivot KafkaServer caches with multiple rows per server into new caches

The KafkaServerMeter and KafkaServerTopic caches contain row-oriented metric data, with a separate row for each metric. Two new caches have been created to store these metrics column-oriented, with one row per server or topic with columns for each metric. They are KafkaServerMetrics and KafkaServerTopicMetrics. Furthermore, the history tables have been removed from the two original caches, and history tables from the two new caches are now saved to the database and used in the displays. The history tables that have been removed are KAFKA_SERVER_METER and KAFKA_SERVER_TOPIC. The corresponding new history tables are KAFKA_SERVER_METRICS and KAFKA_SERVER_TOPIC_METRICS. The appear in the Configuration UI Data Storage tab with the names "Server Metrics" and "Server Topic Metrics". --------------------------------- Classic displays - internal only? --------------------------------- In the Single Broker Summary, the Topic Trends tab has been removed. In the Single Topic Summary, the Rate dropdown has been removed and the trend metrics e.g. MsgsInPerSec are now RateMsgsIn etc. In the All Kafka Broker Metrics Table, the trend has been removed entirely.

24324: Update jackson libraries from 2.8.4 to 2.9.9

The Jackson libraries used with Kafka monitoring have been updated from version 2.8.4 to version 2.9.9.

24370: Fixed duplicate column in Kafka Broker Table

The Kafka all servers table display had a duplicate column Purgatory Size Fetch. This has been corrected.

24543: Enhanced Kafka Producer and Consumer history

The following columns have been added to the history tables: KafkaConsumer: fetch-latency-avg, records-per-request-avg KafkaProducer: records-per-request-avg

Solution Package for IBM MQ

23947: New MQ alerts for managed queues

Two New Alerts Have been Added * MqManagedQueueNoActiveReaders - when the number of active readers (inputs) is 0 for any managed queues (SYSTEM.MANAGED.DURABLE.>) * MqManagedQueueTooManyReaders - when the number of active readers (inputs) for any managed queue is equal or greater than the threshold (default set to 2).

24109: The product formerly known as "IBM WebSphere MQ" is now "IBM MQ"

The product formerly known as "IBM WebSphere MQ" is now "IBM MQ". References (in displays, etc) to "IBM WebSphere MQ" have been changed to "IBM MQ".

24226: IBM MQ connection configuration has been enhanced

The Solution Package for IBM MQ connection configuration in the Configuration Application has been enhanced to allow the setting of per-connection attributes. The IBM MQ Add Connection dialog, in addition to specifying the connection name, host and port, now allows the user to specify the per connection username and password (if required by the connection) A connection can be specified as an SSL connection by setting the SSL connection slider "Do you want to connect using SSL" to yes The user is then able to enter the SSL connection attributes required by the connection, as configured on the MQ Server (ask your MQ system administrator for details) You can enter the path of the Trusted Certificate Store (TrustStore) name, and its associated password if the certificate is password protected You can also enter the path of the Personal Certificate Store (KeyStore) name, and its associated password if the certificate is password protected. You can also enter the name of the SSL Cipher Suite used for the SSL Connection. Consult your MQ System Administrator for the required value. Note: * SSL Cipher Suite Value can vary depending upon JDK version, and whether the IBM JDK or another JDK is used for the client. An example of a valid SSL Cipher Suite when using the Oracle JDK on the client is TLS_RSA_WITH_AES_128_CBC_SHA256 * Supported/Enabled Cipher Suites vary by Version of Java, Supplier of JDK/JRE (IBM vs Oracle/Sun) and time. - Consult your System Administrator * You may need to download and install Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files for your version of JDK/ JRE to enable some Cipher Suites e.g. http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html * When Using the Sun / Oracle JDK/JRE instead of the IBM JDK / JRE you may also need to use the following JVM flags -Dcom.ibm.mq.cfg.preferTLS=false -Dcom.ibm.mq.cfg.useIBMCipherMappings=false These can be added As (sl.rtview.jmn) custom properties in the config UI See also https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031290_.htm

Solution Package for IBM Websphere MQ

23670: Added support for Topic and Subscription metrics

MQMON now queries for Topic and Subscription Metrics and attributes, including new Alerts against these metrics. The Metrics and attributes are displayed in tabular form and in individual summary displays

24456: Added default poll rate for MQ and exposed it in the Config UI

The IBM MQ Solution Package Configuration Data Collection Tab has been enhanced. It now allows the user to set a user defined poll rate (in seconds) at which to collect metric data. The default poll rate is 20 Seconds. The Queue Filter now has a default value of *, to Query all the available queues by default.

Solution Package for Node.js

23384: Enhanced rtview-nodemon readme.txt to include better examples for configuration

The rtview-nodemon example readme.txt file (rtvapm\nodemon\agents\rtview-nodemon\readme.txt) has been updated to include better examples for configuration.

24278: Fixed typo in rtview-nodemon agent readme.txt (missing closing quotation in example)

A missing closing quote was added back to the port parameter in the Node agent's readme.txt file's usage examples.

Solution Package for Solace PubSub+

24322: Platform now collected correctly for all SEMP versions

Platform is now being correctly gathered for all supported SolOS versions.

24391: New alerts for redundancy misconfiguration and activity status change (deprecates SolHAPairFailoverDetected)

SolBrokerRedundancyDown and SolBrokerRedundancyActivityStatusChanged alerts have been implemented to detect redundancy misconfiguration and changes in the activity state of brokers configured for redundancy. These alerts will be only executed for brokers that are detected as being configured for redundancy due to either the existence of its mate router name or because they have been explicitly defined as configured for redundancy. Explicitly defining brokers as being redundancy configured is only required when the monitor has not succeeded on detecting the brokers as configured for redundancy. To verify whether the monitor has detected all brokers configured for redundancy correctly, go to the Admin > Cache Table display and select the _SolBrokerRedundancy cache in the upper table. Verify in the lower table of this display that all brokers redundancy configured have the IsHABroker flag checked. If that is not the case, you need to specify the mate router name in the redundancy configuration of each broker. The SolBrokerRedundancyDown alert verifies that redundancy is configured properly by checking whether Redundancy Mode, Redundancy Status and Configuration Status are valid. That is, the Redundancy Modes is either Active/Active or Active/Standby, the Redundancy Status is Up and the redundancy Configuration Status is Enabled. If any of these conditions is not met, then an alarm alert will be raised with the following alert text: "<hostname> is not properly configured for redundancy or redundancy is down. Redundancy Status: <a> Configuration Status: <b>", where <hostname> is the hostname of the offending broker and <a> and <b> are the current Redundancy Status and Configuration Status of the broker respectively. The SolBrokerRedundancyActivityStatusChanged alert checks whether the previous state of the Active-Standby Role, the Activity Status of the Primary Virtual Router and the Activity Status of the Backup Virtual Router is different from the current state. If they are different, that implies a change in the state of the redundancy status occurred and a warning alert will be triggered. As soon as the previous and the current redundancy state is stabilized, the warning alert will be automatically cleared, indicating in the alert text the current and previous states being detected. The warning alert contains the following text: "<hostname> has changed its redundancy activity state. There might be untracked intermediate states from the ones that have been detected. Current state: <A> Previous state: <B>", where <A> and <B> are the concatenation of active-standby-role, primary-status-activity, and backup-status-activity separated by the character "-" for current and previous states. Best Practices & Troubleshooting * It's possible to have multiple SolBrokerRedundancyActivityStatusChanged warning alerts when failing over if intermediate states have been collected. For instance, if the changes from Local Active to Local Inactive to Shutdown are detected, then two SolBrokerRedundancyActivityStatusChanged warning alerts will be executed in this broker and will have two warnings from one broker and one from the other broker if the intermediate state on the second broker was not gathered due to polling interval being longer than the time the broker changes its redundancy state. If you only want one warning alert per broker per failover operation, the recommended action is to increase the duration of the alert. This value will vary depending on data collection latency and is system dependent. On the other hand, if you need to keep track of all intermediate states of the failover operation, then you should decrease the polling interval for the show redundancy detail poller. This is not recommended as might overflow the data collector with requests that cannot be successfully completed or preventing sending other monitoring data regarding other aspects of the broker due to the existence of requests too-often repeated. * Due to SolBrokerRedundancyActivityStatusChanged warning alert being a transient alert which will be automatically cleared when the redundancy status is stabilized, enabling both alerts is recommended as SolBrokerRedundancyDown can stay uncleared if manual intervention for fixing redundancy misconfiguration or non-functioning is required.

24404: SolMsgRouterTranSessionCntUtilHigh no longer using a deprecated metric

SolMsgRouterTranSessionCntUtilHigh previously used a deprecated metric from Solace. It now uses the result of: (Transaction-sessions-used/Max-transaction-sessions) * 100

24443: Replaced Pending Messages by Spooled Messages across displays

"Pending Messages" labels across all Solace PubSub+ monitor displays have been renamed to "Spooled Messages."

24455: New SEMP schemas (9.3+)

The SEMP schemes for 9.3 and 9.3.1 versions have been included.

24461: Solace Config UI no longer allows creation of incorrectly formatted connections

Enhancements have been made to the Solace connections dialog in the Configuration Application to ensure that all required fields have data entered before the connection can be saved.

24464: Client integer metrics changed to long

Integer client metrics have been updated to long type. To update these metrics in their corresponding tables in history, execute the following "alter table" SQL sentences. Work with your database administrator on the optimal way to make these changes. DB2/HSQLDB ALTER TABLE "SOL_MESSAGE_SPOOL" ALTER COLUMN "ingress-flow-count" SET DATA TYPE BIGINT; ALTER TABLE "SOL_MESSAGE_SPOOL" ALTER COLUMN "queue-topic-subscriptions-used" SET DATA TYPE BIGINT; ALTER TABLE "SOL_MESSAGE_SPOOL" ALTER COLUMN "spool-files-total-used" SET DATA TYPE BIGINT; ALTER TABLE "SOL_MESSAGE_SPOOL" ALTER COLUMN "transacted-sessions-used" SET DATA TYPE BIGINT; ALTER TABLE "SOL_APPLIANCE" ALTER COLUMN "num-messages-spooled" SET DATA TYPE BIGINT; ALTER TABLE "SOL_APPLIANCE" ALTER COLUMN"total-clients-connected" SET DATA TYPE BIGINT; ALTER TABLE "SOL_ENDPOINT" ALTER COLUMN "num-messages-spooled" SET DATA TYPE BIGINT; ALTER TABLE "SOL_VPN" ALTER COLUMN "connections" SET DATA TYPE BIGINT; ALTER TABLE "SOL_VPN" ALTER COLUMN "total-unique-subscriptions" SET DATA TYPE BIGINT; ALTER TABLE "SOL_VPN" ALTER COLUMN"num-messages-spooled" SET DATA TYPE BIGINT; MySQL ALTER TABLE "SOL_MESSAGE_SPOOL" MODIFY "ingress-flow-count" BIGINT; ALTER TABLE "SOL_MESSAGE_SPOOL" MODIFY "queue-topic-subscriptions-used" BIGINT; ALTER TABLE "SOL_MESSAGE_SPOOL" MODIFY "spool-files-total-used" BIGINT; ALTER TABLE "SOL_MESSAGE_SPOOL" MODIFY "transacted-sessions-used" BIGINT; ALTER TABLE "SOL_APPLIANCE" MODIFY "num-messages-spooled" BIGINT; ALTER TABLE "SOL_APPLIANCE" MODIFY "total-clients-connected" BIGINT; ALTER TABLE "SOL_ENDPOINT" MODIFY "num-messages-spooled" BIGINT; ALTER TABLE "SOL_VPN" MODIFY "connections" BIGINT; ALTER TABLE "SOL_VPN" MODIFY "total-unique-subscriptions" BIGINT; ALTER TABLE "SOL_VPN" MODIFY "num-messages-spooled" BIGINT; SQL Server ALTER TABLE [SOL_MESSAGE_SPOOL] ALTER COLUMN [ingress-flow-count] BIGINT; ALTER TABLE [SOL_MESSAGE_SPOOL] ALTER COLUMN [queue-topic-subscriptions-used] BIGINT; ALTER TABLE [SOL_MESSAGE_SPOOL] ALTER COLUMN [spool-files-total-used] BIGINT; ALTER TABLE [SOL_MESSAGE_SPOOL] ALTER COLUMN [transacted-sessions-used] BIGINT; ALTER TABLE [SOL_APPLIANCE] ALTER COLUMN [num-messages-spooled] BIGINT; ALTER TABLE [SOL_APPLIANCE] ALTER COLUMN [total-clients-connected] BIGINT; ALTER TABLE [SOL_ENDPOINT] ALTER COLUMN [num-messages-spooled] BIGINT; ALTER TABLE [SOL_VPN] ALTER COLUMN [connections] BIGINT; ALTER TABLE [SOL_VPN] ALTER COLUMN [total-unique-subscriptions] BIGINT; ALTER TABLE [SOL_VPN] ALTER COLUMN [num-messages-spooled] BIGINT;

24474: Include hostname in 'Alert Text' field of SolMsgRouterNotConnected

The SolMsgRouterNotConnected alert now includes the hostname in the alert text.

24480: Fixed SolMsgRouterNotConnected alert misconfiguration

SolMsgRouterNotConnected alerts now provide the CI name.

24508: 'Client Summary' page now showing correct values

Fixed a bug in the collection of client metrics. With the fix, the Single Client Summary will display correctly activity in trends as well as provide the metrics from the last update period in the case the Client went down. To identify whether the Client is still generating activity and the data collection is proceeding normally, verify the Expired field of the Client is false. Otherwise, when Expired is true, the data provided in the display will reflect the metrics delivered from the last update time, when the information was successfully collected. Notice that trends might not show any activity with current preset time of 15 min when the Client stopped earlier to this time frame. To detect whether the transient activity of the Client was registered properly, extend the time range of the trends in the Client Summary display to a broader period.

24520: SolSparseMsgSpool alert now accounts for disk space utilization

Fixed a bug in the execution of the SolSparseMsgSpool alert. With the fix, this alert will trigger a warning alert (Severity 1) when the active disk partition usage is above 30% and the ratio between disk utilization and current persistent utilization is larger than 3. Further reading about this condition can be reached from Solace’s site, Section on diagnosing the sparse message spool file condition at: https://docs.solace.com/Configuring-and-Managing/Mon-Mgmt-Disk-Con.htm

24522: Calculated rates in Broker displays no longer zero when collected with Stats Pump

Fixed a bug in the calculation of client rates for direct, persistent, and non-persistent messages, and bytes received and sent. The fixed metrics are: cl-direct-bytes-rcvd cl-direct-bytes-sent cl-direct-msgs-rcvd cl-direct-msgs-rcvd-per-sec cl-direct-msgs-sent cl-direct-msgs-sent-per-sec cl-non-prst-bytes-rcvd cl-non-prst-bytes-sent cl-non-prst-msgs-rcvd cl-non-prst-msgs-rcvd-per-sec cl-non-prst-msgs-sent cl-non-prst-msgs-sent-per-sec cl-prst-bytes-rcvd cl-prst-bytes-sent cl-prst-msgs-rcvd cl-prst-msgs-rcvd-per-sec cl-prst-msgs-sent cl-prst-msgs-sent-per-sec egress-compression-ratio ingress-compression-ratio tcp-fast-retransmit-sent total-cl-bytes-rcvd total-cl-bytes-sent total-cl-msgs-rcvd total-cl-msgs-rcvd-per-sec total-cl-msgs-sent total-cl-msgs-sent-per-sec total-clients total-clients-connected total-egress-discards total-egress-discards-per-sec total-ingress-discards total-ingress-discards-per-sec cl-direct-bytes-rcvd-per-sec cl-direct-bytes-sent-per-sec cl-non-prst-bytes-rcvd-per-sec cl-non-prst-bytes-sent-per-sec cl-prst-bytes-rcvd-per-sec cl-prst-bytes-sent-per-sec total-cl-bytes-rcvd-per-sec total-cl-bytes-sent-per-sec avg-egress-byte-per-min avg-egress-comp-per-min avg-egress-per-min avg-egress-ssl-per-min avg-egress-uncomp-per-min avg-ingress-byte-per-min avg-ingress-comp-per-min avg-ingress-per-min avg-ingress-ssl-per-min avg-ingress-uncomp-per-min current-egress-byte-per-sec current-egress-comp-per-sec current-egress-per-sec current-egress-ssl-per-sec current-egress-uncomp-per-sec current-ingress-byte-per-sec current-ingress-comp-per-sec current-ingress-per-sec current-ingress-ssl-per-sec current-ingress-uncomp-per-sec egress-comp-bytes egress-ssl-bytes egress-uncomp-bytes ingress-comp-bytes ingress-ssl-bytes ingress-uncomp-bytes

24525: Brokers now appearing in Brokers Table when both NOT_RUNNING and FAILURE statuses are present

Fixed a bug that preventing some Solace Brokers from appearing in in the Solace Brokers Table. The issue was related to the variations in the failure code returned by different SEMP versions. For debugging purposes, a new set of auxiliary caches have been introduced. Each of these auxiliary caches provides a self-explanatory flag indicating one Broker condition.. The list of auxiliary caches and the flags supported is the following: 1. _SolBrokerSystemHardwareRaw (IsSoftwareBroker flag) 2. _SolBrokersConnected (Connected flag) 3. _SolBrokersEndpoints (HasEndpoints flag) 4. _SolBrokerBridges (HasBridges flag)) 5. _SolBrokerRedundancy (IsHABroker flag) 6. _SolBrokerClientStatsRaw (HasClients flag) 7. _SolBrokerVpns (HasVPNs flag)

24585: Use defaults if group_sl.xml and poller_sl.xml not in project directory

In previous releases, the Data Server monitoring Solace PubSUb+ crashed if the pollers_sl.xml and groups_sl.xml files were missing from the project directory. This has been fixed. If these files are missing, the defaults are used instead.

24606: Reduced polling rate of StatsPump to 30 seconds

We changed the mandatory poller update rates in the StatsPump from 5 to 30 seconds. As part of this change, a JVM heap dump will now be generated in the case of an OutOfMemory error.

24634: Blank brokers aren't listed in All Brokers Table

Fix a bug preventing Solace Brokers that did not have endpoints from being listed in the All Brokers Table display.

24716: Corrected invalid sample soleventmodule filters

The SolaceEventModule contains several sample Alert Filters. The System + VPN - VPN Resource Util filter previously used invalid wildcard XPath syntax: severityCode>=5, scope='CLIENT', eventName='VPN_RDP_RC_CONN_DOWN', eventName='VPN_RDP_RC_DOWN', eventName='VPN_RDP_RDP_DOWN', scope='VPN' and (eventName='*_HIGH' or eventName='*EXCEED' or eventName='EXCEEDED') This has been updated to use correct XPath 1.0 syntax: severityCode>=5, scope='CLIENT',eventName='VPN_RDP_RC_CONN_DOWN', eventName='VPN_RDP_RC_DOWN', eventName='VPN_RDP_RDP_DOWN', scope='VPN' and (substring(eventName,string-length(eventName)-4)='_HIGH' or substring(eventName,string-length(eventName)-6)='_EXCEED' or substring(eventName,string-length(eventName)-8)='_EXCEEDED')

Solution Package for TIBCO ActiveSpaces

24369: Fixed errors in Configuration Application for TIBCO ActiveSpaces (4.1+)

In the Configuration Application, the Solution Package for TIBCO Active Spaces (4.1+) did not correctly set the default values, nor did changes to its fields enable the Save button. These issues have been fixed.

24423: Fixed error when connecting to FTL server with no AS4 processes

If a dataserver configured for tdgmon connected to an FTL realm where only the FTL server is running with no AS4 processes (node, proxy, keeper) then the following error showed in the dataserver log: ERROR: function <refNodeCopyset>, caught exception in updateResult: java.lang.NullPointerException, type:GetNodeCopyset, file:tdg_node_cache_source.rtv This has been corrected.

24433: Fixed startup errors

At startup the ActiveSpaces monitor dataserver would log the following (benign) errors. This has been corrected. <tdgNode09>, Invalid column name <node_ready;node_started>, type:TCVT, file:tdg_node_cache_source.rtv <tdgNode09>, No valid input columns specified, type:TCVT, file:tdg_node_cache_source.rtv <tdgNode10>, Invalid column name <node_completed_op_count;node_deleted_keys_count;node_eventsforwarded;node_failed_op_count;node_get_op_count;node_global_ops_pending;node_global_ops_rejected;node_iterclose_op_count;node_itercreate_op_count;node_iterget_op_count;node_livedata_size;node_migration_bins_pending;node_migration_bins_received;node_migration_bins_sent;node_numlisteners;node_numqueries_value;node_numrowsexpired;node_numrowsscanned;node_numscanscompleted;node_numttltables;node_operations_allowed;node_operations_suspended;node_put_op_count;node_queryclose_op_count;node_querycreate_op_count;node_queryget_op_count;node_reindex_completed;node_reindex_rows_count;node_reindex_started;node_remove_op_count;node_rowsreceived;node_stmtclose_op_count;node_stmtcreate_op_count;node_txnbegin_op_count;node_txncommit_op_count;node_txnrollback_op_count;node_kvstore_write_count;node_kvstore_write_time_nanos;node_kvstore_write_value_count>, type:TCVT, file:tdg_node_cache_source.rtv <tdgNode10>, No valid input columns specified, type:TCVT, file:tdg_node_cache_source.rtv <tdgProxy07>, Invalid column name <proxy_ready;proxy_started>, type:TCVT, file:tdg_proxy_cache_source.rtv <tdgProxy07>, No valid input columns specified, type:TCVT, file:tdg_proxy_cache_source.rtv <tdgProxy08>, Invalid column name <proxy_num_statements;proxy_num_queries;proxy_num_listeners;proxy_num_iterators;proxy_stmtclose_op_count;proxy_stmtcreate_op_count;proxy_queryclose_op_count;proxy_queryget_op_count;proxy_querycreate_op_count;proxy_iterclose_op_count;proxy_iterget_op_count;proxy_itercreate_op_count;proxy_txnrollback_op_count;proxy_txncommit_op_count;proxy_txnbegin_op_count;proxy_remove_op_count;proxy_get_op_count;proxy_put_op_count;proxy_client_disconnected;proxy_client_connected>, type:TCVT, file:tdg_proxy_cache_source.rtv <tdgProxy08>, No valid input columns specified, type:TCVT, file:tdg_proxy_cache_source.rtv <tdgKeeper07>, Invalid column name <ready;started>, type:TCVT, file:tdg_keeper_cache_source.rtv <tdgKeeper07>, No valid input columns specified, type:TCVT, file:tdg_keeper_cache_source.rtv

24449: Key Metric TdgRealm/Delta CPU now points to correct metric column

The ActiveSpaces key metrics for Realm CPU and Memory were not associated with the correct metrics and thus would not display correctly in the key metrics displays. This has been corrected. Also the Realm CPU key metric has been renamed from "Delta CPUJ" to "CPU"

24577: Fixed cache mismatch in collector

In a sender-receiver deployment, the summary page trends in the receiver did not match those in the sender. This has been corrected.

24579: ActiveSpaces package decimal places made consistent

All metric cards now use a consistent decimal format (two decimal places).

Solution Package for TIBCO Adapter

24638: Inactive TIBCO Adapter now shows active after the Adapter instance is restarted

When an Adapter instance is stopped, RTView shows the state as stopped, then after the configured interval it is marked Expired and eventually removed from the displays. However if the Adapter instance was restarted, RTView did not detect the new instance, so it would not be marked un-expired or restored to the displays. This has been corrected.

Solution Package for TIBCO BusinessWorks

24117: Clarify application deployment status

(1) If an application's appnodes are a combination of appspace and container deployments, It's Deployment column showed one or the other. Now it will say "Hybrid" (2) A column "Deployment" has been added to the appnode table on the (classic) Application Summary page. (3) If an application's appnodes were monitored with Hawk, the Deployment column would be blank, and neither the application nor its appnodes would appear in their corresponding tables or heatmaps, although they would appear in the corresponding summary pages. This has been fixed.

24354: BW6 Container appears in AppSpace dropdown in Nodes table

BW AppNodes running in containers and not assigned to an appspace appear in the BW Containers displays and not in the App or AppNode displays. However the BW AppNode table and heatmap displays allowed access to the "standalone" container appnodes; this has been corrected.

24368: BW6 Activity displays show no data

BW Activities displays would show no data even if Activity data was correctly enabled. This has been corrected.

24388: Cache rows now have unique timestamps

When the BW6 caches were updated all rows would get the same timestamp. Now each application and appnode, and the appnode's associated processes, will be updated independently.

24444: Added BW6_ACTIVITIES and BW6_ACTIVITY_TOTALS to database schemas

Two database tables were missing from the schemas under rtvapm\bwmon\dbconfig. BW6_ACTIVITIES BW6_ACTIVITY_TOTALS These have been added. Existing users should not need to delete/recreate any existing tables.

24571: BW6 ProcessTotals history caches no longer have duplicate rows

The BW6ProcessTotalsByApp, BW6ProcessTotalsByAppNode, and BW6ProcessTotalsByAppNodeAndApp history tables had multiple rows with the same timestamp and value. This has been fixed.

Solution Package for TIBCO FTL

23289: TFTL_ADVISORY history storage removed

The TFTL_ADVISORY history table storage has been removed from the TftlAdvisory data cache.

24215: Support connections to secured FTL servers

The RTView monitors for TIBCO FTL and TIBCO ActiveSpaces now support connections to secured FTL servers. For instructions on configuring your Data Server see the documentation on "Secure Connections to Monitored Components"

24357: Connection to FTL server that is not active can fill up logs with errors

If the dataserver failed to connect to a specified FTL server the log would show repeated errors of the form GetNodeCopyset: java.lang.IllegalStateException: This is not a JSON Object. This has been corrected.

24407: TftlMetrics cache no longer saves history or writes it to the database

The TFTL_METRIC history table storage has been removed from the database configuration. The FTL Client - Metric Summary display in the thin-client UI now displays only current data.

Solution Package for VMWare

24453: Added VMW_DATASTORE to database schemas

A database table was missing from the schemas under rtvapm\vmwmon\dbconfig. VMW_DATASTORE This table has been added. Existing users should not need to delete/recreate any existing tables.

Version 5.1.3 Release Notes

Configuration

24236: Allow users to see cleared alerts from any time in the past

A simple Alert History Table display has been added to the Components tab at Other/Common/Alerts/Alert History Table. This new table enables the user to see previously cleared alerts in a table.

RTView Core Functionality

Data Server

24393: Fix deadlock condition in rtvquery

A problem in the rtvquery servlet has been fixed which could cause the servlet to hang with a deadlock. However this was only observed during shutdown of the app server (tomcat).

Distribution

24219: Upgrade from jetty 9.4.14 to 9.4.19

The version of jetty has been updated from 9.4.14 to 9.4.19. Users should not see any difference in behavior.

Solution Package for Solace PubSub+

23444: Improve responsiveness of Solace PubSub+ monitoring

The responsiveness of Solace PubSub+ monitoring has been improved in the case where Solace connections to PubSub+ Cloud brokers are processing large data sets.

23701: Solace Bridge diagram - connect to SolAdmin now working for SEMP v9

Right clicking router icons in the Bridges Diagram allows the user to launch the associated PubSub+ Manager. This functionality was broken for routers running newer SEMP versions, and has now been fixed.

24138: Improved calculation of SolMsgRouterSpoolUtilization alert

The calculation of the SolMsgRouterSpoolUtilization has been fixed to be computed as the percentage of spool memory consumed by all endpoints in the broker against the maximum spool memory assigned to the broker itself overall. If the maximum spool memory assigned to the broker varies from the sum of the spool memory assigned for each VPN, then the percentage of this alert might not be triggered correctly. To fix that, the user should manually ensure that the sum of all message VPN maximum spool usage is less or equal to the overall broker maximum spool usage. The reasons to allow that the maximum spool memory assigned to the broker can differ from the total assigned to the VPNs are the following: 1. It would be a painful for users to adjust all (or at least more than one) message VPN’s max spool usage setting when they really only wanted to increase it for one message VPN. 2. Creating a new message VPN would mean the user having to adjust this configured setting on other Message VPN. 3. Avoid artificially limiting the spool size of message VPNs if it is unlikely that several VPNs would ever be near the max spool usage assigned to the broker. This allows users the option to configure the broker to make the most of the underlying storage resources if the associated application behavior is unlikely to cause the overall message-spool allocation to be exceeded.

24159: SolClientSlowSubscriber misconfiguration fixed

A bug that prevented the SolClientSlowSubscriber alert from firing has been fixed.

24162: Alert and metrics to compute SolSparseMessageSpoolFile fixed

The collection of the metrics being used to compute the SolSparseMessageSpoolFile alert has been fixed.

24169: Support setting the maximum memory for the SolEventModule

The RTViewSolaceMonitor and RTViewDataServerSolace have been enhanced to support setting the maximum memory for the SolEventModule. The default is 512M. To set the maximum memory for the SolEventModule, add it to the end of the -soleventmodule command line as follows: -soleventmodule:1024M Replacing 1024M with the maximum memory you would like to use. This must not be set to a value smaller than 512M or to a value higher than the resources allocated for your jvm. This value is passed into the -Xmx Java command line and should use syntax appropriate to that argument which is a number followed by a unit. Valid units are k (kilobyte), m(megabyte), g(gigabyte). If no unit is specified, the number is assumed to be bytes.

24195: Improved handling of loss of connectivity to brokers

Previously connection threads to the HTTP data source could silently stop, causing healthy broker's to appear as Expired. This has been fixed. In conjunction to this fix, a new alert, SolMsgBrokerExpired, has been created to indicate when the monitoring data collection has stopped abruptly. Use this alert in conjunction with the SolMsgBrokerNotConnected alert, or in replacement of it if you don't need to be notified of lack of connectivity when the Solace Monitor starts up.

24224: Use physical-memory-usage-percent provided metric instead of calculated memory-used-percent

The physical and subscription memory used percentages have been enhanced to account for the values provided by Solace.

24304: Ease of use improvements for editing Solace PubSub+ connections.

The Configuration Application now ensures that new standalone Solace connections use the required host:port format.

24314: Replaced SolMsgRouterFailoverDetected with SolHAPairFailoverDetected

The SolHAPairFailoverDetected alert has replaced the SolMsgRouterFailoverDetected. This alert has as indexes the connection strings of the two HA brokers on an Active/Standby or Active/Active redundancy configurations. The condition for this alert to be executed is the following: (primary-status-activity == “Local Active� AND backup-status-activity2 == “Mate Active�) OR (backup-status-activity == “Mate Active� AND primary-status-activity2 == “Local Active�) Limitation: This alert requires that the hostnames and node names of the HA Group must be identical.

24315: Support use of user-supplied SEMP schemas

To simplify the update of the SEMP schemas when they are missing, schemas have been moved outside the data source jar. If the SEMP schemas that are required for connecting to a Solace Broker are missing, the Broker will not appear in the Broker Table of the PubSub+ Monitor and the log from the dataserver under projects\rtview-server\logs directory will show the following exception: “… java.lang.IllegalStateException: Have not loaded schemas for 'soltr/9_0VMR'. Ensure schema version looks like 'soltr/x_y'. Call loadSchemas() first, or import new schema files…� To solve the problem, you should download the schemas from the Solace Customer Portal (https://products.solace.com/) where you as a customer have access to download Solace products as well as the SEMP schemas from any supported release (either Software or Appliance Brokers). Be aware that the SEMP schemas from Software and Appliance Brokers even from the same version might differ. Therefore, verify that the downloaded files for either Software or Appliance Brokers are uniquely identified. To include the newly downloaded SEMP schemas follow these steps: 1) cd to the ‘resources’ directory (yourProjectDir/rtvapm/solmon/lib/ext/resources) and create a separate directory for the SEMP schema version to include. 2) Copy the two schema files into the newly created directory 3) Stop/start PubSub+ Monitor, Solace Data Server or Collector and verify whether the missing Broker appears connected and data is being collected properly. 4) Finally, verify the dataserver.log file no longer shows the missing schema error. Contact SL Technical Support if you have issues downloading or adding these files to the product.

24319: XPath functions fixed in soleventmodule.properties

In previous releases, xpath functions in the following soleventmodule.properties properties did not work and caused a parsing exception: ALERT_WHITELST ALERT_BLACKLIST EVENTWRITER_WHITELST EVENTWRITER_BLACKLIST This has been fixed. XPath functions that return true/false can now be used. Additionally, the typo in the ALERT_WHITELST and EVENTWRITER_WHITELST property names was confusing and has been fixed. Those property names have been changed to ALERT_WHITELIST and EVENTWRITER_WHITELIST. For upward compatibility, if the new property names are not found in the soleventmodule.properties file, the old properties names will be used.

24320: Raised alert level from warning (yellow) to alarm (red) for three alerts

The severity level of the following alerts has been raised to "alarm" level: SolGuaranteedMsgingHbaLinkDown SolGuaranteedMsgingMatePortDown SolGuaranteedMsgingNoMsgSpoolAdActive

24321: Included Solace PSG Password Utility scripts

The scripts to execute the Solace PSG Utility have been added. This tool is used for adding the connection properties to InfluxDB with an encrypted password. To use the tool, open a command prompt or terminal and initialize it: cd <install_dir>/rtvapm> . ./rtvapm_init.sh **IMPORTANT - do not omit the leading dot in this step** or cd <install_dir>\rtvapm> rtvapm_init.bat and then cd to rtvapm\solmon\bin directory and execute: pwd-utility[.bat] <yourPwdString> the following message will appear: Solace PSG Password Generation Utility v0.0.0 ------------------------------------------------------------------- This program encrypts passwords for storage in application property files. The encrypted password is: 'yourEncryptedString' (without the quotes). You may use this value in the password field in configuration property files.

24323: Update jackson libraries from 2.8.4 to 2.9.9

The Jackson libraries used with the Solace PubSub+ monitor have been updated from version 2.8.4 to version 2.9.9.

24336: Soleventmodule: Empty filters shouldn't trigger syntax error messages

In previous releases, setting the following filter properties in soleventmodule.properties to blank did not work and generated an error: ALERT_WHITELST ALERT_BLACKLIST EVENTWRITER_WHITELST EVENTWRITER_BLACKLIST This has been fixed.

24355: Improved support for monitoring of Backup and Monitoring brokers

A bug that prevented that Solace Backup Message Routers from populating correctly to the Solace PubSub+ Monitor has been fixed. This fix also allows monitoring of Solace PubSub+ Brokers that are partially configured.

24362: SolBridgeStats data collection for statds connections fixed

A bug that prevented data from being stored into the SolBridgeStats cache has been fixed.

24363: soleventmodule now correctly creates alerts when recommended actions contains a hard return

In previous releases, the soleventmodule events that have hard returns in the Recommended Actions failed to generate alerts due to a json parsing error. This has been fixed.

24364: Count of spooled messages should match across Broker, VPN, and Endpoint displays

Previously the number of spooled messages per VPN did not match the sum of the spooled messages across all endpoints of the same VPN. This has been fixed.

24383: Integrated "show redundancy group" query

The information from the "show redundancy group" command of the Solace CLI has been included. The SolRedundantBrokers and SolMonitorBrokers caches are now storing the information from this request.

Solution Package for TIBCO FTL

24316: Update jackson libraries from 2.8.4 to 2.9.9

The Solution Package for TIBCO FTL has been updated to use v2.9.9 of the jackson libraries. Previously this solution package used v2.8.4

Version 5.1.1 Release Notes

Alerts

22590: SNMP traps sent by RTView Enterprise did not contain alert info

In previous releases, SNMP traps sent by RTView Enterprise alert notifications did not include all of the fields in the MIB. This has been fixed. SNMP traps can now be configured in the Configuration Application and match the new MIB defined in RTVAPM_HOME\common\lib.

23189: Included my_alert_actions scripts in all projects

RTView has been enhanced to include the my_alert_actions scripts in all project directories for ease of use.

23844: Enhance alert notification configuration.

Alert Notifications have been enhanced to support several new actions and a better configuration interface. For each notification, you can select one or more of the following actions: 1. Execute Script - This wil exectue the my_alert_actions*.bat/sh scripts in the project directory. This is the same action that was used in the previous releases when a notification was enabled. 2. Execute Java Method- This will execute a custom java command. 3. Send Email - This will send an email to one or more recipients. 4. Send SNMP Trap - This will issue an SNMP trap as described in RTVAPM_HOME\common\lib\SL-RTVIEW-EM-MIB.txt. 5. Other - This will execute any command supported by our core product. 6. Conditional - This will allow you to execute different commands based on values in the alert. For example, you could email Jvm alerts to the system administrator and Ems alerts to the TIBCO administrator. The user interface in the Configuration Application has also been enhanced with better descriptions of additional configuration needed for the selected actions. Upgrade Notes In previous releases, any notification other than executing the my_alert_actions scripts had to be configured on the CUSTOM PROPERTIES tab of the Configuration Application. If you are running a project configured with a previous release that has alert notifications defined in the CUSTOM PROPERTIES tab, they will continue to work as they did before with no changes. However, if you want to use the new Alert Notification configuration page, you will need to first delete the CUSTOM PROPERTIES for alert notifications, then recreate them in the Alert Notification page. Otherwise, the CUSTOM PROPERTIES will override the settings in the Alert Notification page.

24078: Alert Renotification interval default value corrected

In previous releases, the Renotification Interval in the Configuration Application incorrectly listed the default value as 300 seconds. This has been fixed. The default is now set to 0. Users must set it to a value greater than 0 in order to issue renotifications.

24187: Alert overrides with multiple indexes fixed for HTML UI

The HTML UI now supports alert overrides with multiple indexes.

Configuration

23516: Support Configuration Application for HA servers

The Configuration Application and Rest API for editing properties have been enhanced to support editing High Availability projects. In order to edit a High Availability project, the Configuration Application (rtvadmin servlet) must be configured for High Availability as follows: - When accessing the Configuration Application in jetty, no additional configuration is needed. It will automatically be configured for High Availability if the server is run with -haprimary or -habackup. - When hosting the Configuration Application on an application server, edit the update_wars.bat (or .sh) file in the projects\rtview-server directory, set HOST to the PRIMARYHOST value and HA_HOST to the BACKUPHOST value. Then run update_wars and deploy the rtvadmin war file to your application server. - To configure an HA pair of RTViewDataServers via the RTViewCentral Configuration Application, make sure that the RTViewCentral connection to the RTViewDataServer is using a fault-tolerant URL. Properties saved in Configuration Application or via the Rest API will be applied to both the primary and backup servers. Therefore, the primary and backup servers must be able to run with identical properties. In the case where drivers and other third party jars are located in different places on the primary and backup systems, you must add a directory in the same location on each system, copy the jars into that directory and reference that directory in the classpath entries so that the same path can be used for both systems. The Restart Servers option in the Configuration Application and Rest API will restart both the primary and backup, one right after the other to apply the properties. The updatePropertiesOnServers option in the Rest API will update properties on both the primary and backup, one right after the other. The Configuration Application (rtvadmin servlet) must be connected to both the primary and backup servers in order to support editing. If you get a not connected error, be sure that both the primary and standby servers are running and accessible from the Configuration Application.

23584: Tab key now works for mqmon's Channel Filter field

In MQMon, the Tab key now works when adding new Channel filters

23641: Support for updating properties via rest api

RTView has been enhanced with a rest api for editing solution package properties. This is to support the following use cases: 1. Importing an initial set of connections into the Configuration Application. This is useful in the case where there are a lot of connections and adding them via the Configuration Application ui will be too time consuming. Once the connections are imported using the rest api, all further editing can be done in the Configuration Application. 2. Dynamic updating of connections via automated process. These connections will only be updated via the automated process and will not be included in the Configuration Application. Connections will be applied without requiring a restart of the data server. Solace and TIBCO Enterprise Message Service properties are editable in the new rest api. Other solution packages properties will be added soon. A sample application has been added to all deliverables that shows how to use the rest api under rtvapm\sampleapps\propeditor. See the README.txt in that directory for instructions on using the rest api.

23869: Fixed error in log file after saving WSM configuration

An unnecessary json element is no longer saved to the properties file for the IBM WebSphere solution package.

23892: Single sign-on disabled for the Configuration Application and HTML UI

In previous releases, the Configuration Application and the new HTML UI were configured for single sign-on. When a user logged into the HTML UI as rtvuser then tried to open the Configuration Application they would get a 403, not authorized error since the Configuration Application requires an rtvadmin login. This has been fixed by disabling single sign-on. Now, the user is prompted for a separate login for the Configuration Application.

23941: Can now restart data server without changing configuration

Servers can now be restarted from the Projects page even if no changes have been made that require a restart.

23965: Config UI now prevent users from using "default" domain for hawk

In previous releases, the Configuration Application TIBCO Hawk Add Connection dialog saved an invalid property when the Domain field was set to default. This has been fixed by preventing the Domain field from being set to default. For connections to the default TIBCO Hawk domain, use a dash (-) in the Domain field instead.

23996: Changed Sender tab in Configuration Application to use Collector in labels

The SENDER tab in the Configuration Application has been updated to use the term collector instead to be consistent with the RTViewDataCollector product name.

24001: Path to custom directory now consistent across all RTView deliverables

The RTViewDataServer project has been enhanced to include the custom directory in projects\custom. This directory contains sample custom function, command, app and rtview handlers. The custom command handler contains an outputAlertNotification method that can be optionally be executed for alert notifications. The custom directory in the following deliverables has been moved to projects\custom: TIBCO EMSMonitor TIBCO BWMonitor TIBCO BEMonitor OCMonitor

24032: Configuration Application updated to handle new Solace data acquisition.

The solace connection dialog in the Config UI now supports HA pairs and is also able to use the stats pump connection for non-cloud vmr's.

Distribution

23737: Version now available from HTML UI

Users can now see the version of RTView from the HTML UI by clicking on the product name at the top left.

23814: Cleaned webapps directory in bundled apache Tomcat

In the previous release, the webapps directory of the bundled Apache Tomcat contained extraneous RTView demo .war files. These have been removed.

General

23624: Configuration Application now catches Data Server's memory sizes without a unit (e.g., m or g)

In the Configuration Application, the Data Server's initial memory and max memory fields now have additional error checking to help ensure that only valid values are saved.

23834: Export to Excel no longer fails

The export to Excel feature now works reliably on tables in the rtview-central and rtview-solmon UIs

23837: No Date Picker in filter options for timestamp columns

In Component Displays, all date columns in all tables were formatted as strings, which disabled all date-specific options in the table header's menu. Now date-specific options are available in all Component Displays.

23928: Corrected scrolling behavior of HTML UI in FF and Edge

A bug has been fixed that affected the vertical scrolling behavior of the HTML UIs in Firefox and MS Edge. Now the left-hand navigation panel and the main display panel each has its own vertical scrollbar, as expected. This bug did not affect Chrome.

24099: Displays now support dynamically changing CIs

Additions and deletions of elements are now reflected in the filter drop-downs of all Component Displays. By default, lists update once per minute.

24167: Grey out rows for all tables with expired rows.

Expired rows are now grayed out in all components displays with an applicable table.

Platform Support

23961: Rename ActiveSpaces to ActiveSpaces 2 in Navigation Tree and Configuration Application

The RTView monitor for TIBCO ActiveSpaces 2.x has been renamed to "ActiveSpaces 2" in the thin client navtree and the configuration application. Previously it was "ActiveSpaces".

RTVMGR

24166: Dataserver drop down on the Cache Table component display no longer empty

In Firefox, the Data Servers in the Data Servers dropdown on the Cache Table display were invisible. This has been fixed.

24232: RTView Data Servers Table now sorted by Name column by default

The table on the Data Servers display is now sorted by name of data server by default.

24233: Drilldown on RTView Data Servers Table now selecting correct dataserver

A drilldown from the RTView Data Servers Table will once again select the correct data server. In the previous release, the first data server in the list was always selected.

RTView Core Functionality

Configuration

23886: Fixed bug effecting dynamic update of connection definitions

An issue that prevented connection definitions from being dynamically updated has been fixed.

Display Server

24123: Support 'nosniff' header in thin client in IE11

A problem has been fixed which prevented the thin client Classic UI from rendering displays correctly in IE11 when the web server set the X-Content-Type-Options:nosniff response header. No other supported browsers were affected by this issue. Site administrators may configure a web server to send the X-Content-Type-Options:nosniff response header for security reasons. With this fix the thin client is not affected by the presence or absence of that header, which is the correct behavior. A related note for Tomcat users: In standalone Tomcat, the X-Content-Type-Options:nosniff response header is set by enabling the httpHeaderSecurity filter in tomcat's conf/web.xml file. By default, that filter also sets the X-Frame-Options:DENY response header. That setting will disable the thin client even with the fix described in this release note. To avoid that problem, tomcat should be configured to set the X-Frame-Options response header to SAMEORIGIN rather than DENY, to allow pages hosted by the same tomcat instance (only) to load thin client displays in iframes. So to set X-Content-Type-Options:nosniff and X-Frame-Options:SAMEORIGIN, the httpHeaderSecurity filter should be configured as follows intomcat's conf/web.xml file: <filter> <filter-name>httpHeaderSecurity</filter-name> <filter-class>org.apache.catalina.filters.HttpHeaderSecurityFilter</filter-class> <async-supported>true</async-supported> <init-param> <!-- allow use in iframe on pages with same origin --> <param-name>antiClickJackingOption</param-name> <param-value>SAMEORIGIN</param-value> </init-param> </filter>

Distribution

24040: Update bundled Apache Tomcat 8.5.x to 8.5.41

The version of the bundled Apache Tomcat has been updated to 8.5.41 (previous was 8.5.35).

Scripts

23594: Added "status_servers.bat/.sh" convenience scripts

The following scripts have been added: RTViewCentral\bin\status_servers.bat RTViewCentral\bin\status_servers.sh RTViewDataCollectorSP\status_collector.bat RTViewDataCollectorSP\status_collector.sh RTViewDataServerSP\status_server.bat RTViewDataServerSP\status_server.sh RTViewSolaceMonitor\bin\status_servers.bat RTViewSolaceMonitor\bin\status_servers.sh

24088: HA support for rtvadmin in update_wars scripts

The HA_HOST parameter is now supported when updating the rtvadmin war files.

Solution Package

23800: Data Cache misconfiguration corrected

Previously the rowExpiredIndexColumns attribute of a cache created by the Data Cache was misconfigured. This is no longer the case.

Apache Kafka

23966: New key metrics and new alerts for kafka

The following alerts have been added to RTView Kafka Monitor: Alert - Description KafkaBrokerFetchRequestsPerSecHigh - Fetch Requests per second exceeds threshold for broker KafkaBrokerProduceRequestsPerSecHigh - Produce Requests per second exceeds threshold for broker KafkaConsumerRecordsConsumedRateHigh - Consumer records consumed rate exceeds threshold KafkaProducerRecordSendRateHigh - Producer record send rate exceeds threshold KafkaZookeeperCpuPercentHigh - CPU percentage reported by the JVM is above the limits defined for that Zookeeper KafkaZookeeperMemoryUsedPercentHigh - Percentage of heap memory used relative to the maximum heap available is above the limits defined for that Zookeeper Note also the alert KafkaConsumerMsgsPerSecHigh has been renamed KafkaConsumerRecordsConsumedRateHigh to reflect more accurately its metric. The following Key Metrics have been added to RTView Kafka Monitor: CI Type - Key Metric KAFKA-BROKER - Fetch Request Rate KAFKA-BROKER - Produce Request Rate KAFKA-BROKER - Message In Rate KAFKACONSUMER - Records Consumed Rate KAFKA-PRODUCER - Record Send Rate KAFKA-ZOOKEEPER - CpuPercent KAFKA-ZOOKEEPER - MemoryUsedPercent The following changes have been made to RTView Kafka Monitor history tables: 1. A new index column client-id has been added to KAFKA_CONSUMER 2. The column time_stamp has been moved to the beginning of the table for these tables: KAFKA_TOPICS_BY_CONSUMER KAFKA_TOPICS_BY_SERVER KAFKA_TOPICS_BY_TOPIC KAFKA_TOPICS_BY_TOPIC_CONSUM KAFKA_TOPICS_BY_TOPIC_SERVER Note these changes will cause previously saved history to be invalidated.

24089: New alerts for Kafka missing from HTML UI Alert Administration display.

The following Kafka alerts were missing from the Alert Admin displays. KafkaZookeeperMemoryUsedPercentHigh KafkaZookeeperCpuPercentHigh KafkaConsumerRecordsConsumedRateHigh KafkaProducerRecordSendRateHigh KafkaBrokerFetchRequestsPerSecHigh KafkaBrokerProduceRequestsPerSecHigh This has been fixed.

IBM Websphere MQ

23932: MODEL Queues may now be queried if desired

Previously it was not possible to to query a MODEL queue without undesirable side effects. This is no longer the case, and it is possible to query MODEL queues, if desired, without the undesirable side effects.

23934: MQMON default filter values now set correctly

Previously in MQMON, the default Channel and Queue Filter Values were not explicitly initialized to the correct default value. They are now set correctly, thus requiring no further action from the user, if they wish to use the default values for the filters.

Solace

23825: New filter defaults for SolaceEventModule

The SolaceEventModule configuration has been enhanced with improved defaults for the alert and event filters in RTVAPM_HOME\solmon\soleventmodule\soleventmodule.properties. Additionally, several commented out sample filters have been added for different monitoring scenarios.

23962: New statspump data source for Solace.

The Solace Stats Pump Data Source has been integrated into the RTView Solace Monitor. This new data source supports HA Broker Pairs and multi-threaded SEMP XML response parsing which improves Data Server performance. The Solace Stats Pump Data Source is used by default in the RTView Configuration Application. Cloud Brokers are the only type of Solace Brokers that are using exclusively the HTTP Data Source.

23963: Output Solace SEMP data to Influx DB

The Solace monitor has been enhanced to send monitoring data to InfluxDB. The configuration requires edition of the stats-receiver.properties file, located in the project directory, to define the list of metrics to store in Influx DB and the IP address and port of the InfluxDB platform to store the data. Please refer to the documentation for the specific configuration steps.

23964: Output Solace SEMP data from Solace Stats Pump to a Solace Broker

The Solace Stats Pump can be configured to execute in isolation and send monitoring data from multiple Brokers to a designated Broker. This configuration will not downgrade the performance of the monitored Brokers if the Broker that will receive the monitoring data is exclusively doing this task. The steps to configure Solace Stats Pump to send monitoring data to a Solace Broker are the following: - Define the Solace Brokers to be monitored by editing the file appliance_config_demo.xml - Define the monitoring data to be polled by editing the file pollers_sl.xml - Define the poller groups that will be used by editing the file groups_sl.xml See the Solace documentation for further reference on how to configure Stats Pump for sending monitoring data to a Solace Broker.

23983: Removed calculated rates from SolVpns cache

Calculated rates from SoVpns cache have been replaced by the metrics delivered by Solace. The SOL_VPNS table from history should be dropped and recreated with the appropriate table create sql sentence you can locate in the rtvapm\solmon\dbconfig directory.

23985: User and some event-driven boolean metrics added to SolClients cache

User and boolean fields associated with one-show events have been added to Solace Client metrics. These booleans are: eliding-enabled, large-message-event-raised, max-eliding-topics-raised, message-too-big-event-raised, parse-error-event-raised

23994: Topic and Queue Rates added to the SolEndpointStats cache

Requests for message flow from Solace Topics and Queues have been added. These requests query all available Endpoints at once without the need of requesting this information per Endpoint.

23998: Added os-physical-interface to SolApplianceInterfaces cache

The os-physical-interface for each Broker Interface has been introduced into the SolApplianceInterfaces cache. This metric will be exposed in the Solace Interface Summary display from the Solace Monitor.

24015: New broker and endpoint alerts

The following new alerts have been added to the Solace monitor: - SolBrokerNoValidDestination alert, which will be triggered as an alarm alert when there exist currently invalid destinations in the broker. (Delta of discard-nodest is non-zero). - SolBrokerNoQueueFound alert, which which will be triggered as an alarm alert when there are discarded queues in the broker. (Delta of discard-queue-not-found is non-zero). - SolEndpointNoBridgeClient alert, which will be triggered as an alarm alert when no binds for the Solace Endpoint exist (bind-count is zero). - SolBrokerNoSubscriptionMatch alert, which will be triggered as an alarm alert when there are no current subscription matches (Delta of no-subscription-match is non-zero). - SolEndpointNoBridgeTopic alert, which will be triggered as an alarm alert when there are no topics subscribed to the Queue (topic-subscription-count is zero). Limitation of SolBrokerNoValidDestination, SolBrokerNoQueueFound and SolBrokerNoSubscriptionMatch Alerts: The request XML is a system level request. The cloud logon credentials will not have permission to execute this request, so this alert will not be executed for Cloud Brokers.

24033: Not clearable event module alerts now clear after expiration time

In the previous release, SolEventModule alerts that were based on non-clearable events sometimes did not clear. This has been fixed.

24055: Replaced calculated rates from SolBridgeStats cache with Solace provided rates

Calculated rates from SolBridgeStats cache have been replaced by the metrics delivered by Solace. The SOL_BRIDGE_STATS table from history should be dropped and recreated with the appropriate table create sql sentence you can locate in the rtvapm\solmon\dbconfig directory.

24056: Replaced delta/rate calculated metrics with Solace provided CSPF rates

The calculated rates for Solace CSPF Neighbors have been replaced by Solace calculated rates. The SOL_CSPF_NEIGHBOR table from history should be dropped and recreated with the appropriate table create sql sentence you can locate in the rtvapm\solmon\dbconfig directory.

24057: Rename calculated rates from SolClientStats cache with those from Solace

Calculated rates from SolClientStats cache have been replaced by the metrics delivered by Solace. The SOL_CLIENT_STATS table from history should be dropped and recreated with the appropriate table create sql sentence you can locate in the rtvapm\solmon\dbconfig directory.

24060: Calculated rates in SolVpns cache replaced by those provided by Solace

Calculated rates from SoVpns cache have been removed except for the total ingress/egress discard rates. The SOL_VPNS table from history should be dropped and recreated with the appropriate table create sql sentence you can locate in the rtvapm\solmon\dbconfig directory.

24082: Solace event module no longer reporting regex errors

In previous releases, the soleventmodule sometimes threw parsing errors on the following syslog messages: CLIENT_CLIENT_BIND_SUCCESS SYSTEM_AUTHENTICATION_SESSION_CLOSED SYSTEM_AUTHENTICATION_SESSION_OPENED This has been fixed.

24090: Ingress/egress message rates added to Endpoint Summary

Endpoint summary display has been enhanced with history of ingress/egress message rates.

24106: Force VPN name when adding a cloud connection

Solace PubSub+ Cloud broker connections now require the use of a VPN name.

24158: SolEventModule typo for BLACKLIST

Previously there was a bug filtering events and alerts by the priority of BLACKLIST. This has been fixed.

24185: Support for HA Solace Brokers

Support for adding HA Pairs has been introduced. Using the Configuration Application, specify the URL, port, and credentials for the Primary and Backup Brokers. Two rows in the broker table for each broker will be added. Note that the Backup Broker will be identified by having the string "-standby" concatenated to the connection string.

24186: Solace Event Module can be used as sole source of monitoring data

The Solace PubSub+ monitor can be configured to run with all data being provided via the Solace Event Module; without connection properties being configured to Solace Brokers. See the RTView Solace Monitor documentation for a complete description of the configuration steps of the Solace Event Module.

24192: New standby filter selection list added to Solace Broker table and heatmap

An 'Show Standby' selection list has been added to filter the table and heatmap of Solace Brokers.

24193: Solace Broker Environmental Sensors should only show data from a single broker

The Solace Broker Sensors display now enforces selection of a single Broker.

TIBCO ActiveSpaces

23811: New Solution Package for TIBCO Active Spaces (4.1+)

A new solution package TDGMON has been added in support of TIBCO ActiveSpaces 4.1, and is configurable in the Configuration Application. Connections are made to this solution package via the FTL server that is part of the ActiveSpaces Realm. Refer to the RTView Enterprise Userguide for more information.

23828: TIBCO ActiveSpaces 2 solution has been enhanced to support User Authentication

The connections in the TASMON solution package have been enhanced with additional properties to support user authentication on appropriately configured security domain controllers for a metaspace.

TIBCO BusinessWorks

23847: Hawk displays now showing correct memory usage for Hawk agents

On some Linux systems the Hawk displays in BW Monitor were showing incorrect values for Memory Used and Memory Used % of the Hawk agents. This has been corrected.

23957: osgi plugin default port updated

The BW Monitor OSGi plugin default target port has been changed to 3272 to correspond to the default receiver port on the RTView dataserver.

23971: BW6_PROCESS_TOTALS_APP* database schemas changed order of time_stamp column

The column order of three caches in the TIBCO BusinessWorks monitor have been changed, so that the time_stamp column is now first. The associated database schemas have been updated: BW6_PROCESS_TOTALS_APP BW6_PROCESS_TOTALS_APPNODE BW6_PROCESS_TOTALS_APPSLICE Users are advised to drop and recreate these tables. Alternatively, you can consult with your DBA on the safest way to execute a column reorder for your existing tables.

23972: Row expiration time now set correctly for BwApps and BwAppNodes

In the BW Monitor App and AppNode caches, the expiration time was being set to the wrong value. This has been corrected.

24136: Removed double entries from bw6mon process cache history

The BW monitor process data was including spurious rows in its history data with values of zero, which would cause process data trends to appear in a "sawtooth" pattern. This has been corrected.

24177: Changed expiration time for delete to 7 days for appnode and app

The default value for the time it takes an expired application or appnode to be removed from the displays has been increased from 24 hours to 7 days.

24178: Reorder process data columns in app and appnode tables

The columns in the Applications, Containers, AppSlices and AppNodes tables have been reordered to bring the most useful information to the front of the tables. On the Containers table the Name Filter was incorrectly labeled "Container Name Filter". It actually filters on Application name. This has been corrected.

24179: Created rate value now zeroes

If a process had an instance created in one update interval, then no further creation, the Delta Created and Created/sec values should go to zero on the next update. This was not happening; the values would retain their previous values indefinitely. This has been fixed.

24231: BW Application Node Summary drill downs corrected

Drilldowns from metric cards in TIBCO BusinessWorks Application Node Summary displays have been removed or fixed where applicable.

24234: Some components displays "blink" multiple times as they are loading

TIBCO BusinessWorks Application Summary and Application Node Summary displays have been enhanced to improve loading and customer experience.

TIBCO EMS

23296: Fixed typo in name of alert for EMSMON Key Metric asyncDbSize

A typo in EmsServerAsyncDBSizeHigh that prevented the asyncDbSize key metric from working has been forrected.

24229: Updated upper navigation dropdown to contain all available displays

Component Display navigation for TIBCO EMS monitoring has been enhanced so that all displays in each section are listed in the dropdown navigation on displays in that section.

TIBCO FTL

23927: TIBCO FTL 6.0 support

Support for TIBCO FTL 6.x has been added and support for TIBCO FTL 5.x has been deprecated.

Version 5.0.0 Release Notes

23222: Build with Java 1.8 + drop support for Java 1.7

RTView is now built with Java 1.8 Java 1.7 is no longer supported.

23386: Fix the Oracle Storage metrics so that the new component display trend graph renders correctly

The ORAMON solution package includes two new metrics in history for disk utilization: USED_DATA and TOTAL_DATA.

23671: New Syslog Event alerts

Three new alerts for Solace monitor for monitoring Syslog Events for the scopes SYSTEM, VPN, and CLIENT have been implemented. These alerts are named: SolEventModuleBrokerAlert SolEventModuleVpnAlert SolEventModuleClientAlert ... and require the Solace Event Module being configured and running. These alerts handle simultaneously Clearable and Non-Clearable Syslog Events. See TN23693 for details on how the Solace Event Module is configured and executed in the Solace Monitor.

Alerts

20783: Fixed "GmsAlertNotifier-1" java.lang.NullPointerException in alert server

In previous releases, when alert persistence was enabled and notifications for cleared alerts were disabled, a null pointer exception could be thrown on startup. This has been fixed.

23417: Added email command example to my_alert_actions.sh

The my_alert_actions.sh alert notification script has been enhanced with a commented out example of how to send an email.

Configuration

22281: Support for restarting central and non-data servers from config ui

Restarting from the Configuration Application has been enhanced as follows: 1. The RTView Central servers can now be restarted from the Configuration Application. 2. The RESTART DATASERVER button has been renamed to RESTART SERVERS. In addition to restarting the data server, it now restarts the associated historian and display server if they are running.

22286: Improved support for configuring high availability

High availability configuration has been added or simplified for all RTView deliverables. See the documentation for details.

22526: Enlarged font for help text in Config UI

The font size for help text throughout the ConfigUI has been enlarged to make reading easier.

23068: Data Server projects now support announcing themselves to RTViewCentral

RTViewDataServers have been enhanced to make it easier to integrate with EM. Previously, to integrate an RTViewDataServer with Enterprise Monitor, you had to go into the Central Server configuration, add a connection to the RTViewDataServer and then copy over the common properties. With this enhancement, all configuration can be done in the RTViewDataServer configuration and reasonable defaults are provided. To simplify deploying via container, all values on the EM Integration tab can be set via environment variable instead of in the Configuration Application. All fields on the EM Integration tab show the Source of the value to the right of the field if the value wasn't specified in the Configuration Application. NOTE: This feature is not supported by central servers running in an emsample project created with a previous release. It requires the new RTViewCentral project. To configure this feature, select the RTViewDataServer in the Configuration Application and click on the EM Integration item in the navigation tree. Fill in the following options: Integrate with Enterprise Monitor - If enabled, connect to the Central Server in the RTViewCentral deliverable using the url in the Central Server URL field, disable local alert notifications (notifications will be handled by the Central server) and get alert thresholds from the Central Server. Note that in order to see your data and alerts in RTViewCentral, you must also add a connection from RTViewCentral to this RTViewDataServer either by enabling the "Announce this RTView Data Server to the Central Server" option and filling in the fields below or by going into the RTViewCentral Configuration Application and adding a connection on the Central Data Server->CONNECTIONS tab. The default for this field is false (0). It can be enabled via this environment variable: RTVDS_INTEGRATEENABLED. For example, RTVDS_INTEGRATEENABLED=1. Central Server URL - The URL to use when connecting to the Central Server in the RTViewCentral installation when Integrate with Enterprise Monitor is enabled. The default is localhost:10018. You can set the value via this environment variable: RTVDS_CENTRALURL. For example, RTVDS_CENTRALURL=http://localhost:10070/rtvdata. Announce this RTView Data Server to the Central Server - If enabled, the Central Server will make a connection to the RTView Data Server in order to display data and alerts from this server. The Central Server will use the values from the RTView Data Server Name, RTView Data Server URL, RTView Query URL, RTView Data Server Host and CITypes to Exclude fields described below when making it's connection to this RTView Data Server. The default is false. You can enable this via this environment variable: RTVDS_ANNUNCIATEENABLED. For example RTVDS_ANNUNCIATEENABLED=1. RTView Data Server Name - The name that the Central Server should use for its connection to this RTView Data Server. This name must be unique within the connections on the Central Server. The default is the Project ID from the General tab. You can set the value via this environment variable: RTVDS_NAME. For example, RTVDS_NAME=EMSMON_LOCAL. RTView Data Server URL - The URL that the Central Server should use for its connection to this RTView Data Server. The default depends on the HTML Server Enabled option on the Data Server tab. If the HTML Server is enabled, the default is http://hostname:3270/rtvdata, otherwise it is hostname:3278 where 32 is the Port Prefix for this project and hostname is the RTView Server Host. You can set the value via this environment variable: RTVDS_URL. For example, RTVDS_URL=http://myhost:8068/rtvdata. RTView Query URL - The URL that html clients should use to query this RTView Data Server. The default depends on the HTML Server Enabled option on the Data Server tab. If the HTML Server is enabled, the default is http://hostname:3270/rtvquery where 32 is the Port Prefix for this project and hostname is the RTView Server Host, otherwise it is blank. You can set the value via this environment variable: RTVDS_QUERYURL. For example, RTVDS_QUERYURL=http://myhost:8068/rtvquery. RTView Data Server Host - The Host name or ip address that the Central Server and html clients should use for connections to this RTView Data Server. The default the ip address for the host. You can set the value via this environment variable: RTVDS_HOST. For example, RTVDS_HOST=localhost CITypes to Exclude - The CI Types to exclude from the Service Model in the Central Server. The defualt is blank which means all CI Types for the configured solution packages are included in the Service Model. You can set the value via this environment variable: RTVDS_CITYPESTOEXCLUDE. For example, RTVDS_CITYPESTOEXCLUDE=BW-ACTIVITIES,BW-PROCESSES.

23071: New RTViewCentral deliverable

Enterprise Monitor has been enhanced with a new RTViewCentral deliverable. The project in this deliverable is similar to the central servers in the emsample project that was included in previous releases. Emsample projects created with a previous release will run in this deliverable with no changes, however there are some limitations when using the Configuration Application in this case. These limitations are listed in the release note for TN23288. This deliverable is meant to be used in conjunction with one or more RTViewDataServer installations which will provide the data. This is the workflow for setting up an RTViewCentral deliverable to work in conjunction with an RTViewDataServer installation: 1. Install RTViewCentral and run it using the appropriate start_servers script in the RTViewCentral\bin directory. 2. In a browser, navigate to http://localhost:10070/rtvcentral and login (admin/admin or demo/demo) to access the Enterprise Monitor. 3. Install the version of RTViewDataServer that contains the solution packages for which you would like to collect data and run it using the appropriate start_servers script in the top level directory. 4. In a browser, navigate to http://localhost:3270/rtvadmin and login (rtvadmin/rtvadmin). Use the Configuration Application to configure data collection. Then configure EM Integration. On the EM Integration tab, turn on Integrate with Enterprise Monitor and Announce this RTView Data Server to the Central Server. Fill in the other fields if the defaults will not work for your setup. See the release note for TN23068 for more information on the EM Integration tab. Restart your RTViewDataServer to apply your changes. Optionally confirm you are receiving data by browsing to http://localhost:3270/common and confirm you see data in the caches. 5. In the browser from step 2, you should see the following: - in the ADMIN tab, go to Architecture->System Overview and you should see the RTViewDataServer you just configured. - you should see data from your RTViewDataServer in the SERVICE TREE, SERVICE VIEWS and COMPONENTS tab - In the ADMIN tab, you can enable alerts and adjust thresholds for the alerts in the RTViewDataServer. Alerts should then show up in the ALERTS tab.

23073: Support for adding refs to all sp's without including each in project.properties

RTView EM has been enhanced with a new way of specifying rtvapm_reference properties. Instead of listing a reference property for each solution package, e.g. rtvapm_reference=bwmon rtvapm_reference=hawkmon rtvapm_reference=emsmon ... you can now simply use the property "rtvapm_reference=all" and RTView EM will add references for all the solution packages in your RTVAPM_HOME, and any custom solution packages in your RTVAPM_USER_HOME.

23273: Password no longer deleted after saving an edited Hawk EMS connection in BW6 config UI

A fix was made to an issue where passwords were being deleted when certain Hawk connections were edited.

23288: Configuration Application changes for new deployment architecture

The Configuration Application has been enhanced to support the new RTViewCentral deliverable, the RTViewDataServer Enterprise Monitor Integration and to make configuration options easier to find. Changes have been made under RTView Central Server and under the RTView DataServer sections. RTView Central Servers Section Changes: 1. The General->COMMON tab has been removed as the RTViewCentral project does not support common properties files. When running the Configuration Application in an emsample project from a previous release properties from conf\project-common.properties are merged into the local properties. 2. The General->About tab has a new field named Central Server URL. This field is for reference purposes only to store the url that RTView DataServers should use to connect to the Central Server and defaults to localhost:10018. When running the Configuration Application in an emsample project from a previous release the Config Server URL from conf\project-common.properties is copied into this field. 3. A new Databases entry has been added to the navigation bar which contains all of the Database connection fields: The Alert Threshold and Historian database fields were moved here from the General->COMMON tab. The Diagram Generator, Metric Explorer and CMDB databases were moved here from the Central Config Server->CONFIGURATION and CMDB tabs. The "Access the Alert Threshold Database via the Central Config Server Instead of Connecting Directly" field has been removed as the new deployment architecture has merged the Central Config Server and Central Alert Server into a single server. When running the Configuration Application in an emsample project from a previous release, the Alert Threshold and Historian databases properties from conf\project-common.properties are copied to this tab. If the "Access the Alert Threshold Database via the Central Config Server Instead of Connecting Directly" setting is enabled, it will be maintained but the Configuration Application does not provide a way to disable it. 4. The Central Alert Server->ALERTS and DATA STORAGE tabs have moved to the new Alerts section of navigation bar. 5. The Central Config Server section has been removed. The new RTViewCentral deliverable has merged the Central Config and Central Alert Servers into a single Central Server that serves both functions. The database fields on the Central Config Server->CONFIGURATION SERVER and CMDB tabs have moved to the Databases section. The other fields on the CMDB tab have moved to the new Service Model navigation bar entry. When running the Configuration Application in an emsample project from a previous release where the Memory and/or Log settings for the Central Config Server were overridden, those values are copied to the General->CUSTOM PROPERTIES tab. 6. The Central Alert Server section has been removed. The new RTViewCentral deliverable has merged the Central Config and Central Alert Servers into a single Central Server that serves both functions. The ALERTS and DATA STORAGE tabs have moved to the new Alerts navigation bar entry. When running the Configuration Application in an emsample project from a previous release where the Memory and/or Log settings for the Central Alert Server were overridden, those values are copied to the General->CUSTOM PROPERTIES tab. 7. The Data Servers navigation bar entry has been removed and the Data Servers->CONNECTIONS tab has been moved to the new Central Server section. The Select Mode for Including Solution Packages on the COMPONENTS tab field has been removed. The COMPONENTS tab has been enhanced to only include displays for the solution packages in all enabled connections. See the release note for TN23074 for more information. 8. The new Central Server entry in the navigation bar lets you set memory and log file options for the Central SErver and also add RTView Data Server connections on the CONNECTIONS tab. RTView Data Server Server Configuration Section Changes: 1. The General->ALERTS tab has moved to the Alerts navigation bar entry. The Alert Threshold Database Connection entry has moved to the new Databases navigation bar entry. When running the Configuration Application in an emsample project from a previous release, the Alert Threshold database property from conf\project-common.properties (previously set on the COMMON tab under RTView Central Servers) is copied to this tab unless it was previously overwritten locally. If the "Access the Alert Threshold Database via the Central Config Server Instead of Connecting Directly" setting was enabled, it will be maintained but the Configuration Application does not provide a way to disable it. The "Configure notifications for this server in addition to central notifications" option has been removed but will be maintained when running in an emsample project created with a previous release. To disable local notifications, turn off Enabled Notifications. 2. The Historian->HISTORIAN Historian Database Connection entry has moved to the new Databases navigation bar entry. When running the Configuration Application in an emsample project from a previous release, the Historian database property from conf\project-common.properties (previously set on the COMMON tab under RTView Central Servers) is copied to this tab unless it was previously overwritten locally. 3. The Data Server->SENDER tab was previously only visible when running with the sender property filter. It is now always visible so that you can configure the sender before running it. 4. A new EM Integration navigation bar entry allows you to integrate the RTViewDataServer with the Enterprise RTView Monitor. See the release note for TN23068 for more information.

23346: Refresh prompt added to avoid "invalid project not editable" error

The Configuration Application will now show a message asking the user to refresh when it encounters difficulty connecting to a server after that Data Server (or Data Collector) has been restarted.

23359: Persist alert option for central server no longer saves wrong property

In previous releases, the Configuration Application saved the wrong value for the Persist Alerts option under RTView Central Servers. This has been fixed.

23364: Support added for searching connections

Searching and sorting functionality has been added to all connection lists.

23391: History Storage - Keys field removed from MySQL configuration

The History Storage Keys field on the DATA STORAGE tab of the config ui was removed.

23402: DATA STORAGE tab now hidden when running as a sender

When a server is running as a sender (ie in the RTViewDataCollector), the options on the ConfigUI's DATA STORAGE tab do not apply. In this case, the tab will be hidden.

23415: Connection to localhost no longer fails when added via config ui

In previous releases, connections added in the Configuration Application or properties file with localhost in the URL were ignored. This has been fixed.

23457: Fixed password-deletion bug in TIBCO Hawk connections

A fix was made to an issue where passwords were being deleted when certain Hawk connections were edited. Additionally, new EMS connections could not be created if the password field was blank.

23563: Added new AMXMON expiration settings to Configuration Application

The TIBCO ActiveMatrix section of the Configuration Application has been enhanced include fields to set the expiration and delete time for the AmxNodes cache: Node Expire Time - Sets the amount of time between data updates for a row to be marked expired. Node Delete Time - Sets the amount of time between data updates for a row to be deleted.

23674: Editing existing connection no longer results in a new duplicate connection

Previously editing existing connections could accidentally created clones. This has been fixed.

23686: Solace branding changes in Config UI

The Solace Configuration Application pages have been updated to reflect current Solace branding.

Data Model

23540: Metrics and alert added for information relating to In-Synch Replicas at the topic level

The following metrics have been added to the Solution Package for Kafka in the All Topics Table and Heatmap: replicas replicas-outofsync. These values are summed across all the partitions of the topic. The following alert has been added to Solution Package for Kafka: KafkaClusterTopicReplicasOutOfSync This may be selected for all topics in a given cluster or individual topics in a given cluster. The default values are 5 for warning and 10 for alert, representing the number of replicas out of sync for the topic.

Deployment

23403: jetty no longer requires a jdk to host the thin client

In previous releases, hosting the thin client in jetty required a jdk instead of a jre. This has been fixed.

Distribution

23072: Tomcat bundled with RTViewCentral deliverable

The RTViewCentral deliverable contains an Apache Tomcat distribution (v8.5.35) configured for the convenience of the user. It is at RTViewCentral/apache-tomcat-8.5.35. The file RTViewCentral/apache-tomcat-*/README_RTVIEW.txt lists the changes made to this distribution. If you wish to use this Tomcat instead of Jetty as your appserver, do the following: - Under the RTViewCentral/bin directory, edit start_servers[.bat/sh] and stop_servers.[bat/sh] to uncomment the lines to start/stop Tomcat. For example, for the start_servers script: Windows: rem echo ... starting Tomcat server rem call start_tomcat.bat to: echo ... starting Tomcat server call start_tomcat.bat Linux: #echo "... starting Tomcat server" #. ./start_tomcat.sh to echo "... starting Tomcat server" . ./start_tomcat.sh The next time you start/stop your servers, the Apache Tomcat server will also be effected.

23076: New RTViewDataServer variants

The RTView DataServer is used for sending data to RTView Cloud displays and dashboards, or for sending data to an on-premise RTView Central Server deployment. In this release the RTView DataServer product line has been expanded to a family of 7 variants. RTView(R) DataServer (released in EM 4.1) ```````````````````````````````` Basic DataServer capabilities using the Data Cache. Files: RTViewDataServer_x.zip RTView(R) DataServer for Infrastructure ```````````````````````````````````````````````````````` For monitoring non-middleware and open-source elements. Includes Solution Packages for: - Data Cache - RTView Management - RTView Host Agent - Docker - MongoDB - MySQL - MS SQL Server - Node - JBoss - VMWare - Amazon Cloudwatch - User Experience Files: RTViewDataServerInfra_x.zip RTViewDataCollectorInfra_x.zip RTView(R) DataServer for TIBCO (Released in EM 4.2) ``````````````````````````````````````````````` For monitoring of TIBCO's middleware products. Includes Solution Packages for: - Data Cache - RTView Manager - TIBCO Active Spaces (2.x) - TIBCO ActiveMatrix - TIBCO Adapters - TIBCO BusinessEvents - TIBCO BusinessWorks - TIBCO BusinessWorks 5 - TIBCO Enterprise Message Service - TIBCO FTL - TIBCO Hawk Files: RTViewDataServerTIBCO_x.zip RTViewDataCollectorTIBCO_x.zip RTView(R) DataServer for IBM ``````````````````````````````````````````` For monitoring of IBM's products. Includes Solution Packages for: - Data Cache - IBM DB2 - IBM WebSphere - IBM MQ Files: RTViewDataServerIBM_x.zip RTViewDataCollectorIBM_x.zip RTView(R) DataServer for Oracle ``````````````````````````````````````````````` For monitoring of Oracle's products. Includes Solution Packages for: - Data Cache - Oracle Database - Oracle Coherence - Oracle Weblogic - Oracle Enterprise Manager Files: RTViewDataServerOracle_x.zip RTViewDataCollectorOracle_x.zip RTView(R) DataServer for Solace (Released in EM 4.2) ``````````````````````````````````````````````` For monitoring of Solace appliances. Includes Solution Package for: - Data Cache - Solace - Syslog Files: RTViewDataServerSolace_x.zip RTViewDataCollectorSolace_x.zip RTView(R) DataServer for Kafka (Released in EM 4.1) ``````````````````````````````````````````````` For monitoring of Apache Kafka. Includes Solution Packages for: - Data Cache - Apache Kafka - RTView Management Files: RTViewDataServerKafka_x.zip RTViewDataCollectorKafka_x.zip

23412: UX Robot no longer bundled inside product deliverables

The UX Robot agent (UXRobot_*.zip) is no longer packaged inside the Solution Package for User Experience. It is available as a separate download.

General

23074: have components tree automatically populate based on cisource properties

The tree for the COMPONENTS tab has been enhanced to filter the available displays based on the solution packages hosted by the enabled RTView Data Server connections. When running in an emsample project from a previous release where the tree was customized, this filter will be applied in addition to any customization.

23407: RTView Manager included with RTViewCentral deliverable

The RTViewCentral deliverable has been enhanced to contain an RTView Manager project. The purpose of this project is to monitor the RTView Central Servers a well as any RTViewDataServers to which Central is connected. All RTView Manager connections in this project are discovered from the RTView Central Server and cannot be edited. This monitor runs stand-alone and is not included in the EM Central views. To access this monitor, go to http://localhost:3070/rtview-manager.

23687: New user names added to the thin client

The default thin client login has been enhanced to support the following new users: user = rtvadmin, password = rtvadmin, role = admin user = rtvuser, password = rtvuser, role = read-only user = rtvalertmgr, password = rtvalertmgr, role = event The previously supported default users (admin, demo) are still supported for the thin client in RTViewCentral, but the new login must be used for the beta Enterprise Edition user interface. In RTViewSolaceMonitor, the new login must be used.

RTVRULES

23078: rtvrules added to RTViewCentral

RTViewCentral has been enhanced to the contain the rtvrules project previously available in emsample. This project supports service level alerts.

RTView Core Functionality

Alerts

23373: Improved error reporting when persistence database doesn't have correct schema

The Alert Engine has been enhanced to provide expected column information in the case where the Alert Persistence database table does not contain the correct schema.

Data Historian

23504: Historian now detects lost database connection when using prepared statements

Previously, under certain circumstances, the Historian would not detect lost database connections when using prepared statements. This is no longer the case.

Data Server

23491: Options added to rtvquery for how to output NaN

The rtvquery servlet has new options for specifying how values of NaN, Infinity, and -Infinity should appear in the response. The new options are infval, and neginfval, and nanval. infval: The value to use for +Infinity neginfval: The value to use for -Infinity nanval: The value to use for NaN, and for +Infinity if infval is not specified, and for -Infinity if neginf is not specified. These options are recognized only if the nanok option is set to true (nanok=true) and if the requested format is json (fmt=json). These options can be useful if the rtvquery response will be parsed by 3rd party apps that expect specific strings for those values. For example, if a parser expects the string "null" for values of NaN and +/-Infinity, the following options should be used: http://somehost/rtvquery/cache/MyCache/current?fmt=json&nanok=true&nanval="null" Note that the quotes around null are required to make it a valid JSON string. Or, for a parser that expects zero for NaN and +/-Infinity: http://somehost/rtvquery/cache/MyCache/current?fmt=json&nanok=true&nanval=0 Or, for a parser that expects zero for NaN, 99999 for +Infinity, and -99999 for -Infinity http://somehost/rtvquery/cache/MyCache/current?fmt=json&nanok=true&nanval=0&infval=99999&neginfval=-99999 If none of the new options is specified, then the behavior is the same as in previous releases: That is, if nanok = true, then NaN appears as "NaN" in the response, +Infinity appears as "Infinity", and -Infinity as "-Infinity". If nanok = false or is not specified, then NaN, +Infinity,and -Infinity all appear as "" (an empty string) in the response.

Data Sources

23500: Duplicate database connection errors no longer printed to log file

The error reporting for failed database connection attempts has been enhanced. Previously, an error was printed to the console for each failed connection attempt. Now, an error is reported for the first failed connection attempt and no more output is generated until a success message is printed when the connection succeeds. The connection error is only printed again the first time we fail to reconnect after a successful connection is lost. This change applies both to the GmsRtViewSqlDs connections and to the Historian connection to the RTVHISTORY database.

Distribution

23220: jetty updated to 9.4.14

The version of Jetty used by EM to host web applications has been upgraded to Jetty version 9.4.14. In addition, the temp directory used by Jetty has been changed. Previously, the java.io.tmpdir directory was used, but files were not always removed from this directory. Now, Jetty creates a temp sub-directory in the directory where the data server is running. This temp directory is deleted on shutdown.

Scripts

18806: Support secure JMX with start and stop and status scripts

The start_rtv, stop_rtv and status_rtv scripts have been enhanced so as to work with RTView servers whose JMX ports have been secured either with username and password or with SSL. You give the scripts the necessary information about credentials and they manage authentication with the server. In the first case the necessary information is username and password. In the second case it is client KeyStore and TrustStore locations and their corresponding passwords. This information can be given to the scripts in two ways: via command-line arguments, and via properties placed in any property file used by the server. Username and password may be specified via command-line arguments as follows: -jmxuser:... -jmxpass:... Or by properties as follows: sl.rtview.jmxremote.username=... sl.rtview.jmxremote.password=.... Client KeyStore and TrustStore files and passwords may be specified as follows: -sslkeystore:... -sslkeystorepass:... -ssltruststore:... -ssltruststorepass:... Or by properties as follows: sl.rtview.ssl.client.keyStore=... sl.rtview.ssl.client.keyStorePassword=... sl.rtview.ssl.client.trustStore=... sl.rtview.ssl.client.trustStorePassword=.... You may encrypt the passwords in your properties files by using the command-line tool "encode_string", for example encode_string encoder2 password This will give you an encrypted value for "password" you may use in your properties.

23204: update_wars scripts now support command-line arguments

The update_wars scripts in all deliverables have been improved as follows: 1. The name, host, and portprefix are declared in variables at the top of the script for easy editing. 2. Those three variables may be passed into the scripts on the command-line, e.g. update_wars.sh my-appname my-hostname 99 3. You may use "?" or "help" to get a usage message, e.g. > update_wars.sh help Usage: update_wars.sh [appname [host [portprefix]]] Defaults: rtview-bwmon localhost 33 4. You may edit other variables at the stop of the scripts to set properties for HA (high-availability). Set HA_HOST to the hostname of the backup data server. Set HA_DISPLAYHOST to the hostname of the backup display server. Set HA_FAILBACK to true to automatically reconnect to the primary display server.

23320: Can now run stop_rtv in two deployments simultaneously

If you tried to run stop_rtv simultaneously in two different distributions (e.g. RTViewCentral and RTViewDataServer) you might get the error "The process cannot access the file because it is being used by another process." This has been corrected.

23416: JMX port conflicts reported by start scripts

The start_rtv scripts, when checking for port conflicts before starting a server, will now detect if a port conflict is caused by another RTView server, and will identify that server by its RTVAPM_HOME. For example: ...start_rtv.bat: another dataserver running with JMX port 3268 under C:\rtview\RTViewDataServer\rtvapm If the port conflict is caused by a non-RTView process the message will be like this: ...start_rtv.bat: JMX port 3268 in use by PID 1234 In either case the script will include this advice: Warning: server not started, port conflict To avoid port conflicts, run your start script with the -portprefix: command line argument to change the first 2 digits of all your server ports. To persist these port changes, change the port prefix in the Configuration Application or use the -saveportprefix: command line argument. See the documentation for more information.

23431: Start scripts no longer fail on windows if there are spaces in the install directory

The scripts used to start and stop rtview servers on Windows would fail if the product were installed in a directory with spaces in the name (e.g. "test directory"). This has been fixed.

23467: Fixed portprefix command line bugs

Two problems with the -portprefix option have been corrected. It will now emit correct args for the single-solution monitoring products, and it will not incorrectly emit args for central servers.

23482: start_rtv with -portprefix now changes database port

In an RTViewDataServer distribution with database enabled, if the servers were started with "-portprefix:xx" the new port number was not passed to the database. This has been corrected.

Solution Package

Amazon CloudWatch

23054: Corrected property names in sample.properties and add defaults to conf

The sample.properties file for the Solution Package for Amazon Web Services contained typos in the connection properties. This has been fixed. Default values for initialHistory and autoDiscoveryPeriod have also been added to avoid errors like so: 2018-06-18 10:36:10,303 INFO pool-2-thread-1 - [rtview] AwsCloudWatchDs: ERROR: updateDataObject: discovery period not set in Options

Apache Kafka

22895: History Table Names shortened to stay under 30-character limit

The Kafka monitor history table names have been shortened to 30 characters to conform to database requirements

23290: Now fetching historical data correctly for tabs under All Brokers Metrics Table

The Kafka All Brokers Table has three tabs - Timers, Histograms, Meters - each of which has a trend graph. Those graphs were not fetching data from the database as needed (Extend With SQL feature). This has been fixed.

23395: Added JVM metrics to Broker, Producer, Consumer caches, displays, alerts, and key metrics

------------------------------------ The following alerts have been added: ------------------------------------ KafkaBrokerCpuPercentHigh KafkaConsumerCpuPercentHigh KafkaProducerCpuPercentHigh Executes a single warning alert and a single alarm alert if the percent of CPU used exceeds the specified threshold. Index Type: Per KafkaBroker / KafkaConsumer / KafkaProducer Metric: CpuPercent KafkaBrokerMemoryUsedPercentHigh KafkaConsumerMemoryUsedPercentHigh KafkaProducerMemoryUsedPercentHigh Executes a single warning alert and a single alarm alert if the percent of memory used exceeds the specified threshold. Index Type: Per KafkaBroker / KafkaConsumer / KafkaProducer Metric: MemoryUsedPercent ----------------------------------------- The following key metrics have been added: ----------------------------------------- CI Type Cache Selector Metric / Alert KAFKA-BROKER KafkaServerJvm CpuPercent CpuPercent / KafkaBrokerCpuPercentHigh KAFKA-BROKER KafkaServerJvm MemoryUsedPercent MemoryUsedPercent / KafkaBrokerMemoryUsedPercentHigh KAFKA-CONSUMER KafkaConsumer CpuPercent CpuPercent / KafkaConsumerCpuPercentHigh KAFKA-CONSUMER KafkaConsumer MemoryUsedPercent MemoryUsedPercent / KafkaConsumerMemoryUsedPercentHigh KAFKA-PRODUCER KafkaProducer CpuPercent CpuPercent / KafkaProducerCpuPercentHigh KAFKA-PRODUCER KafkaProducer MemoryUsedPercent MemoryUsedPercent / KafkaProducerMemoryUsedPercent ----------------------------------------- The following displays have been enhanced: ----------------------------------------- All Brokers Table, All Consumers Table, All Producers Table - added columns "CPU %" and "Mem Used %" All Brokers Heatmap, All Consumers Heatmap, All Producers Heatmap - added "CPU %" and "Mem Used %" to mouseover tooltip. ----- Note ----- The key metric KafkaBrokerNetProcAvgIdlePct has been removed.

23413: Removed duplicate alert KafkaBrokerReqHdlrAvgIdlePctLow

The alert KafkaBrokerReqHdlrAvgIdlePctLow was a duplicate of the alert KafkaBrokerNetProcAvgIdlePctLow and has been removed.

23434: Kafka Cluster alerts are no longer misconfigured

In RTView EM the Kafka Cluster alerts were not configured so that the "Go To CI" button in the Alert Table would go to the corresponding Kafka Cluster summary page. This has been corrected.

23539: Kafka 12.2 classpath support

In previous releases, connecting to Kafka 12.1 caused the RTView DataServer to throw an exception and fail to start Jetty due to a mismatch of the versions of Jetty included with Kafka and RTView. This has been fixed.

Host Infrastructure

23048: Fixed incorrect info in hostbase sample.properties file

This Host Solution Package property is obsolete: collector.sl.rtview.cache.config=host_cache_source_agent_v1.1.rtv $hostAgentDomain:myDomain For SL Host agents, the domain name is set in the agent's agent.properties file.

23683: Corrections/additions to rtvHostAgent

The default port that the Host Agent sends to has been changed from 3972 to 3272, the new default listen port for RTView DataServers. For user convenience, information about optional command line arguments, that can override some properties in agent.properties, has been added to the README.txt and agent.properties comments.

IBM Websphere Application Server

23181: Removed unused properties from sample.properties

The following unused properties have been removed from the Solution Package for IBM Websphere sample properties files: sl.rtview.sub=$WAS_SERVERINFO_TABLE:'' sl.rtview.sub=$WAS_SYSTEMMETRICS_TABLE:'' sl.rtview.sub=$WAS_JVMRUNTIME_TABLE:'' sl.rtview.sub=$WAS_SESSIONTOTALS_BYSERVER_TABLE:''

MongoDB

23269: Show correct replica set member state

Previously, under certain circumstances, the replica set member state ("DesignationInSet") for an instance would not be shown correctly. This is no longer the case. Possible replica set member states are described here: https://docs.mongodb.com/manual/reference/replica-states/ e.g. PRIMARY, SECONDARY, ARBITER

Node.js

23278: Corrected README.txt info on host paramater

There were several errors in the readme.txt file for the rtview-nodemon agent regarding the use of the host parameter which have now been corrected.

23477: Updated versions of dependencies used to build nodemon agent

When installed, the rtview-nodemon agent will now use updated versions of pidusage and monitor-plugin-process.

Oracle Database

23324: Added Disk Usage metrics to history

The disk utilization metrics from OraDatabaseDiskUsage cache have been added to history.

Solace

23258: Improved drill down behavior of Solace Neighbors topology diagram

The CSPF Neighbors Topology diagram has been fixed and now allows drill down to the CSPF Neighbor Table filtered by the selected Message Router when one double clicks on a Message Router with neighbors. Otherwise, the CSPF Neighbor table will show all neighbors from all Message Routers.

23536: Data queries improved to work with heavily loaded router

The RTView Solace Data Source has been improved to incorporate paging on all high volume SEMP requests. These improved queries are for Clients, Endpoints (Queues and Topics) and VPNs.

23630: Bind-requests removed from SolClients cache

The metric bind-requests has been removed from the SolClients cache and accordingly from the Clients Table and Client Summary.

23690: Brokers Table no longer empty when collecting data from cloud brokers

The VPN information from the Solace Cloud Brokers has been raised to the Brokers displays to avoid misleading empty displays due to the limited characteristics of their functionality.

23693: New Solace Event Module

The Solace Monitor has been enhanced to include the Solace Event Module which listens for the syslog messages that are generated by the Solace brokers. It contains meta data for parsing the syslog messages into a readable form and also for triggering alerts based on the syslog events. The parsed syslog messages are forwarded to the RTViewDataServer’s SolEventModuleEvents cache, and the alerts are forwarded to the RTViewDataServer’s SolEventModuleAlert cache. The Solace Event Module is executed as a subprocess of the data server. If you are licensed to run the Solace Event Module, you can enable it by adding the -soleventmodule command line option to the dataserver line of your rtvservers.dat file. See the documentation for more information on setup and configuration of the Solace Event Module.


23722: New Solace Sparse Message Spool Files alert

A new alert SolSparseMessageSpoolFile, for detecting the existence of sparse message spool files, has been implemented. This alert will be triggered when the Disk Space Utilization is above 30% and the ratio of Disk Space in MB and Spool Usage in MB is above 3. Look at the Recommended Actions Section from https://docs.solace.com/Configuring-and-Managing/Mon-Mgmt-Disk-Con.htm for details on how to solve this situation.

23729: Support for Syslog messages changed

Solace solution package support for Syslog messages has changed. The previously supported Syslog connections and displays are no longer available. Solace Syslog messages are now handled by the Solace Event Module. The new Syslog display is availabe in the RTViewSolaceMonitor and in the beta Enterprise Edition monitor. It is not available with Enterprise Monitor (thin client). Users with existing Solace projects from previous releases that contain Syslog connections will need to migrate their Syslog connection information to the Solace Event Module.

23766: New metrics to calculate SolSparseMessageSpoolFile alert

The Disk Space Usage in MB and the Spool Usage in MB metrics have been added to the SolApplianceMessageSpool cache. These metrics will be used to calculate the condition for triggering the SolSparseMessageSpoolFile alert.

TIBCO ActiveMatrix

23474: Included the 'Runtime State' in the AMX 'All Service Nodes Table' display

The column 'Runtime State' has been added to the AMX 'All Service Nodes Table' display

23497: Changed cache retention policy for AMX nodes to mark and delete

The AMX Node cache has been set up to mark and delete expired nodes. The time to expire and delete nodes is controlled by two new variables: $amxNodeExpirationTime $amxNodeExpirationTimeForDelete

23636: CI Type AMX-NODE no longer has wrong index columns

The amxmon alert AmxNodeNotRunning was displayed in the Alerts table with incorrect indexes in the CI column. There should be three indexes, HostName;AMX Host;Node, but only HostName;AMX Host were displayed.

TIBCO BusinessWorks

22998: Alert descriptions now include units for CPU/memory alerts for BW/BW6

The descriptions for the following alerts have been changed to indicate the corresponding metric is "% of total": BwEngineCpuUsedHigh BwEngineMemUsedHigh BwServerCpuUsedHigh BwServerMemUsedHigh Bw6AppNodeCpuUsedHigh Bw6AppNodeMemUsedHigh The descriptions for the following alert has been changed to indicate the corresponding metric is "MB" BwServerFreeMemLow

23263: New "BW Process Hung" alerts for BW and BW6

The alert BwProcessHung has been added to the BW5 monitor and the alert Bw6ProcessHung to the BW monitor. This alert is triggered for a given process when the delta elapsed time is greater than zero but the delta elapsed time is zero.

23286: Updated OSGi Plugin

The BW Monitor OSGi Plugin has been updated to version 4.2. Please see documentation for improved installation instructions.

23305: Application summary trends now show data in sender-receiver deployment

In a sender-receiver deployment, when viewing the displays on the receiver side, the trends in the Application Summary display will be blank. This has been corrected.

23339: Improved error reporting in dataserver log when Hawk not available

RTView dataservers configured for BusinessWorks will write warning messages to the log if Hawk is not installed and configured in the environment. The number of messages has been reduced.

23405: ActiveMatrix removed from BusinessWorks names

TIBCO has changed the name of TIBCO ActiveMatrix BusinessWorks to TIBCO BusinessWorks. RTView references have been updated accordingly.

23530: OSGi plugin now allows appnodes to be named with container ID or env var substitution

The RTView BW Monitor OSGi Plugin has been enhanced as follows: (1) If you do not provide, via properties, a specific name for the appnode running in the container, the Docker container ID or PCF container GUID will be used for the appnode name. (2) If you do provide specific names for domain, appspace, or appnode, you can include variables from the container environment in the names, by bracketing the environment variable name with '%'. For example, if you wanted to name your PCF container appnodes "instance-1", "instance-2" etc. then you could supply an appnode name such as: sl.rtview.bw.appnode=instance-%CF_INSTANCE_INDEX% (3) The "Deployment" column in the Application and Appnode tables will now say "PCF" or "Docker" instead of just "Container".

TIBCO EMS

19248: Producer and consumer tables no longer show incorrect "unknown" type

In previous releases, the Consumer and Producer tables listed Unknown for the destinationType column if the type was not a topic. This has been fixed. They now list the following values: Topic - if getDestinationType() returns DestinationInfo.TOPIC_TYPE Queue - if getDestinationType() returns DestinationInfo.QUEUE_TYPE Topic or Queue - if getDestinationType() returns DestinationInfo.ALL_TYPE Unknown(typeVal) - if getDestinationType() returns any other value

22485: Value of max # of history rows for EmsQueuesExt and EmsTopicsExt updated

The cache attribute max number of history rows has been updated to use the substitution emsMaxNumberOfHistoryRowsLarge in EmsQueueExt and EmsTopicsExt caches, which is set by default to 200,000 rows.

Version 4.2.0 Release Notes

Configuration

22451: Solution Package for TIBCO ActiveMatrix added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for TIBCO ActiveMatrix.

22826: Solution Package for Amazon Web Services added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for Amazon Web Services.

22828: Solution Package for IBM DB2 added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for IBM DB2.

22829: Solution Package for Docker added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for Docker.

22830: Solution Package for RTView Host Agent added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for RTView Host Agent.

22832: Solution Package for MongoDB added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for MongoDB.

22834: Solution Package for Node.js added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for Node.js .

22835: Solution Package for Oracle Database added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for Oracle Database.

22838: Solution Package for Oracle Web Logic added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for Oracle Web Logic.

22839: Solution Package for IBM WebSphere added to Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for IBM WebSphere.

23135: Fixed bug with removing vpn from Solace connection

In the previous release, it was not possible to remove all Solace vpn's from the connections dialog. This has been fixed.

23140: New Connection icon no longer disappears from Configuration Application after toggling tabs on SYSLOG connections.

The Solace Add Syslog Connection ('+') button now always appears as expected.

23187: IE 11 Compatibility mode is now recognized as not supported

IE 11 Compatibility mode is now flagged as being unsupported for the Configuration Application.

JBoss

22976: Wildfly documented in sample.properties and added to Configuration Application

The connection properties for WildFly have been added to the sample.properties and included in the Configuration Application.

Data Server

23210: Improved error reporting for start_rtv.bat/sh scripts

The start_rtv scripts have been enhanced to report possible port conflicts before trying to start a server, and to report if a server is not actually started due to some other cause (e.g. expired license key). if a server's data and/or JMX port is already in use by another process, start_rtv will report e.g.: dataserver: JMX port xxx in use by PID yyy dataserver: Data port xxx in use by PID yyy If the server fails to start for some other reason, start_rtv will report e.g.: dataserver: Executing rundata -propfilter:receiver dataserver: ... was not started, check log file.

Distribution

23077: RTView DataServer for Kafka port prefix and server name default updated

The following changes have been made to the default project in the RTView DataServer for Kafka deliverable: - Default port prefix is now 32 - Short-form server name has been changed from KAFKAMON to DataServerKafka - Long-form server name has been changed from Apache Kafka Monitor to RTView DataServer for Kafka - project directory name has been changed from projects\sample-server to projects\rtview-server

23198: Sample project directory renamed to rtview-server

Two naming changes have been made to the RTViewDataServer family of deliverables: The sample-server project for the RTViewDataServer* deliverables and the sample-collector project of the RTViewDataCollector deliverable have been renamed to "rtview-server". The RTViewDataCollector_x.zip deliverable has been renamed to RTViewDataServerSP_x.zip, to reflect that it contains all solution packages.

23223: RTView DataServer for TIBCO - new deliverable

A new RTView(R) DataServer variant has been added to the RTView monitoring lineup. It is intended for use by those who wish to monitor TIBCO's middleware products. Files: RTViewDataServerTIBCO_x.zip RTViewDataCollectorTIBCO_x.zip RTView(R) DataServer for TIBCO includes Solution Packages for: - TIBCO BusinessWorks 5 - TIBCO BusinessWorks 6 - TIBCO Enterprise Message Service - TIBCO Adapters - TIBCO ActiveSpaces (2.x) - TIBCO Hawk - TIBCO FTL - TIBCO ActiveMatrix - RTView Management

23228: RTView DataServer for Solace - new deliverable

A new RTView(R) DataServer variant has been added to the RTView monitoring lineup. It is intended for use by those who wish to monitor Solace appliances. Files: RTViewDataServerSolace_x.zip RTViewDataCollectorSolace_x.zip RTView(R) DataServer for Solace includes Solution Packages for: - Solace - Syslog

General

22859: Spurious file no longer appears in cache subdirectory

Previously, under certain circumstances a spurious file was generated in the cache subdirectory when using the datacache mechanism. This is no longer the case.

23064: Configuration Application now displaying proper warning after failing to write property.

An alert dialog has been added to display any warning msgs that follow a successful save.

23168: Extend With SQL previously not working for trends in some displays

RTView trend displays will automatically retrieve data from a database if available and if required by the time range requested in the display. This feature was not working correctly for a number of displays. This has been corrected.


RTView Core Functionality

Data Historian

22195: RTView Historian now uses PreparedStatements

The Historian now uses PreparedStatements for repeated SQL Queries against the historian database - For raw data insert - For data compaction - For retention deletion Previously the historian used literal SQL queries with unique timestamps.

Data Server

23211: Message now shown in dataserver console when Java is not available.

The scripts which start servers have been improved to give a clear indication if the java command is not available. If java(.exe) is not found on the PATH but JAVA_HOME is defined, the scripts will add JAVA_HOME/bin to the PATH and try again. If JAVA_HOME is not defined or java(.exe) cannot be found in JAVA_HOME, the scripts will fail with the error "java not found on PATH and JAVA_HOME not defined or not valid." On Windows this will be followed by a pause and "Press any key to continue".

Scripts

23032: New validate_install.bat/sh script

A new script has been added to the RTView distributions to validate the RTView installation. It will verify the environment and directory structure and on Unix it will also fix file permissions and file formats as required. The script is validate_install.bat/sh. It is used in a command prompt or terminal window by changing to the toplevel/rtvapm directory and typing "validate_install(.sh)". On Unix, if file permissions or formats are fixed, the script will print a count of the files fixed. Additionally, if invoked with the argument "-v" (verbose) it will list the names of the files fixed. Examples: Validating installation in /opt/rtview/RTViewSolaceMonitor ... Java installation correct. ... rtvapm installation correct. ... file permissions correct. ... file formats correct. Validating installation in C:\rtview\RTViewDataServerKafka ... Java installation correct. ... rtvapm installation correct.

23219: hsqldb updated to 1.8.1

The version of hsqldb included has been updated to 1.8.1. Previously when the hsqldb database was shut down with stop_rtv.bat/sh, its console window would show multiple messages of the form Exception in thread "HSQLDB Connection @5757c327" java.lang.NullPointerException This has been corrected. Note that on Windows, when shutting down the database you may see messages of the form "database alias=alertdefs does not exist" in the hsqldb console window. These messages may be ignored.

Solution Package

Apache Kafka

23184: Custom Kafka DS incorrectly parses some command output

The Solution Package for Kafka makes use of the output from the kafka-consumer-groups.sh command. In the case where a consumer is not assigned any partitions it will appear in the command output with dashes for the partition-related fields, e.g. TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG CONSUMER-ID HOST CLIENT-ID - - - - consumer5-67bd6d45-0f4c-450e-a969-c16e565808b4 /192.168.200.226 consumer5 Lines of this form were not correctly handled by the dataserver, resulting in error messages like: [rtview] getLagTable: java.lang.NumberFormatException: For input string: "-" This has been corrected.

IBM DB2 Database

21571: Minor typo on display for IBM DB2 Database display

A typo in the IBM DB2 Database displays has been fixed.

IBM Websphere Application Server

22991: WSM data server no longer crashes if classpath not set

In previous releases, the Solution Package for IBM WebSphere crashed if the classpath did not contain the WebSphere jars. This has been fixed.

23182: Cache configuration parameters now available in Config UI

All caches from the RTView IBM WebSphere Monitor have been enhanced to support parametrizion of condensing and cache size attributes. This enhancement will be taken into account for the RTView Configuration Admin Tool to allow customers to make changes in these cache attributes.

TIBCO BusinessWorks

22503: SQL statements for BW tables optimized

The schemas for the BW historian tables listed below (found under rtvapm/bwmon/dbconfig) have been optimized to reflect common customer scenarios: BW_ENGINES BW_PROCESSES BW_PROCESS_TOTALS BW_ACTIVITIES BW_ACTIVITY_TOTALS 1. "MicroAgentName" VARCHAR(100) increased to "MicroAgentName" VARCHAR(160) since the engine name often exceeds 100 chars. NOTE: This change does not apply to Sybase, due to Sybase not supporting >100 characters for an index column. 2. "MicroAgentInstance" VARCHAR(255) decreased to "MicroAgentInstance" VARCHAR(10) because this column refers to the instance # which rarely exceeds 1000. This will save some space in the database. Users with existing tables do not need to update their tables.

23167: BwProcessCreatedRateLow now alerts corrected

The BwProcessCreatedRateLow alert was incorrectly configured so that it acted like a "High" rather than a "Low" alert. In other words, the alert would trigger if the Created Rate value was greater than the threshold rather than less than. This has been corrected.

Version 4.1.0 Release Notes

Configuration

22559: Run all sample projects as receivers

The solution package data servers for all sample projects are now run as receivers. This means that all data servers open an RtvAgent port to listen for collector/sender data.

22574: Added sender target to all sample projects

Enterprise RTView has been enhanced to include sender targets in the configuration for all sample solution package projects. The sender target is only used when the solution package data server is run as a sender.

22583: Solution Package for Apache Kafka added to configuration application

The RTView Configuration Application has been enhanced to include the Solution Package for Apache Kafka.

22606: Improved user notification

When one or more solution packages are added to a data server connection, and the project type is a configclient, a message will be displayed instructing the user to update the data server connections list with the new solution package(s).

22747: Solution Package for Solace added to the Configuration Application

The RTView Configuration Application has been enhanced to include the Solution Package for Solace Message Router.

22831: Solution Package for Redhat JBoss added to configuration application

The RTView Configuration Application has been enhanced to include the Solution Package for Redhat JBoss.

22833: Solution Package for IBM MQ added to configuration application

The RTView Configuration Application has been enhanced to include the Solution Package for IBM Websphere MQ.

22847: Enable Checkbox should be enabled for default diagram generator and metric explorer DB

The enabled checkbox should always appear ungrayed for Diagram Generator and Metric Explorer DB connections

22891: Configuration Application now uses basic authentication instead of digest

In the previous release, the Configuration Application used Digest authentication which cause occasional problems with the login dialog coming up repeatedly when single sign on was not enabled in the app server. It has been modified to use BASIC authentication instead which does not require single sign on. Basic authentication sends the username and password as a base64-encoded string. This a public encoding scheme and is therefore not secure unless https is used. If you are concerned about keeping the login credentials of the Configuration Application secure, you should deploy it using https which will secure all data including the login credentials.

22892: New Restart Data Server option added to configuration application

The RTView Configuration Application has been enhanced with a button to restart a Solution Package data server. This button is available whenever there are unapplied changes. To restart a solution package data server: 1. Make some configuration changes and click SAVE to save them. 2. A Restart button will appear in the top right corner of the page. When you click the Restart button, you will be taken back to the top level page. The data server for the solution package project will exit, then start back up with the changes applied. The button is also available on the top level page if you want to restart your data server later. There is a delay of 10 seconds between the shutdown of the server and the restart in order to allow system resources to be released by the exising process. It may take several more seconds before Configuration Application and other clients reconnect to the data server. Note that this process only restarts the data server. Settings for the display server or historian processes will not be applied until those processes are restarted using the scripts. They cannot be restarted from the Configuration Application.

Deployment

22056: Added https support to the servlet container

The html server feature of RTView Enterprise Monitor has been enhanced to support https. This is configured in the Configuration Application Data Server page in the HTML Server section. There are 4 fields for configuring https: - Use Https - Set to true to use https - Keystore File - Set to the key store file name (including path) that contains the certificate for your domain. This is required to use https. - Keystore Password - Set to the password for the keystore. This field is optional. - Key Manager Password - Set to the password for the key manager. This field is optional.

22173: New cache viewer added to servlet container

RTView Enteprise Monitor html server feature has been enhanced to include a cache viewer. This is useful for verifying cache contents without the need for setting up the thin client. For any data server that has the html server enabled, navigate to the following url to bring up the cache viewer: http://localhost:3270/common Replacing the 32 with the port prefix used by your data server. Select a cache from the top table to show the cache contents in the lower table.

Distribution

22850: RTViewDataServer available on Red Hat OpenShift Container Platform

The RTView DataServer deliverable has been made available on Red Hat's OpenShift Container Platform, starting with version 4.0.0. The URL for the image is: registry.connect.redhat.com/slcorp/rtview-dataserver More information is available on RedHat's site at: https://access.redhat.com/containers/?tab=overview#/registry.connect.redhat.com/slcorp/rtview-dataserver

RTView Core Functionality

Data Sources

22840: Automatically detect when JSON configured standby EMS Servers become active

The EMS Admin data adapter had an issue with fault-tolerant server pairs configured via JSON, such that the data adapter would not detect when the inactive server became active. This has been corrected.

Distribution

22853: rtvpost servlet added to Jetty

RTView Enteprise Monitor html server feature has been enhanced to include the %RTV_HOME%\servlets\rtvpost\rtvpost.war servlet in Jetty.

Scripts

22888: Start script no longer fails on Solaris

On Solaris 10/11 using RTViewEnterpriseMonitor, starting the central database might give the error "expr: string too long". This has been corrected.

Solution Package

Apache Kafka

22731: Add summary data to kafka caches.

The column "ZK Disconnect Rate" has been added to the All Brokers table. This is the mean rate of Zookeeper disconnects per broker, in seconds. Two caches have been added: KafkaServerZookeeper contains per-broker counts of zookeeper disconnects and expirations KafkaCluster contains server and client counts and specific metrics summarized at the cluster level.

22808: Added missing database definitions

Two tables have been added to the SQL schemas under kafkamon\dbconfig. These caches were added in the previous release as task 22094: KAFKA_TOPIC_PARTITION KAFKA_TOPIC_TOTALS_SERVER

22852: Simplified connection properties

The instructions for kafkamon connections included the following section, which is now obsolete and should be disregarded: ## The aggregator dataserver (if it is not also a collector) will not include any of the above ## Kafka configuration, but it must include a topic property (without a bootstrap-server) for ## the cluster, e.g. ## ## receiver.sl.rtview.cache.config=kafka_topic_partition_cache_source.rtv $kafkaClusterName:prodCluster

Solace

22721: Support Solace Cloud Edition

Support for Solace Cloud Edition has been added. Connections can be defined using the RTView Configuration Application.

22787: Wrong metric name in renaming function will generate a wrong zero value

A typo on the name of the spool message size in MB metric for topic endpoints was preventing the correct value to be collected. This typo has been fixed and now the spool message size in MB for topic endpoints is collected properly. Also, several typos on client bridge received bytes metrics have been removed which prevented the correct values to be stored in the SolBridges cache. Now the client received total, data, persistent, non persistent, and direct bytes are stored properly into the cache.

22789: Collect SEMP version automatically to avoid configuration problems

As of Solace VMR version 8.7+ and Solace Appliance version 8.3+, it is no longer required to include a SEMP version string in connection properties. See https://docs.solace.com/SEMP/Using-Legacy-SEMP.htm. For earlier versions of Solace VMR and Solace Appliance, the SEMP version string should be entered in connection properties. Not using the proper SEMP version string would impair the collection of monitoring metrics. See RTView Solace Solution Package documentation for a description to determine the SEMP version string in your Solace Message Router and to enter this value in your connection properties.

TIBCO ActiveMatrix

22707: New AmxNodeNotRunning alert

The following alert has been added to amxmon: AmxNodeNotRunning. It triggers if the runtime state of the node is not RUNNING.

TIBCO BusinessWorks

22695: BWAgentPlugin can now get max heap size from java.extended.properties if found

The Hawk microagent BWAgentPlugin reads the BW engine deployment files to determine the Java max heap allocation. Usually this is given by the property "java.heap.max" in the engine's .tra file, but it can also be given by the property "java.extended.properties." The microagent has been enhanced to look for the second property if the first is not found.

22884: bw6mon application table appnode counts and timestamps corrected

In a situation where there a number of applications with no process execution in any appnode, bw6mon would report incorrectly the number of appnodes per application, and would report the timestamp as zero (blank). These issues have been corrected.

22885: Alert LED indicators now navigate to a page with detailed alert information

The summary pages have been enhanced with new alert displays. The Application, AppNode, and Container summary pages have alert indicators whose color indicates whether there are current alerts for the displayed item, in the categories relevant to it. Clicking an indicator will now bring up a table listing the alerts in each category. To close this table and restore the previous display, click the Close button. Clicking a row of the alert table will bring up a detail window for the selected alert.

22886: bw6mon appnode summary page heatmap tooltip correction

The bw appnode summary page has a heatmap of the processes of the appnode. The heatmap cell's tooltip showed an incorrect set of columns. This has been fixed.

22889: bw6mon now correctly displays appnodes if containers are displayed first

In the BW monitor displays, if a container display was selected followed by an appnode display, the appnode display would not show data correctly. This has been fixed.

22898: BW6 Application Heatmap and AppNode Heatmap bug fixes

In the case of no processes execution in the lifetime of an application, the application heatmap would not display the application correctly. This has been corrected. The appnode heatmap was not correctly connected to memory usage as indicated. This has been corrected.

Version 4.0.0 Release Notes

22415: New RTViewDataCollector deliverable

A new deliverable called RTViewDataCollector has been added to the RTView lineup. It is a reduced-size subset of functionality contained in the larger RTView Enterprise Monitor deliverables - meant to be a convenient way to configure remote sender DataServers. It supports all current Solution Packages. It contains a single sample project that can be configured and duplicated as needed, and configured using the new browser-based Config UI. By default the RTViewDataServerSP is configured to be used as a sender, forwarding data to a receiver DataServer. Instructions for installation and use of the RTViewDataCollector are included in a README file in the RTViewDataCollector deliverable.

22416: New RTViewDataServerSP deliverable

A new deliverable called RTViewDataServerSP has been added to the RTView lineup. It is a reduced-size subset of the functionality contained in the larger RTView Enterprise Monitor deliverables - meant to be a convenient way to configure remote DataServers when the central EM installation location is not the optimal location for Solution Package data collection. It supports all current Solution Packages. It can also be used to collect real-time data to be used by RTView Cloud displays. It contains a single sample project that can be configured and duplicated as needed, and configured using the new browser-based Config UI. By default the RTViewDataServerSP is configured to be used as a receiver, listening for additional data being forwarded by sender DataServers. Users who wish to configure sender DataServer's can refer to the new RTViewDataCollector deliverable. Instructions for installation and use of the RTViewDataServerSP are included in a README file in the RTViewDataServerSP deliverable.

22417: New RTViewDataServer deliverable

A new deliverable called RTViewDataServer has been added to the RTView lineup. It is intended primarily for sending real-time data to RTView Cloud displays. Users who wish to leverage existing RTVIew Enterprise Monitor Solution Packages should use the RTViewDataServerSP deliverable. Instructions for installation and use of the RTViewDataServer are included in a README file in the RTViewDataServer deliverable.

Configuration

22192: Replace emcommon with project-common

The emsample\conf\emcommon.properties file has been replaced with project-common.properties which is editable by the configuration ui. Users upgrading from previous releases can continue to use their existing emcommon.properties file by copying it into the emsample\conf directory. It will still be read by all emsample servers.

22264: New Configuration application added

RTView EM and its specialized Monitors have been enhanced to support a configuration application. See the documentation for more information.

22284: add rtvadmin to make_war and update_war scripts

The new rtvadmin war file, which runs the Config UI, has been added to the make_war and update_war scripts

22288: Removed projects\sample and webapps subdirectories from rtvapm\sp directories

In previous releases, each solution package directory under RTVAPM_HOME had projects, ALERTDEFS, HISTORY and webapps subdirectories. Those subdirectories have been removed. The RTVAPM_HOME\projects\emsample\servers directory has sample project directories for all solution packages that can be used instead.

22290: remove server level properties from sp\conf\rtvapm.sp.properties files

In previous releases, each solution package defined its own ports, sender target and server identification properties. These properties have been removed from the solution package properties and should be defined in the project properties instead. The sample projects included in EM have been updated to include these properties which have been set to the same values that they inherited from the solution package properties in previous releases. New projects that do not define these properties will use the following defaults: # data server ports and process identifiers dataserver.sl.rtview.dataserver.port=3278 dataserver.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3268 dataserver.sl.rtview.cmd_line=-proctag:RTVAPM.RtvDataServer sl.rtview.alert.persistAlertEngineName=RTVAPM sl.rtview.sub=$domainName:SL-RTVAPM-1 # data client dataclient.sl.rtview.dataserver=//localhost:3278 # display server ports and process identifier displayserver.sl.rtview.displayserver.port=3279 displayserver.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3269 displayserver.sl.rtview.cmd_line=-proctag:RTVAPM.RtvDisplayServer # historian port and identifier historian.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3267 historian.sl.rtview.cmd_line=-proctag:RTVAPM.RtvHistorian # database port database.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3261 # sender ports,target and identifier sender.sl.rtview.dataserver.port=3276 sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3266 sender.sl.rtview.sub=$rtvAgentName:MyMachineName # receiver port receiver.sl.rtview.rtvagent.port=3272 # http port collector.sl.rtview.rtvhttp.port=3275 Upward compatibility support is included for projects created previous to EM 4.0. In EM 4.0, the rtview.properties files in all sample projects were replaced with project.properties files. Any project with an rtview.properties file is recognized as a project created with a previous release. In that case, RTView will automatically read in the old ports, sender target and server identification properties for all solution packages in the rtview.properties file. Therefore, projects created with previous of EM will continue to run with no modifications. It is recommended, but not required that existing custom solution packages make the following changes. These changes are needed in order to be compatibe with the new Configuration Application. Custom solution packages will continue to work as before without these changes, but data servers containing custom solution packages without these changes should not be configured via the Configuration Application: 1. Move the following server level properties from conf\rtvapm.sp.properties to conf\rtvapm.sp.compat.properties: - all ports - all proctag properties - sender.sl.rtview.sub=$rtvAgentName - sl.rtview.alert.persistAlertEngineName - sl.rtview.sub=$domainName 2. Put the custom solution package directory under RTVAPM_HOME or RTVAPM_USER_HOME as follows: - if under RTVAPM_HOME, the solution package name must end in "mon" for the Configuration Application to detect it This will add the custom solution package to the list of available solution packages in the Configuration Application. 3. add rtvadmin\sp.meta.json under lib with the following - the Configuration Application will use this as the display name for your solution package: { "displayname": "The Display Name for your SP" } 4. copy src\rtfiles\rtvconfig.sp.xml to lib\rtvadmin so the Configuration Application can read its CI Types.

22298: New portprefix command line option

The RTView launcher has been enhanced with options for changing all the port numbers used by a package. Port numbers are assigned to a package using a package prefix and a two-digit suffix specific to the port. A complete list of suffixes is appended. This enhancement allows you to change the port number prefix for the server being launched. The change will apply only to that launch unless you also specify -saveportprefix, in which case the new prefix and port numbers will be saved to project.properties.json and project.properties. -portprefix:X Change all relevant ports to use prefix X by appending arguments to the command line that will be used to launch the server. -saveportprefix Used with -portprefix, save project.properties and project.properties.json. If the project does not contain those files, create them and add project.properties to the end of the command line. If the project does contain those files modify and save them. Note if you start a server with -portprefix, you may use the status_rtv and stop_rtv commands with it only if you repeat the -portprefix option with those commmands.

22474: PROPDB and RTVCONFIG databases disabled

The following database connections are now disabled by default in emsample: PROPDB RTVCONFIG These databases are not used in the standard emsample project. Customer with existing emsample projects that do use those databases should continue to defined them in their central.properties file as before.

22531: Added button to displays to access the config ui

The EM Config UI may be accessed via a "gear" icon which will appear at the right end of the title bar. It is visible only in the thin client when the role is admin.

22579: KAFKAMON server requires rtvmgr package

The emsample project configuration for kafkamon has been modified to include the rtvmgr package, which is required for kafkamon operation.

TIBCO ActiveMatrix

21862: BW6 displays and caches are now enabled by default

The bwmon and bw6mon packages are now both enabled by default within emsample, with the possibility that only one package is actually active. The amxmon package, which uses some bw caches, is still disabled by default. Instructions for enabling it can be found under rtvapm/amxmon/README.txt

Deployment

22125: New html server available for Data Servers

RTView Enterprise Monitor has been enhanced to embed Eclipse Jetty to support running an html server in any data server process. This html server is configured to host the following servlets: - %RTV_HOME%\servlets\rtvadmin\rtvadmin.war - %RTV_HOME%\servlets\rtvquery\rtvquery.war - %RTV_HOME%\servlets\rtvdata\rtvdata.war - %RTV_HOME%\servlets\rtvadmin\rtvadmin.war The html server is disabled by default in all deliverables except the RTViewDataServer and RTViewDataCollector deliverables. To enable it, add the following property to the properties file for your data server: dataserver.sl.rtvapm.sc.enabled=true The servlets hosted in a data server are automatically configured at startup with the correct port for connecting to the data server. The servlets can be accessed at http://localhost:3270/servletname. To change the port, add the following property to the properties file for your data server: dataserver.sl.rtvapm.sc.port=3370 When running with the html server enabled in a data server, you must always shut down the server using the stop_rtv script. This is because the html server writes temporary files to the directory listed in the java.io.tmpdir System property. When the data server is shutdown properly using stop_rtv, the temporary files are deleted. If the data server is shut down using a kill command, the temporary files are not cleared. Eclipse Jetty is dual licensed under Apache License 2.0 and Eclipse Public License 1.0.

22302: Improvements to HA for all directories under emsample\servers

High Availabllility has been fixed and/or incorporated to all dataservers that are available under EM.

Distribution

22120: Jackson libraries - move into shared location

External jackson and netty libraries previously provided as part of the Kafka monitoring solution package have been moved out of that solution package into the common platform library directory.

22177: New RTViewEnterpriseMonitor bundle that has all solution packages

RTView Enterprise Monitor is now available as one download containing all available solution packages. This new deliverable, RTViewEnterpriseMonitor_VERSION.zip, contains the following directories: RTViewEnterpriseMonitor\ apache-tomcat-7.0.72\ bin\ emsample\ rtvapm\ make_all.sh make_all.bat apache-tomcat-7.0.72 - Apache Tomcat 7.0 configured for jmx remote monitoring and pre-populated with RTView Enterprise Monitor servlets bin - scripts for launching apache tomcat and all enabled RTView EM solution packages emsample - example EM project rtvapm - the RTView Enterprise Monitor application directory Refer to the RTVIew EM UserGuide for more information on how to configure and use RTView EM.

22419: Bundled tomcat updated to v8.5.24

The Apache Tomcat bundled with RTView EM has been updated to version 8.5.24

General

22099: Applied properties view sometimes shows wrong property hierarchy

In previous releases, the order of Applied Properties was sometime incorrect. This has been fixed.

22315: Removed custom sp example from deliverable

The custom solution package example has been removed from EM. Contact SL technical support for information on creating custom solution packages. Existing custom solution packages will continue to work as they did before. See the release note for TN22290 for information on how to optionally upgrade your custom solution package to be compatible with the new Configuration Application. A simple mechanism has been added for configuring custom handlers for use in custom displays. An example of the custom handler classes is available under the following directories: RTViewEnterpriseMonitor: emsample\custom TIBCOEnterpriseMonitor: em-tibco\custom All standalone deliverables: projects\sample\custom Use the following properties to instance the custom handlers in your server: # Add the jar containing the custom classes to the classpath. Adjust this path if necessary # to point to the location of your jar. sl.rtview.cp=<path to custom jar>/lib/rtvapm_custom.jar # the custom function handler sl.rtvapm.customfunctionhandler=functionHandlerClassName # the custom command handler sl.rtvapm.customcommandhandler=commandHandlerClassName # the custom rtview manager sl.rtvapm.customrtvmanager=rtviewManager # the custom app manager sl.rtvapm.customappmanager=rtvAppManager The steps for using the sample java alert notification example has changed as follows: 1. Enable alert notifications in the Configuration Application 2. Add the following properties on the CUSTOM PROPERTIES tab: # Add the jar containing the custom classes to the classpath. Adjust this path if necessary # to point to the location of your jar. sl.rtview.cp=<path to custom jar>/lib/rtvapm_custom.jar # instance the custom command handler: sl.rtvapm.customcommandhandler=com.sl.rtvapm.custom.RtvApmCommandHandler # new alert notification: sl.rtview.alert.notifiercommandnew=system cust 'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol' $alertNotifyTable # cleared alert notification: sl.rtview.alert.notifiercommandcleared=system cust 'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol' $alertNotifyTable # alert column changed notification. change the notifiercolumns property to notify on other columns: sl.rtview.alert.notifiercolumns=Acknowledged;Owner;Comments sl.rtview.alert.notifiercommandchanged=system cust 'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol' $alertNotifyTable # first severity change notification sl.rtview.alert.notifiercommandfirstsevchange=system cust 'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol' $alertNotifyTable # timer renotifications for all open/unacknowledged alerts sl.rtview.alert.notifierrenottime=300 sl.rtview.alert.notifiercommandrenot=system cust 'my_alert_notification.$domainName.$alertNotifyType.$alertNotifyCol' $alertNotifyTable

RTVMGR

21741: Monitoring Tomcat 8.0 or 8.5 no longer produces cache function errors

A bug that caused errors in the dataserver.log file for data server's monitoring Tomcat 8.x servers has been fixed. The errors had the following syntax: ERROR: function <tomcatWebModuleStats04DeltaRate>, Table structure has changed; cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv ERROR: function <tomcatManagerStats77DeltaRate>, Table structure has changed; cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv

RTView Core Functionality

22551: Mouseover text no longer mispositioned on scrolled thin client displays

A problem has been fixed in the thin client that caused the mouseover (tooltip) text to be mispositioned for objects that needed to be scrolled into view.

Data Server

22462: Float column values no longer garbled in rtvquery response

In the previous release, values for cache columns with type = float were garbled in query responses from the rtvquery (REST) servlet, so the response could not be parsed. This is fixed.

Data Sources

22482: GmsRtViewHawkCustomSSLHandler now called for HAWK 5.x ems connections by the TIBCO Hawk Data Source

Previously the GmsRtViewHawkCustomSSLHandler "MyHawkSSLHandler" was not called for TIBCO Hawk 5.x ems connections. This is no longer the case. Use of the GmsRtViewHawkCustomSSLHandler "MyHawkSSLHandler" to set Hawk SSL parameters is described in the "TIBCO Hawk SSL Parameters" Section of the TIBCO Hawk Data Source documentation.

Display Server

22117: Tomcat no longer throws an error if image path contains a backslash

A bug has been fixed in the thin client which would cause Tomcat 8.5+ to throw an IllegalArgumentException if the path to an image contained a backslash. The full exception is as follows: java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986

Object Library

19863: Added support for HTML pie charts

BASICS: The thin client now supports a web pie chart. The web pie chart is a pure HTML implementation of an RTView pie chart object. In the RTView thin client, the web pie chart provides an interactive, high performance chart without requiring the Flash player or other browser plugin. There is no web pie chart in the Builder palette. Instead, a new property named webChartFlag has been added to the flex (obj_fxpie) and swing (obj_pie) pie charts. To enable the web pie chart the user simply sets the webChartFlag property to true (checked) on a flex or swing pie chart instance. Then, when the display is opened in the thin client in a web compatible browser, the web pie chart will appear in place of the flex or swing pie chart. This feature is similar to the webChartFlag property that has been available on the flex and swing trend graph and bar graph objects in several prior releases. PROPERTIES: The web pie chart supports all of the major properties available in the flex and swing pie charts. However several minor properties are not supported or have limited support in the web pie chart. These properties are listed at the end of this note. BEHAVIOR: In addition to the properties listed below, there are some behavioral differences between the web pie chart and the flex/swing pie chart as follows. 1) Stretching: Unlike the swing pie chart obj_pie, the web pie chart does not stretch to an oval shape to fill the available space. Instead the web pie chart remains round, with its diameter determined by the smaller dimension. (The flex pie chart is always round too). 2) Slice order: In the swing and flex pie charts the bottom edge of the first wedge/slice, corresponding to the first row in the valueTable, is drawn at 0 degrees (that is, its bottom edge is horizontal). The slices for subsequent rows follow in counter-clockwise order. In the web pie chart, the first slice is drawn at 90 degrees, so its left edge is vertical. The slices for subsequent rows follow in clockwise order. 3) Tooltip: The tooltip on the web pie chart shows the label and value for a wedge, but does not show its computed % 4) Wedge labels (on obj_fxpie only): On obj_fxpie, wedge labels are visible unless wedgeLabelPosition = None(0), as expected. However, the label shows only the wedge's label, not its value or %. Also the wedgeLabelPosition values of "Inside with Callout(3)" and "Outside(4)" give the same result as "Callout(1)" on the html5 chart. If wedgeLabelPosition = Inside(2), some wedge labels may spill outside of their wedge, depending on the size of the label and wedge. ENABLING / DISABLING: The web pie chart can be enabled for all obj_fxpie (flex) instances by adding the following rule to an rtview stylesheet (.rts) file loaded by the display server: obj_fxpie { webChartFlag : 1 } Similarly, the web pie chart can be enabled for all obj_pie (Swing) instances by the following rule: obj_pie { 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. UNSUPPORTED/IGNORED PROPERTIES: As mentioned earlier, some chart properties are hidden in the builder if webChartFlag is checked. These properties of obj_fxpie are hidden if webChartFlag is checked: bg3dFlag bgGradientFlag labelColumnFormat rowLabelVisFlag rowNameVisFlag legendBgGradientFlag legendWidthPercent legendValueVisFlag legendPercentVisFlag entranceDuration entranceTrigger entranceType exitDuration exitTrigger exitType wedgeExplodeRadiusPercent wedgeLabelTextColor wedgeLabelTextFont These properties of obj_pie are hidden if webChartFlag is checked: bgEdgeWidth bgGradientMode bgGradientColor2 bgRaisedFlag bgShadowFlag bgStyle borderPixels labelColumnFormat rowLabelVisFlag rowNameVisFlag labelMinTabWidth legendBgGradientMode legendBgGradientColor2 legendWidthPercent legendValueVisFlag legendPercentVisFlag outlineColor transparencyPercent

22114: webChartFlag can now be set in styles sheet for bar and trend graphs

In prior releases, the webChartFlag property could not be set on obj_bargraph and obj_trendgraph02 objects via an rtview stylesheet (.rts) file. This has been fixed, so the following stylesheet entries will now set webChartFlag on all such objects: obj_trendgraph02 { webChartFlag: 1; } obj_bargraph { webChartFlag: 1; }

22398: Fx Graphs now supported in 64 bit java on Windows

The Fx Graph objects are now supported in the Builder & Viewer in 64 bit versions of Java on Windows. Previously only 32 bit java was supported. This enhancement does not affect Linux or MacOS rtview installations. The Fx Graph objects are still not supported in the Builder/Viewer on those platforms.

Reporting

22541: Export to PDF in thin client no longer triggers server log error message

Previously, under certain circumstances, exporting a PDF, using the "Export to PDF" option would trigger a java.lang.IllegalStateException error message in the (display)server log (e.g. logs\displayserver.log). This is no longer the case.

22558: Ability to suppress headers and footers in generated PDF reports added

A capability to suppress headers and footers in generated PDF reports has been added to the report generator. This is achieved by means of adding new attributes to the report tag in the report config xml file The new attributes are: no_header no_footer which take a boolean value, and are false by default. Not adding the attributes will have the same behavior as previously. e.g. for a generated report with a header and footer <report name = "plant_status"> for a generated report with no header (but with a footer) <report name = "plant_status_no_header" no_header="true" > for a generated report with no footer (but with a header) <report name = "plant_status_no_footer" no_footer="true" > for a generated report with no header and no footer <report name = "plant_status_no_header_footer" no_header="true" no_footer="true">

Scripts

22296: rtvpost added to make_war and update_war scripts

The rtvpost war file is now included in the make_ and update_wars scripts.

22542: Split start/stop_servers scripts in bundles into central vs data servers

The RTViewEnterpriseMonitor and RTViewTIBCOMonitor deliverables have been enhanced with scripts to start and stop only the central servers, and to start and stop only the data servers. They are: start_central_servers.bat/sh stop_central_servers.bat/sh start_data_servers.bat/sh stop_data_servers.bat/sh -------------------------------------- The start_rtv, stop_rtv, and status_rtv scripts have been enhanced as follows: (1) The first argument to the scripts, the config, may now be a list of configs separated by "+". For example, "start_rtv bwmon+emsmon" will start all (uncommented) servers in the bwmon and emsmon sections. (2) A new argument has been added to exclude a list of configs. For example, "start_rtv all -exclude:bwmon+emsmon" will start all (uncommented) servers except those in the bwmon and emsmon sections.

Solution Package

22171: New Data Cache package

A new Data Cache package has been added to RTView Enterprise Monitor. It is used to post data to RTView via http from a javascript application such as NodeJs. Rest Endpoints (urls) are provided to allow the posting of data to caches, and the creation, deletion and replacement of caches. Refer to rtvapm\datacache\README.txt for more information

22310: Solution package README.txt files deprecated

The solution package README.txt files have been deprecated. Information relevant to essential configuration has been migrated into the conf\sample.properties comments, to continue to support users who prefer to set properties manually in the properties files, rather than use the new Config UI.

Apache Kafka

22134: New consumer lag metrics alerts

The following alerts have been added to Kafka Monitor: KafkaConsumerLagIncreasing This alert is triggered for any topic if the consumer lag rate of change is greater than zero for the specified duration. This implies the lag is steadily increasing. KafkaConsumerSlow = current-delta positive and lag-delta nonnegative This alert is triggered for any topic if the consumer lag delta is nonnegative and the current offset delta is positive for the specified duration. This implies the consumer is slow in reading messages and should be considered a warning. KafkaConsumerPartitionStalled This alert is triggered for any partition of any topic if the consumer lag delta is nonnegative and the current offset delta is zero for the specified duration. This implies new messages are being added to the partition but the consumer is not reading them.

22473: Collect and display consumer lag metrics

The information Kafka Monitor presents about consumer lag has been significantly enhanced. Lag metrics are now collected on a per-partition basis for the cluster and summarized across brokers and consumers. The new calculated value is now used in the Consumer displays instead of the old "record-max-lag" value reported by the brokers, and new displays have been added as follows. 1. The Cluster All Topics Chart now has a bar graph with lag values summed across brokers and consumers 2. The Topic Summary has a new Partitions tab with - Bargraph of lag per topic:broker - Table of partitions for topic 3. The Broker Summary has a new Topic Lag tab with - Bargraph of lag per topic - Table of topics for broker 4. The Consumer Summary has a new Consumer Lag tab with - Bargraph of lag per topic - Table of topics for consumer

Host Infrastructure

22261: rtvHostAgent no longer pre-extracted

To reduce the size of the product download, the rtvHostAgent .zip file will no longer be pre-extracted under hostmon/agents. The README.txt from within the rtvHostAgent_x.zip is, however, now available as hostmon/agents/README_rtvHostAgent.txt

Oracle Weblogic

22158: HOST CPU Usage % no longer zero for non JRockit JVMs

The System CPU % has been enhanced to use the SystemCpuLoad attribute from the JMX OperatingSystem MBean when the running version of Java is 1.7 or higher. This fixes an issue whereby the HOST CPU Usage % was zero for non JRockit JVMs.

22159: The JVM CPU % now represents multiple cores and is not capped at 100%

The JVM CPU % now shows percentages above 100%, which comes from the number of cores.

22370: function error in data server logs cleaned up

Previously a WLM dataserver running on Linux, monitoring v12.2.x, would print the following spurious error: 2017-11-28 15:01:42,928 INFO GmsTimer-DataServer - [rtview] ERROR: function <wlsWorkManagerStats2>, Table structure has changed; cannot save data., type:DELTARATEROWS, file:wls_workmgr_cache.rtv This error has been addressed

TIBCO ActiveSpaces

22162: New Tasmon Query Metrics displays

New Tasmon Query Metrics displays (All Queries Table, Query Summary) have been added. These show metrics on queries including query duration. The All Queries Table display shows metrics for current and recent queries, filterable by selected Domain, Metaspace and space. Information on a specific query can be shown by drilling down on a row in the Queries table. This will drill down to, and populate, the Query Summary display for the selected query. The Query Summary display shows Space, Member and Query information for the selected query. In the case where the query is run across multiple members, information is shown for related queries. Queries are related when they share the same parent request id as the selected query. Related queries can be drilled down to in the Related Queries Table, to become the selected query in the query summary display. Additional Member information is available by drilling down on the Member Info .. area, which will drill down to the Member Summary display for the given member. Note: The metrics for the above displays are only available for ActiveSpaces 2.3(+) Systems when query statistics monitoring has been configured. Query statistics monitoring is configured by populating the TasQueryStats cache using a named connection to ActiveSpaces 2.3+ Metaspace as described in the sample.properties file. # Configure the following cache definition to populate the TasQueryStats cache for version 2.3+ ActiveSpaces Systems # - one for each configured connection using the $tasConnName subs # #collector.sl.rtview.cache.config=tas_querystats_cache_source.rtv $tasDomain:<domain-name> $tasConnName:<connection> #

22163: New Tasmon Alert TasQueryDurationHigh

A new Tasmon Alert TasQueryDurationHigh has been added. This alert will trigger when a query duration (in seconds) is above the defined thresholds (in seconds). This alert has a per space override available. Note: The metrics for the above alert are only available for ActiveSpaces 2.3(+) Systems when query statistics monitoring has been configured. Query statistics monitoring is configured by populating the TasQueryStats cache using a named connection to ActiveSpaces 2.3+ Metaspace as described in the sample.properties file. # Configure the following cache definition to populate the TasQueryStats cache for version 2.3+ ActiveSpaces Systems # - one for each configured connection using the $tasConnName subs # #collector.sl.rtview.cache.config=tas_querystats_cache_source.rtv $tasDomain:<domain-name> $tasConnName:<connection> #

22164: New TASMON connection parameters (securityToken and identityPassword)

New connection parameters, securityToken and identityPassword, have been added to the tasmonds connection string property. The securityToken value is the value of the path to the security token file. By copying the security property file to current project directory, the path can be eliminated and just the name of the security token file used. When the securityToken parameter is used, the discovery parameter should not be used, since discovery values are defined in the securityToken file. The identityPassword value is the value of the password used to created the safe identity password required with the security token file Examples of connection strings that use these parameters are given in sample.properties # NOTE: When securityToken is used discovery and listen values should NOT be specified #collector.sl.rtview.tasmonds.conn=__name=<connection> memberName=RTViewEM metaspaceName=<metaspace> discovery=<discoveryURL> listen=<listenURL> # remote discovery # collector.sl.rtview.tasmonds.conn=__name=ms1 memberName=RTViewEM metaspaceName=ms1 discovery=tcp://localhost:6001?remote|true listen=- # With secureToken #collector.sl.rtview.tasmonds.conn=__name=ms memberName=RTViewEM metaspaceName=ms securityToken=mytoken.txt # with secureToken and identityPassword #collector.sl.rtview.tasmonds.conn=__name=ms memberName=RTViewEM metaspaceName=ms securityToken=mytoken.txt identityPassword=password

22504: Tasmon now supports encrypted identityPassword's in connection definition properties

Tasmon now supports encrypted identityPassword's in connection definition properties, for use with securityToken files.

TIBCO Adapter

22078: Set the webChartFlag to true in the EM stylesheet for the Java trend graphs

The webChartEnabledFlag has been set to true for obj_trendgraph02 objects in EM so that they will use the html5 version of the graph in the thin client.

TIBCO BusinessWorks

22157: Show BW6 deployment as appspace or container

The Application and Appnode tables have a new column Deployment with values Appspace and Container, and there are checkboxes on the Table and Heatmap displays to control which are displayed.

22187: Removed "Error Count" from BW6 AppNodes Heatmap metrics dropdown

The BW All AppNodes Heatmap display had an erroneous entry "Error Count" in the Metrics dropdown menu. This has been removed.

22188: Fixed "Current Executions" on the BW6 AppNode summary display

On the BW AppNode summary display the field "Current Executions" was not correctly attached to data and showed zero. This has been corrected.

22399: Time Since Last Update now formatted as duration

In the BW All Activities table in BusinessWorks 5 Monitor, the column Time Since Last Update is now formatted as a duration, e.g. 0d 00:50 is 50 minutes.

22425: Support for standalone containers in BW6/BWCE

In this release, if you choose not to supply values for the properties sl.rtview.bw.domain sl.rtview.bw.appspace sl.rtview.bw.appnode then unique names will be created for appspace and appnode, and each container will appear as a standalone application with a single appnode. If you supply specific names then your containers will appear in the displays as if they were appnodes in an appspace, and if they are instances of the same application, their metrics will be summed for the application, as if it were deployed to the appspace. In summary, you may configure your containers to run as if they were appnodes in an appspace; or else they will run such that each is a unique appnode and application.

22442: Rename BW6 to BW in displays and navtree

The naming of BW displays across versions 5 and 6 has been made more uniform. The displays such as BW6 Applications, BW6 AppNodes etc. will now be labeled simply BW Applications etc. In the navigation tree their section will be labeled TIBCO BusinessWorks and the section formerly labeled TIBCO BusinessWorks will be labeled TIBCO BusinessWorks 5

22564: bw6mon and amxmon assigned unique port prefixes

The RTView EM packages TIBCO ActiveMatrix Monitor (amxmon) and TIBCO BusinessWorks Monitor (bw6mon) have been given new default port assignments. This will be reflected in the "port prefix" in the Configuration UI as well as the "update_wars" scripts in the emsample project. For BusinessWorks Monitor the new port prefix is 45. This results in the following default port assignments: dataserver data port 4578 dataserver JMX port 4568 datserver SC port 4570 dataserver rtvhttp port 4575 dataserver rtvagent port 4572 dataserver sender data port 4576 dataserver sender JMX port 4566 displayserver data port 4579 displayserver JMX port 4569 historian JMX port 4567 database (hsqldb) JMX port 4561 For ActiveMatrix Monitor the new port prefix is 44. This results in the following default port assignments: dataserver data port 4478 dataserver JMX port 4468 datserver SC port 4470 dataserver rtvhttp port 4475 dataserver rtvagent port 4472 dataserver sender data port 4476 dataserver sender JMX port 4466 displayserver data port 4479 displayserver JMX port 4469 historian JMX port 4467 database (hsqldb) JMX port 4461 For compatibility purposes the old port assignments are available in the rtvapm.<package>.compat.properties files in RTVAPM_HOME/<package>/conf. Note that these files will be automatically loaded if the file rtview.properties (which is now obsolete) is found in the project directory.

22700: Support for specifying BW Engine name prefix on data server command line

The BW Monitor data server has been enhanced with a new command-line argument -engineprefix:<string> where <string> will be used to identify BW Engine microagents in the Hawk agent, and will be removed from BW Engine names in the displays. This string is normally COM.TIBCO.ADAPTER.bwengine. If you set the prefix e.g. -engineprefix:COM.TIBCO.ADAPTER.bwxxx you will see a log message such as ... setting BW Engine prefix to COM.TIBCO.ADAPTER.bwxxx

TIBCO EMS

21717: servers.xml removed from emsmon project

The Monitor for TIBCO Enterprise Message Service has been enhanced to use properties to define connections to EMS Servers. Previously this was done in an xml file named servers.xml. Projects using servers.xml files to define their connections will continue to work. New projects should define their server connections as follows, replacing <URL> <USER>, <PASSWORD> with the appropriate values for the connection: collector.sl.rtview.jmsadm.jmsadm_server=url=<URL> user=<USER> password=<PASSWORD> Note that the user and password aguments are optional. Some examples: collector.sl.rtview.jmsadm.jmsadm_server=url=tcp://host1:7222 collector.sl.rtview.jmsadm.jmsadm_server=url=tcp://host2:7222 user=user1 password=pass1 collector.sl.rtview.jmsadm.jmsadm_server=url=tcp://host3:7222,tcp://host3:7222 user=user1 password=pass1 Passwords can be encoded before entering them in your properties file using the encode_string command line utility.

21718: Removed unneeded cp properties from EMSMON sample.properties

The following properties are no longer needed by the Monitor for TIBCO Enterprise Message Service. They have been removed from the sample properties. collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/jms.jar collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/jms-2.0.jar collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/tibjms.jar collector.sl.rtview.cp=%TIBJMS_ROOT%/lib/tibjmsadmin.jar

TIBCO FTL

22030: New Solution Package for TIBCO FTL

The Solution Package for TIBCO FTL (TFTLMON) has been added to RTView Enterprise Monitor. This Solution Package monitors all the components of a FTL Realm, including Satellite Servers, CSPF Neighbors, VPNs, Bridges, Clients, and Endpoints. See the RTView Enterprise Monitor User Guide for configuring the TFTLMON Solution Package.

TIBCO Hawk

22170: Default hawk connection disabled

In previous releases, using stop_rtv.sh on Unix platforms to stop a Data Server running the HAWKMON package failed due to a spurious rvd process caused by the creation of an unecessary connection made by the HAWKMON data source. This has been fixed.

UX Monitor

22260: UXRobot zip no longer pre-extracted

To reduce the size of the product download, the UXRobot.zip file will no longer be pre-extracted under uxmon/agents. The README.txt from within the UXRobot_x.zip is, however, now available as hostmon/agents/README_UXRobot.txt

VMWare vSphere

22178: Re-implemented support for standalone ESXi hosts

In the previous release, support for standalone VMWare ESXi hosts (as opposed to vCenter servers) was broken due to added support for clusters. There is now a separate VMWmon cache source file or connections to standalone VVWare hosts. For standalone hosts use collector.sl.rtview.cache.config=vmw_host_cache_source.rtv $vmw_conn:<connection-name> and for vCenter servers use collector.sl.rtview.cache.config=vmw_cache_source.rtv $vmw_conn:<connection-name>

Version 3.8.1 Release Notes

Solution Package

Apache Kafka

22094: Enhanced Topic Summary with multiple averages

The Kafka Single Topic Summary and the Single Broker Summary Topic Trends displays have been enhanced with the addition of a drop-down list to select different averaging for the trend values, including mean, 1, 5, and 15 minutes.

22095: Sort options added to topics charts

The displays Kafka Cluster Activity for Topic and Kafka Cluster Activity for all Topics have been enhanced with sort controls so you may choose the column by which data is sorted, and in which direction.

22149: Added support for Kafka version 9 zookeepers

Kafka Zookeepers running under Kafka version 0.9 will now appear in the monitor displays, in the cluster assigned in the startup properties. Limitations: - v0.9 Zookeepers will not have a "cluster id" field - KafkaClusterSplitBrain alert will not work correctly for v0.9 Zookeepers

22150: Four KafkaCluster alerts added

Four alerts for Kafka Clusters have been added to the Alert Administration table. Their names and descriptions are as follows: KafkaClusterNoActiveController There is more one active controller per cluster (could indicate split-brain) KafkaClusterSplitBrain One or more Zookeepers or Brokers are not acting as part of the main cluster KafkaClusterPartitionsUnbalancedHigh Partitions supported by the cluster are not evenly distributed across the available brokers KafkaClusterLeadersUnbalancedHigh Partition leaders for the cluster are not evenly distributed across the available brokers. These may be made available in EM 3.8.0 by adding the following line to your sample.properties file: collector.sl.rtview.alert.config=kafka_cluster_alertdefs.rtv

22151: Support for multiple-digit zookeeper IDs

Previously the Kafka Monitor would fail to display metrics for a Zookeeper whose ID was more than one digit. This has been corrected.

TIBCO BusinessWorks

22139: The column CPU % in BwEngines cache should never have NaN

Under some circumstances stopped engines would report a CPU% of NaN. They will now report a value of zero.

22147: Active applications no longer incorrectly appear as EXPIRED

In the previous release, applications in the table could be missing a value in the Timestamp column, which would cause the application to be marked expired, and thus trigger the AppExpired alert if enabled. This has been fixed.


Version 3.8.0 Release Notes

Configuration

22053: EM property handling has been enhanced

In previous releases, sender properties could be overriden by project properties unintentionally. In order to address this, the EM property handling has been enhanced to give precedence to the properties that use the sender property filter for processes that are run with the sender property filter.

22069: Port inconsistencies fixed in multiple solution packages

The following solution packages were set to use an incorrect port in rtvagent.war to communicate with the dataserver: acwmon mqmon mysqlmon ocmon syslog These have been corrected.

Deployment

21919: $rtvTimeZoneOffset substitution has been removed from emcommon and emreference

The $rtvTimeZoneOffset substitution has been removed from emsample\conf\emcommon.properties. This substitution is not used in any standard EM displays. Customers who have created custom displays for use with EM, should check to see if they have used that substitution and if so, add it to their project properties.

Distribution

21983: Fixed an issue with .war file creation

Previously some solution packages could not be built from scratch in a deliverable using the make_wars_package.bat script, due to a file missing from the package library. This has been fixed. The effected solution packages are: Solution Package for Amazon Cloudwatch (acwmon) Solution Package for VMWare (vmwmon) Solution Package for TIBCO ActiveSpaces (tasmon)

RTView Core Functionality

Data Historian

21921: Microsoft SQL Server 2014 and 2016 now supported

Microsoft SQL Server 2014 and 2016 are now supported as databases for use with the Data Historian, provided that the latest JDBC driver is used (sqljdbc41.jar with Java 1.7, sqljdbc42.jar with Java 1.8).

Data Sources

22083: Jmx commands no longer fail silently when RTView isn't connected

In previous releases, if a jmx command failed because RTView wasn't connected, it failed silently. This has been fixed and the error is reported.

Display Server

21909: Tomcat logs no longer produce gratuitous rtvCleanup errors

In previous releases the following error message appeared in the Tomcat log at shutdown, for each deployed copy of the rtvdisplay servlet: "SEVERE: The web application [/rtvdisplay] appears to have started a thread named [rtvCleanup] but has failed to stop it. This is very likely to create a memory leak." Starting with this release, the error message should be seen less often in the log file, although it may still appear occasionally. In any case, there is no danger of a memory leak when tomcat is shutdown.

21990: Fixed a vulnerability in the thin client

An XSS (cross-site scripting) vulnerability in the thin client login.jsp file has been fixed.

21996: Fixed an issue with thin client resizing

In previous releases, after a display is resized by the thin client to fit the browser window, the black border around the default button (if any) was drawn in the button's original position, rather than the button's new position. This is fixed.

Object Library

21045: Misconfigured table objects no longer cause javascript exceptions in the thin client

A bug in the thin client has been fixed which could cause a javascript exception if the columnFormat on a table object was misconfigured to specify a format for a string column, and a backslash character appeared in the column.

Scripts

22049: EM enhanced to automatically read local project.property files

EM applications have been enhanced to automatically read project.properties if it exists in the directory where they were started. If project.properties does not exist, no error is printed. Upgrade Notes: If you are upgrading from a previous version and your project contains a project.properties file, be aware that this file will be used even if it is not specified on the command line. To avoid this, rename or remove your project.properties file.

Solution Package

Apache Kafka

22029: New Solution Package for Apache Kafka

The Solution Package for Apache Kafka (KAFKAMON) has been added to RTView Enterprise Monitor. This Solution Package monitors all the components of a Kafka Cluster, including Zookeepers, Brokers, Producers, Consumers, and Topics. See the RTView Enterprise Monitor User Guide for configuring the KAFKAMON Solution Package.

General

21856: Several solution packages have had their ports standardized

The default port numbers for sender and receiver ports in several solution packages were modified to follow the convention of using the same first 2 digits for all ports within a solution package. The modified properties are listed below. db2mon, jbossmon, oramon, tasmon, tbemon, vmwmon: Changed the following properties from port 5665 to 3272: sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3272 packages=all receiver.sl.rtview.rtvagent.port=3272 dockermon, mongomon, mssqlmon, nodemon: Changed first 2 port digits from 41 to 32 for the following properties: sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3272 packages=all receiver.sl.rtview.rtvagent.port=3272 sender.sl.rtview.dataserver.port=3276 sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3266 hawkmon: Changed first 2 port digits from 39 to 33 for the following properties: sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3372 packages=all receiver.sl.rtview.rtvagent.port=3372 sender.sl.rtview.dataserver.port=3376 sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3366 hostbase: Changed first 2 port digits from 39 to 32 for the following properties: sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3272 packages=all sender.sl.rtview.dataserver.port=3276 sender.sl.rtview.jvm=-Dcom.sun.management.jmxremote.port=3266 receiver.sl.rtview.rtvagent.port=3272

Host Infrastructure

21903: Fixed an issue with HostProcessCountLow alert

The indexes and the driving metric of the HostProcessCountLow alert have been fixed. In addition, the Alert Text now reads as a Low Alert instead of a High Alert.

IBM Websphere Application Server

21776: Linux custom_setup script enhanced in WSM

The custom_setup script for Linux has been enhanced to exclusively define WAS_HOME and JAVA_HOME environment variables. And similarly to the configuration under Windows, the definition of the location of the API jars required to connect to the WebSphere Admin has been moved to the sample.properties file.

MySQL

21861: MySQLMON enhanced to collect MYSQL 5.7.6+ data by default

The RTView MYSQLMON Solution Package no longer requires the "show_compatibility_mode=ON" setting to allow collection of MySQL 5.7.10+.

22097: MYSQLMON sql schema files now complete

The database table schemas under rtvapm\mysqlmon\dbconfig have been updated to include missing optional table schemas. The name of the existing tables were also updated to remove the extraneous "_TABLE" from the end of them, to match the table names as configured in the MYSQLMON historian. Users of v3.7 may need to update their three existing database table names to the new names. Users who used Historian auto-creation will already have the new table names. Example syntax is available below. Oracle alter table MYSQL_BYTES_TABLE rename to MYSQL_BYTES; alter table MYSQL_CRUD_TABLE rename to MYSQL_CRUD; alter table MYSQL_QUERIES_TABLE rename to MYSQL_QUERIES; DB2 RENAME TABLE MYSQL_BYTES_TABLE TO MYSQL_BYTES; RENAME TABLE MYSQL_CRUD_TABLE TO MYSQL_CRUD; RENAME TABLE MYSQL_QUERIES_TABLE TO MYSQL_QUERIES; MySQL RENAME TABLE MYSQL_BYTES_TABLE TO MYSQL_BYTES; RENAME TABLE MYSQL_CRUD_TABLE TO MYSQL_CRUD; RENAME TABLE MYSQL_QUERIES_TABLE TO MYSQL_QUERIES; SQL Server (replace "database_name" with the name of your database) use database_name go exec sp_rename '[MYSQL_BYTES_TABLE]', '[MYSQL_BYTES]' exec sp_rename '[MYSQL_CRUD_TABLE]', '[MYSQL_CRUD]' exec sp_rename '[MYSQL_QUERIES_TABLE]', '[MYSQL_QUERIES]' go Sybase sp_rename 'MYSQL_BYTES_TABLE', 'MYSQL_BYTES'; sp_rename 'MYSQL_CRUD_TABLE', 'MYSQL_CRUD'; sp_rename 'MYSQL_QUERIES_TABLE', 'MYSQL_QUERIES';

Solace

21815: Message Router drop down enhanced to show availability of message routers

The Message Router drop down has been enhanced to indicate the availability of the Message Router. When the Message Router is disconnected, the connection name contains the string [?] appended to indicate the quality state: "No Data". When the Message Router has expired, the connection name contains the string [X] appended to indicate the quality state: "Lost Data". No string is appended to the connection name if the Message Router has no monitoring issues.

21886: Removed unnecessary link in Message Routers navigation tab

The link to the CSPF Neighbors has been removed from the Message Routers navigation tab.

21997: Multiple improvements made to some SOLMON displays

To avoid having the SOLMON Client displays blank when there is an error in the SEMP request that populates the SolClients cache, an improvement in our displays has been introduced to show the data available mainly from the SolClientStats cache and leave the SolClients cache as a secondary source of data. As a result, the All Clients Table can show the data coming from the available SolClientStats cache. The missing columns that are primarily static strings will be blank in this display. In regard the Clients Summary, a quality measurement of the available data is being performed so the display shows the existing data and hides the graphical elements for which we don't have available current data. If the data is Expired, the background of this display is shown grey with the string "[X]" appended to the Client name in the drop down. Finally, the background of the display will be shown as light red and the Alert State grayed out if there is no client available.

22036: Properties related to SOLMON history tables moved to conf directory

The properties that enable/disable the SOLMON history tables have been moved from the sample.properties file to the rtvapm.solmon.properties file located in the conf directory. To change the default settings, follow the instructions provided in the second file.

TIBCO ActiveSpaces

21860: Handling of ActiveSpaces environment variables has been improved

The custom_setup.sh script in tasmon would overwrite the existing value of LD_LIBRARY_PATH rather than append to it. This has been corrected. Also, both the .bat and .sh version will now check to see if a location for AS libraries is defined, and if not will use a default location and warn the user. You may define your correct location by editing the script. For Windows the default location is: AS_PATH=%RTVAPM_HOME%\..\ext\tibco\as\2.1.6 For Unix it is: AS_HOME=/opt/tibco/as/2.1 Note the scripts no longer issue a warning that the script "has not been edited."

22059: New System Resource Metrics available for metaspace members

New System Resource Metrics are available for metaspace members, for metaspace members that have system monitoring enabled, in the the All Members Table Display (and in the TasMembers cache) Enabling system monitoring is described in the Tibco Active spaces documentation. System monitoring can be enabled at Tibco process (e.g. as-agent) launch time by using the command line argument -monitor_system true. System monitoring can also be dynamically enabled or disabled for metaspace members using as-admin CLI commands. Individual metaspace members can have system monitoring enabled / disabled using the as-admin command execute on member "<name>" monitor system true|false e.g. execute on member "retail_put" monitor system true Multiple / all metaspace members can have system monitoring enabled / disabled using the as-admin command execute on [peer | remote] members <admin_command> e.g. execute on peer members monitor system true The System Resource Metrics are obtained from the $sys_stats space. These are are the values used in the as-admin CLI command show | describe system stats The (new) column names in the the All Members Table Display (and the TasMembers cache) are the same as the $sys_stats space tuple field names for traceabilty The (new) column names and description from the Tibco show | describe system stats documentation are given below String sys_name Indicates the operating system that is running. String cmd_name Indicates the command used to start as-admin; for example, as-admin -monitor_system true . String proc_id Indicates the process ID for the process that is monitored. String user_name Indicates the user name of the user running the process. Long thread_count Indicates the number of threads running for the process. Long res_mem_size Indicates the amount of physical memory currently allocated to the member or agent process. (Resident Memory(MB)) Float mem_load Indicates the % Memory used. Long peak_res_mem_size Indicates the peak size of the system resident memory allocated by the system. Long page_size Indicates the current size of the system pagefiles (resident memory) allocated by the system. Page File Size (MB) Long peak_page_size Indicates the peak size of the system pagefiles allocated by the system. Float process_cpu_load Indicates the load on the CPU. (CPU %) Integer cpu_count Indicates the number of CPUs running on the system. JVM Heap Metrics - only available for Java Metaspace member processes Indicates the following information for the JVM heap: Long jvm_comm_heap_size Committed MB - The committed heap usage. Long jvm_max_heap_size Max MB - The maximum heap usage. Long jvm_used_heap_size Peak (MB) - Indicates the peak usage in MB. JVM Nonheap - only available for Java Metaspace member processes Indicates the following information for the JVM non-heap memory: Long jvm_comm_nonheap_size Committed MB - The committed nonheap usage. Long jvm_max_nonheap_size Max MB - The maximum nonheap usage. Long jvm_used_nonheap_size Peak (MB) - Indicates the peak nonheap usage in MB. Long jvm_finalizing_count The amount of memory freed by the finalize operation on the JVM. String as_version Indicates the ActiveSpaces version that is running. Additionally, there is the calculated value JvmMemoryUsedPercent , where JvmMemoryUsedPercent is %age JVM Heap Used ( Used JVM Heap / Max Jvm Heap) = (jvm_used_heap_size/jvm_max_heap_size) * 100.0

22060: New displays added to display member system resource usage

Two new displays (Member Summary - Process, Member Summary - JVM) have been added to the TIBCO Active Spaces solution pack to display member system resource usage. The Member Summary - Process display, displays current and historical process resource usage for a given metaspace member. Note: The metrics for the above display are only available for members where system monitoring has been enabled. Enabling system monitoring for a member is described in the TIBCO documentation. The Member Summary - JVM display, displays current and historical JVM resource usage for a given metaspace member. Note: The metrics for the above display are only available for Java members where system monitoring has been enabled. Enabling system monitoring for a java member is described in the TIBCO documentation.

22061: Additional resource metrics have been added to the history of the TasMembers cache

Additional selected member resource metrics have been added to the history of the TasMembers cache. The individual columns / metrics are described in The release note for 22059. The subset of additional columns used for history are listed in the "ALTER TABLE" commands, below. Users will need to update the table structure of the TAS_MEMBER historian table by executing the following alter table SQL sentences in your selected database administrative tool: DB2: ALTER TABLE "TAS_MEMBER" ADD "thread_count" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "res_mem_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "mem_load" FLOAT; ALTER TABLE "TAS_MEMBER" ADD "peak_res_mem_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "page_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "peak_page_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "process_cpu_load" FLOAT; ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_heap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_max_heap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_used_heap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_nonheap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_max_nonheap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_used_nonheap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_finalizing_count" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "JvmMemoryUsedPercent" DOUBLE ; SQL Server: ALTER TABLE [TAS_MEMBER] ADD [thread_count] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [res_mem_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [mem_load] FLOAT; ALTER TABLE [TAS_MEMBER] ADD [peak_res_mem_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [page_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [peak_page_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [process_cpu_load] FLOAT; ALTER TABLE [TAS_MEMBER] ADD [jvm_comm_heap_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [jvm_max_heap_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [jvm_used_heap_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [jvm_comm_nonheap_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [jvm_max_nonheap_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [jvm_used_nonheap_size] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [jvm_finalizing_count] BIGINT; ALTER TABLE [TAS_MEMBER] ADD [JvmMemoryUsedPercent] FLOAT; MySQL: ALTER TABLE "TAS_MEMBER" ADD "thread_count" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "res_mem_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "mem_load" FLOAT; ALTER TABLE "TAS_MEMBER" ADD "peak_res_mem_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "page_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "peak_page_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "process_cpu_load" FLOAT; ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_heap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_max_heap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_used_heap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_comm_nonheap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_max_nonheap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_used_nonheap_size" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "jvm_finalizing_count" BIGINT; ALTER TABLE "TAS_MEMBER" ADD "JvmMemoryUsedPercent" DOUBLE; Oracle: ALTER TABLE "TAS_MEMBER" ADD ("thread_count" NUMBER, "res_mem_size" NUMBER, "mem_load" FLOAT, "peak_res_mem_size" NUMBER, "page_size" NUMBER, "peak_page_size" NUMBER, "process_cpu_load" FLOAT, "jvm_comm_heap_size" NUMBER, "jvm_max_heap_size" NUMBER, "jvm_used_heap_size" NUMBER, "jvm_comm_nonheap_size" NUMBER, "jvm_max_nonheap_size" NUMBER, "jvm_used_nonheap_size" NUMBER, "jvm_finalizing_count" NUMBER, "JvmMemoryUsedPercent" REAL); SyBase: ALTER TABLE "TAS_MEMBER" ADD "thread_count" BIGINT NULL, "res_mem_size" BIGINT NULL, "mem_load" FLOAT NULL, "peak_res_mem_size" BIGINT NULL, "page_size" BIGINT NULL, "peak_page_size" BIGINT NULL, "process_cpu_load" FLOAT NULL, "jvm_comm_heap_size" BIGINT NULL, "jvm_max_heap_size" BIGINT NULL, "jvm_used_heap_size" BIGINT NULL, "jvm_comm_nonheap_size" BIGINT NULL, "jvm_max_nonheap_size" BIGINT NULL, "jvm_used_nonheap_size" BIGINT NULL, "jvm_finalizing_count" BIGINT NULL, "JvmMemoryUsedPercent" FLOAT NULL;

22062: TASMON enhanced with three new alerts

The new Alerts TasMemberCpuHigh, TasMemberMemoryUsedHigh, TasMemberJvmMemoryUsedHigh have been added. A new alert - TasMemberCpuHigh has been added. This alert will trigger when the Member CPU Used % goes above the specified threshold for the specified duration. This alert has a per member override available. A new alert - TasMemberMemoryUsedHigh has been added. This alert will trigger when the Member Memory Used % goes above the specified threshold for the specified duration. This alert has a per member override available. A new alert - TasMemberJvmMemoryUsedHigh has been added. This alert will trigger when the Member JVM Memory Used % goes above the specified threshold for the specified duration. This alert has a per member override available. Note: The metrics for the above alerts are only available for members where system monitoring has been enabled. Enabling System monitoring for a member is described in the TIBCO documentation. Also note, the metric for Jvm Memory Used %, is only available for java members where system monitoring has been enabled. Enabling System monitoring for a java member is described in the TIBCO documentation.

22063: New system resource metrics are available in the All Members Heatmap Display

New CPU %, Memory % and JVM Memory % system resource metrics are available in the All Members Heatmap Display. These Metrics are available to select from the Metric drop-down selector, and are visible in the cell mouse-over pop-up. Note: Note that these values are only present for members that have system monitoring enabled. For members without system monitoring enabled, the value for the metric is NaN (Not a number) and displayed appropriately. See the TIBCO documentation for how to enable system monitoring for metaspace members.

22113: "Misses" and "ToPersist" Metrics now display correctly in Summary displays.

Previously, under some circumstances, the "Misses" and "ToPersist" labelled metrics would not display the correct values, in Summary displays. This is no longer the case. Summary Displays consist of Metaspace Summary, Space Summary, Member Summary, and Member by Space Summary.

TIBCO Adapter

21899: New TIBCO Adapter Monitor Solution package

The TIBCO Adapter Solution Package TADMON has been included in RTView EM. This Solution Package allows monitoring of TIBCO Adapters, which connect to multiple technologies. These adapters are arranged in several categories depending on the type of the technology they integrate with TIBCO products. There are Technical Adapters (Eg. TIBCO ActiveMatrix Adapter for Database), Functional Adapters (Eg. TIBCO Adapter for Remedy), and custom (implemented by the TIBCO Adapter SDK). See the RTView EM User Guide for configuring the TADMON Solution Package.

TIBCO BusinessWorks

21965: Improved notification of stopped/expired BW6 appnodes and applications

In BW6 Monitor an appnode is marked as expired in the displays after a period of time has elapsed with no change in its data. This enhancement adds a new alert, Bw6AppNodeExpired, that you can enable for all or specific appnodes, to be raised at that time. If an application is stopped (e.g. by admin interface) its state will become "Stopped" in the application table. This enhancement adds a new alert, Bw6ApplicationStopped, that you can enable for all or specific applications, to be raised at that time. Note that whereas expired AppNodes may be removed from the displays after a specified time, Applications do not expire. If an application is undeployed and not redeployed, it will only be removed from the displays when the RTView dataserver is restarted.

21992: BWMON enhanced with a new and improved readme file

The README file for the RTView OSGi Plugin for BusinessWorks Monitor has been expanded and reorganized for greater clarity.

22014: New alert BwEngineUnreachable

BW Monitor has improved the way it detects and presents the status of BW Engines. 1. If an Engine is stopped normally its status will become STOPPED as before. Now this status will also be shown by highlighting the Engine's row in the All Engines table using a light pink color. This highlighting will also be used on the BW Processes and Activities associated with the stopped Engine. In addition the alert BwEngineStopped will be triggered if it is enabled. 2. If an Engine stops abnormally, e.g. crashes, the Hawk agent will report it as "unreachable", and BW Monitor now makes use of this information: the Engine status becomes UNREACHABLE and the Engine and its processes and activities become highlighted in their respective tables using the standard gray color. In addition a new alert BwEngineUnreachable will be triggered if it is enabled. Note that, as before, if the Hawk agent itself becomes unreachable, it will be marked Expired, along with all its engines and their associated processes and activities, and the BwServerExpired alert will be triggered if it is enabled.

22015: appnode status of "Expired" split into "Stopped" vs "Unreachable"

Previously an appnode would be marked Expired if data was not received from it for any reason. Now it will be marked either Stopped if it was stopped normally, e.g. by an admin comand, or Unreachable if it stops abnormally, e.g. the process crashes. In either case the appnode will be removed from the displays after 24 hours with no data. The Bw6AppNodeExpired alert has been replaced with two new alerts, Bw6AppNodeStopped and Bw6AppNodeUnreachable.

22017: New alert Bw6AppExpired

BW6 Monitor has been enhanced with Application expiration, defined as follows: an application expires when none of its processes has shown activity for longer than the expiration period, 10 minutes by default. Thus if an application is distributed across multiple AppNodes in an AppSpace, it will not expire as long as any one of its AppNodes is still running. An expired application will be highlighted in gray the All Applications table, and a new alert Bw6AppExpired will be triggered if it is enabled.

22035: BWMON enhanced with option to limit collection of activity and process data

If you want to reduce the amount of data collected by BW Monitor and you do not require BW Activity data, you may disable the collection of this data with the following property: collector.sl.rtview.sub=$bwActivitiesDisabled:1 Likewise, you may disable the collection of BW Process data with the following property: collector.sl.rtview.sub=$bwProcessesDisabled:1

22067: BW6MON enhanced with new alert

BW6 Monitor has been enhanced with a new alert Bw6AppErrorState which indicates that an application has encountered an error and thus is in some state other than Running or Stopped. The specific state (e.g. StartFailed) will be reported in the alert text. e.g. BW6 App is in error state "StartFailed".

22116: BW6MON AppNode table enhanced with new State column

The column State has been added to the BW6 AppNode table, with the values ACTIVE, STOPPED, UNREACHABLE. A corresponding text field has been added to the AppNode Summary display. In addition, the AppNode, AppSlice, Process, and Activity tables will display row highlighting for any AppNode in the Stopped or Unreachable states. Unreachable rows will be displayed in grey and Stopped rows in pink.

TIBCO EMS

21878: EMSMON enhanced with user-friendly headers

All EMSMON tabular displays have been enhanced with user-friendly headers. The displays are in the following menu options: All EMS Servers->All Servers Table Single EMS Server->Single Server Tables EMS Topics->All EMS Topics Table EMS Queues->All EMS Queues Table EMS Clients->Routes EMS Clients->Connections EMS Clients->Producers EMS Clients->Durables EMS Clients->Bridges, Users, Ports

21969: Background colors in EMSMON All Servers grid have been updated

The All Servers Grid display has been fixed to mimic the color indicators for Inactive Servers when EMS Servers were working correctly and went down. This will be indicated with the Expired flag set to true, which has been included in the composite object comprising the elements of the object grid. This addition will help to find EMS Servers that were working fine, but went down unexpectedly. For aesthetic consistency across all the displays under the All EMS Servers menu, the All Servers Table display has been enhanced to reflect the background color of Expired EMS Servers as Inactive. Also, in this same display, the font color from Inactive and FT Standby EMS Servers has been changed to be readable.

VMWare vSphere

21830: VMWMON enhanced to monitor hardware of esxi hosts

RTView VMWare Monitor has been enhanced to monitor the hardware components of the esxi hosts. The host hardware components are shown in the new Host Health table, and the System Vendor and Model are shown in new columns in the All Hosts table. The Host Health table has multiple components per host and sensors per component. It has a dropdown selector to filter the table by sensor type.

Version 3.7.0 Release Notes

Distribution

21836: MySQL now provided via Docker Hub

For the convenience of users who utilize Docker, the slcorp repo on Docker Hub now includes an image of MySQL Database configured to work with RTView. This container only works with Docker 1.10 and later. See rtvapm/containers/docker/mysql-rtview/README.txt for more information.

Drill Down

21887: Fixed an issue with navtrees

In previous releases, when drilling down from within a display to another display in the navtree, the tree selection sometimes failed to update correctly. This happened in the case where there were multiple navtree items for the same display with different subs and the user drilled down to that display from within another display. This has been fixed.

RTView Core Functionality

Alerts

21924: Fixed an issue with disabling event alerts

In previous releases, disabling event alerts was sometimes ignored due to a bug that was introduced in RTView Classic 6.7.0, RTView EM 3.2.0. This has been fixed.

Builder

21672: Builder enhanced to remember dialog window sizes and positions

The Display Builder has been enhanced to automatically save and restore the size and location of the following dialogs: - Open (File->Open) - Save (File->Save/Save-As) - Function Results (Function Dialog->Result Button) The Tools->Reset Window Layout menu option and the -resetlayout command line option restore the size and location of these windows in addition to the other windows that were previously reset.

Builder - Property Dialogs

15582: Japanese label for "Update Mode" property now shown on certain dialogs

Previously, the Japanese label for "Update Mode" property was not shown on certain polled ds attach to data dialogs when running on a Japanese OS. The English label was used instead. This is no longer the case. Affected dialogs include the custom polledds and polledds2 example data sources, and the http rest data source

Data Server

21898: Fixed an issue with rtvquery returning errors on valid query strings

In previous releases, the rtvquery servlet would sometimes return an error of "No data received before timeout, query may be invalid" for a specific, valid cache query string, on every attempt. The servlet needed to be restarted to clear the error. This has been fixed.

Data Sources

21689: Fixed an issue with the "Extend with SQL" cache feature

In prior releases, the "Extend with SQL" feature of the cache data source could cause thread growth if the history database connection was undefined or unavailable. This is now fixed.

Display Server

21906: Thin client enhanced to check user role access on each request

In prior releases, after a user had logged into the thin client, the user could manually enter a specific URL in the same browser instance and possibly view data from rtview displays to which the user's role should have denied access. This is fixed.

21908: Enhanced display server with option to limit access to specific panel files

The display server now supports a "permitpanel" option to specify the panel layout files that the server will read. A panel layout for the thin client is requested from the display server with a URL parameter as follows: panels.jsp?file=X where X is the name of the panel layout file that the server should read. By default, the display server will attempt to read any filename on the server that is specified by the URL parameter. If the file is a valid panel layout file, the thin client will use it. But if the file does not exist, a "no such file" error is displayed in the browser, and if the file exists but does not contain the expected layout information, a "no panels found" error is displayed in the browser. The permitpanel option allows you to specify the file(s) which the display server will read in response to a panels.jsp request. Requests from panels.jsp for any other files are rejected with a "Permission denied" error shown in the browser, regardless of whether the file exists or not, and the server will not attempt to read such files. The option may be specified multiple times to allow access to multiple panel files. Command-line example: run_displayserver -permitpanel:PANELS.ini -permitpanel:layout.xml DISPLAYSERVER.ini example: permitpanel PANELS.ini permitpanel layout.xml In addition, the display server supports another new option to prevent attempts to load remote files, as follows: -permitfile:LOCAL_ONLY If that option is specified any rtv or image files that are referenced by URL will not be read and the server will log a message similar to the following: non-local file read permission denied: http://host/somefile

21912: Fixed phishing vulnerabilities in thin client

In prior releases, it was possible to create phishing URLs which appeared to be directed at the rtview thin client but would redirect the user to another site, or download and possibly execute a file. These vulnerabilities have been fixed.

Platform Support

21871: RTView upgraded to Java 1.7

RTView is now built with Java 1.7. Java 1.6 is no longer supported.

Solution Package

Docker

21913: Docker Engine and Container heatmaps now indicate expiration

Previously Docker Engine and Container heatmaps did not indicate expiration of their respective entities. This is no longer the case. Entities in the heatmap change color to indicate expiry.

MySQL

21791: New MySQL Monitoring Solution Package

The Solution Package for MySQL has been added to the list of monitoring Databases under RTView EM. The monitoring data for this Solution Package is collected under the servers/miscmon dataserver. Please refer to the RTView EM documentation for information about configuration and troubleshooting.

21968: Alert names have been optimized

To follow the RTView standard naming convention of limits alerts with high thresholds, the following alerts have been renamed: MysqlSlowQueries, MysqlLocksWaited, MysqlQcacheLowMemPrunes, MysqlSlowThreads, and MysqlDelayedWrites. These alerts are now named: MysqlSlowQueriesHigh, MysqlLocksWaitedHigh, MysqlQcacheLowMemPrunesHigh, MysqlSlowThreadsHigh, and MysqlDelayedWritesHigh, respectively.

Oracle Coherence

21644: Added new configuration option to display invocation only clusters

Invocation only clusters (those with no storage nodes or caches) require additional configuration to be monitored. This requires that one invocation only cluster be monitored at a time by a suitably configured data server. Configuration for use with an invocation cluster takes the form of a properties file that must be edited by the user before use. The properties file is called invocationonly.properties and can be found in the sample project directory. You will need to edit the invocationonly.properties file, to set the ACTUAL_CONN_NAME placeholder to the value of the sl.rtview.jmx.jmxconn property used to connect to the invocation only cluster. e.g. consider using the named connection "MyInvocationCluster" Then you would have the property sl.rtvapm.ocmon.jmxconn=MyInvocationCluster and you would need to to edit the property line in invocationonly.properties from maincollector.sl.rtview.cache.config=oc_connection_dummy_cache_store.rtv $conn:ACTUAL_CONN_NAME $cache:OcStorageDataRaw $file:ocmon_ts_constants.xml $table:DummyOcStorageDataRaw to maincollector.sl.rtview.cache.config=oc_connection_dummy_cache_store.rtv $conn:MyInvocationCluster $cache:OcStorageDataRaw $file:ocmon_ts_constants.xml $table:DummyOcStorageDataRaw When the invocationonly.properties has been edited this way, it can be used to configure the monitoring dataserver by using the command line argument -properties:invocationonly either on the command line when launching the dataserver, or adding it in the rtvservers.dat entry used to launch the monitoring dataserver.

21763: New Cluster MBean Servers display has been added

A new Cluster MBean Servers display has been added that lists information on currently detected remote JMX management enabled MBean Servers within the cluster. The new Cluster Bean Server display is accessible from the OC Metrics Administration display, by clicking on the "Cluster MBean Servers" Button. This will bring up the Cluster MBean Servers display. The Cluster MBean Servers display lists the currently detected remote JMX management enabled Mbean Servers, in the currently selected cluster. Information displayed includes the hostname and IP address of the cluster node, and the port used for remote JMX management.

21764: New displays for federated cache information have been added

Coherence now allows you to federate caches across clusters. New displays allow you to monitor federation performance and throughput. The new displays are under the Federated Clusters tab in the nav tree. Detail and Summary displays are available for performance statistics derived from the cluster Destination and Origin MBeans. The Detail displays show the current information for all participating nodes for a selected cluster. This information may be restricted to a single host if desired. You can drill down on an individual node in the Detail display to display Summary information for that node. Summary displays show current information, and trended historical rate information. Destination information shows how efficiently each node in the local cluster participant is sending data to each destination cluster participant. Origin information shows how efficiently each node in the local cluster participant is receiving data from destination cluster participants.

21765: New Cache Size Alerts

New alerts are available to monitor cache sizes and alert if thresholds are exceeded. A new alert - OCCacheSizeHigh has been added. This alert will trigger when the cache size 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. Given that cache sizes vary, if you are only interested if the size of specific caches exceeds specific thresholds, it may be preferable to use the Per Cache, or Per Storage Class Override settings, allowing you set specific thresholds for specific caches. e.g. If the size of the "DistributedCacheForMessages" caches exceeds a specific size. A new alert - OcCacheOCCacheSizeLow 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. Given that cache sizes vary, if you are only interested if the size of specific caches goes below specific thresholds, it may be preferable to use the Per Cache, or Per Storage Class Override settings, allowing you to set specific thresholds for specific caches. e.g. If the size of the "DistributedCacheForMessages" cache goes below a specific size. These alerts are disabled by default as appropriate threshold values and overrides will vary by installation and will need to be set accordingly.

Oracle Weblogic

21835: Fixed a few typos in alert descriptions

Fixed typos in the alert description of the following two alerts: WlsServerStaleData and WlsPendingRequestCurrentHigh.

TIBCO ActiveSpaces

21738: Fixed an issue with gaps in trend chart data

A bug that prevented the Response Time trend from the Metaspace Summary display to show gaps when the data server was disconnected for more than 5 min has been fixed.

TIBCO BusinessEvents

21863: TIBCO BE Monitor enhanced to connect to TIBCO APIX solutions

TIBCO APIX is a solution with TIBCO BE engines defined with certain rules and events. Customers can now configure TBEMON to monitor TIBCO APIX BE engines. To monitor an APIX BE engine you will include two new files via cache.config properties: tbe_cache_source_be5.1_asg_cacheagent.rtv tbe_cache_source_be5.1_asg_inferenceagent.rtv Note you will need separate connections for cache and inference to a single engine process Include properties like the following in your runtime properties file. asgCacheConn, asgInferConn are arbitrary but distinct names, e.g "asgcache_4456, asginter_4456" #collector.sl.rtview.jmx.jmxconn=<asgCacheConn> <hostname> <port> URL:- - - 'false' #collector.sl.rtview.jmx.jmxconn=<asgInferConn> <hostname> <port> URL:- - - 'false' #collector.sl.rtview.cache.config= tbe_cache_source_be5.1_asg_cacheagent.rtv $tbe_conn:<asgCacheConn> $tbe_cluster:<clusterName> #collector.sl.rtview.cache.config=tbe_cache_source_be5.1_asg_inferenceagent.rtv $tbe_conn:<asgInferConn> $tbe_cluster:<clusterName>

21872: Enhanced sorting on the TBEMON All Agents table

The All Inference Agents table is now sorted by agentId by default

TIBCO EMS

21911: Aggregation of queue/topic caches now using sum instead of average

The compactionGroupBy attribute from the EMS Queue and Topic Extended Caches has been changed from sum to average.

VMWare vSphere

21805: VMWare Monitor enhanced with Datastore information

VMWare Monitor has been enhanced with the addition of information about Datastores. The navtree has a new section, Datastores, containing three tables and a summary display. The Datastores Table lists all the datastores on a server with their type, capacity, utilization, free space, etc. The Hosts by Datastore Table and VMs by Datastore Table show which datastores are in use by which hosts and VMs. The Datastore summary shows information about a single datastore, including its utilization and free space over time.

21824: VMWare Monitor enhanced with hardware information

VMWare Monitor has been enhanced with the addition of information about hardware components. The Hosts section of the navtree has a new entry: Host Health. Here you will find information on each component such as the sensor type, current reading, and state of the component.

21825: Enhanced VMWare Monitor with cluster information

VMWare Monitor has been enhanced with the addition of information about Clusters. The navtree has a new section, Clusters, containing the All Clusters Table, which lists all the clusters on a server with their overall status, HA configuration, etc. The Hosts table also has a new column showing the cluster to which the host belongs.

21828: VMWare Monitor enhanced with Host NICs information

VMWare Monitor has been enhanced with the addition of information about Host NICs. The Hosts section of the navtree has a new entry, Host NICs, which displays two tables, Physical NICs and Virtual NICs. Here you will find information such as the link speed of a physical NIC or the IP address of a Virtual NIC.

21831: VMWare Monitor enhanced with vSphere information

VMWare Monitor has been enhanced with the addition of information about vSphere Events and Alarms. The navtree has a new section, Events/Alarms, containing the All Events Table and the All Alarms Table. Information about Events includes the class, type, and message text. Information about Alarms includes the alarm name and description and the acknowledgement status.

Version 3.6.0 Release Notes

Data Model

21354: EM enhanced to support same service name across multiple groups and environments

Enterprise Monitor has been enhnaced to support using the same service name in multiple Groups and in multiple Environments. The CMDB Administration display has been enhanced to support this as well. With the new changes, all entries must have an Environment. Previously saved cmdb entries that do not have an Environment can no longer be edited or viewed in the CMDB Administration display although they are still visible in the Service Summary displays. Upgrade Notes: In order to support using the same service name in multiple Environments, the schema for the RTVCMDB database has been changed to add the Environment column to the table index. Existing projects from previous releases will continue to work against an RTVCMDB database without this index. However, if you have an existing project and you want to take advantage of this new feature, you will need to add the Environment column to the table index and fill in an Environment for any entries where it is blank.

Deployment

21748: Fixed an issue where Unix data servers sometimes failed to shut down

In previous releases, using stop_rtv on Unix platforms to stop a TIBCO solution package data server process sometimes failed due to a spurious rvd process. This has been fixed.

Distribution

21846: New RTView Monitor for Solace - AMI option

RTView Monitor for Solace is now available pre-installed on an Amazon EC2 Amazon Machine Image (AMI) running Amazon Linux. It comes pre-installed with a 30-day license, and is configured to start all RTView processes and supporting services on restart. The AMI includes the following application stack for convenience of quick deployment. Please refer to /home/ec2-user/amibase/MANIFEST.txt for the full version info: Oracle Java 8 Node Docker MySQL 5.7 (via Docker) for storage of historical data rtvHostAgent (via Docker) for providing host metrics to RTVMGR cadvisor-rtview (via Docker) for providing docker metrics to RTVMGR The scripts used to create the docker containers are included in named subdirectories under /home/ec2-user/amibase, to be used as templates if you wish to recreate the containers with your preferred configuration. The MySQL database data is stored external to the docker container at /home/ec2-user/amibase/mysql/DATA. Initial Setup: You may gain access to the community rtvsolmon-VERSION-YYYYMMDD-community AMI via sl.com, at http://sl.com/solace-ami-free-trial/. We recommend starting with an instance from the t2 family, sized according to the number of Solace appliances you are monitoring. Depending on how much archival data you wish to store in the database, you may wish to increase your disk size past the default 8 GB of the AMI. After creating an instance from the rtvsolmon-VERSION-YYYYMMDD-community AMI, you will need to SSH to your instance to add the connection properties for your Solace appliance(s) to /home/ec2-user/RTViewSolaceMonitor/em-solmon/servers/solmon/sample.properties. Please see the User Guide for full details.

General

21205: Thin client table objects are now rendered as HTML5

The table objects in the EM thin client have been enhanced to provide improved filtering, sorting, and other interactive features. See the release note for 20185 for a detailed description of the new table features.

21813: Fixed an issue with group objects and wrapped diagrams

In the previous release, if the first object in a wrapped diagram was defined to be included in a group, it was not included in the group object. This has been fixed.

RTVMGR

21739: Enhanced the All JVMs Heatmap display with a Source drop down

A drop down for Source has been added to the All JVMs heatmap display.

21740: Enhanced the All JVMs Table display with a Source drop down

A drop down for Source has been added to the All JVMs Table display.

21754: Fixed an issue preventing JVM Runtime data collection

A bug that prevented collection of JVM Runtime data from several versions of Java (6, 7 and 8 versions) has been fixed.

21792: Enhanced the All JVMs Table display with more columns

PID, Host Name, Current Heap, and Used Heap have been added to the All JVMs Table display.

21793: Enhanced the All JVMs Heatmap display

The All JVMs Heatmap display from RTVMGR Solution Package has been enhanced to include PID, Current Heap, and Used Heap. The last two metrics are also included in the Metric drop down.

21838: Enhanced RTVMGR in SOLMON Bundle

The RTVMGR configuration has been enhanced in RTView Monitor for Solace. It now includes monitoring for a MySQL Database, as well as Host and Docker metrics. For users of the RTView Monitor for Solace AMI version, all connection properties populate these displays have been pre-configured in the standard sample.properties file and do not require further configuration. Users of the On Premise version will not see data in the Host or MySQL displays unless they choose to configure these.

RTView Core Functionality

21668: Enhanced caches with new initialization option

BACKGROUND: If a cache's schemaTable property is not specified, then the cache's schema (column names and types) is copied from the first data table applied to the cache that contains at least one data row. Data tables that contain columns but no rows are ignored. In some configurations that can delay cache initialization and cause undesired behavior in functions and displays attached to the cache. ENHANCEMENT: An option has been added to the cache data source to initialize a cache's schema from the first data table applied to the cache, even if the table contains zero data rows. The new option can be specified on the command-line as follows: -cacheds:storeempty Or in CACHEOPTIONS.ini as follows: storeempty true Or in an rtview properties file as follows: sl.rtview.cache.storeempty=true The new option is disabled by default. If the new option is not specified, the cache's schema is initialized by the first data table containing at least one data row that is applied to the cache, as in all prior releases. If a cache's schemaTable property is specified then the cache's schema is always initialized from that table, as in prior releases, regardless of the new property setting.

Alerts

21677: Enhanced Alert data source

The Alert data source has been enhanced to support a new table named Alert Definitions. This table contains a row for each alert with the following columns: Alert Name - the name of the alert File Name - the name of the file containing the alert definition Substitutions - the substitutions specified when the alert definition file was loaded.

21795: Fixed an issue where the Cleared Reason for an alert was incorrect

In prevous releases, the Cleared Reason was sometimes incorrect after an alert was disabled and re-enabled. This has been fixed.

Data Historian

21699: Enhanced Historian compaction to avoid long delays

The Historian smooth compaction code no longer performs a row count. This prevents long delays during smoothing by avoiding Select Count(*) calls.

Data Sources

21522: Added new HTTP Data Adapter

The RTView HTTP Data Adapter embeds a HTTP server in RTView to handle data sent as HTTP Requests. When enabled, the embedded HTTP server is opened on a specified port, and delegates requests to handlers on given URLs. The RTView HTTP Data Adapter comes with two default handlers that allow data to be sent to RTView applications by means of JSON data in a specific format as HTTP POST requests. This JSON data is mapped to GmsTabularData and can be used to update RTView function chains or write to RTView caches directly. RTView can be updated by clients that can send HTTP POST requests, containing JSON data. Handlers receive the data, map the data to GmsTabularData, and then perform actions with that data. The default handlers are contained in the gsmjhttpds.jar. They expect JSON data in the same format as output by the rtvquery servlet when fmt=json. If no metadata is present, all columns are defined as string type. The rtvquery JSON response format is defined as: { "metadata":[ {"name":"column 1 name","type":DataType}, ... metadata for other columns ... ], "data":[ {"column 1 name":"row1, column1 value", ... data for other columns in row 1}, ... data for other rows ... ] } The expected format is a JSON object that can be mapped to GmsTabularData. The JSON object has two named members: "metadata" describing the metadata (column names and types for the following data), and "data" containing the data values. The "metadata" member is a name:value pair where the value is a JSON array of JSON objects, one per column. The column metadata objects have two members: "name" and "type". The "name" member is a name:value pair with the column name as its value. The "type" member is a name:value pair with the column type as its value. Valid column types are GmsTabularData column types: "string", "long", "int", "double", "float", "date", "boolean". The metadata is used to define the column types for the mapped GmsTabularData. If the metadata member is not present, the mapped GmsTabularData will use "string" for all columns. The "data" member is a name:value pair where the value is a JSON array of JSON objects, one per row of data in the mapped GmsTabularData. Each row is a JSON object, with member name:value pairs, one per column. Each column member is a name:value pair, where the name is the name of the column, and the value is the value of that column for that row. When the RTView HTTP Data Adapter is enabled (using the default RTVHTTPOPTIONS.INI file, contained in custom\rtvhttp), it has the following options set: Enabled: true Port: 9099 Root Url: /rtview Use HTTPS: false And sets the following RTVHttp Handlers DEFAULT_CACHE_WRITER Handler Name:DEFAULT_CACHE_WRITER Java Class: com.sl.gmsjhttpds.DefaultJsonCacheWriter Handler URL: /write/cache/ DEFAULT_JSON_HANDLER Handler Name:DEFAULT_JSON_HANDLER Java Class: com.sl.gmsjhttpds.DefaultJsonHandler Handler URL: /json/data/ DEFAULT_JSON_HANDLER is the Default Handler. The default handlers are contained in the gsmjhttpds.jar. They expect JSON data in the same format as output by the rtvquery servlet. If no metadata is present, all columns are defined as string type. HTTP POST requests to /rtview/json/data/<table_name> will be handled by the DEFAULT_JSON_HANDLER, which will make the data available via rtvhttp data attachments using the supplied <table_name>. Data sent to /rtview/json/data/<table_name> will be output by RTView HTTP data attachments, where the "Handler Name:" is set to DEFAULT_JSON_HANDLER, and the "Table Name:" is specified as the <table name> in the URL. For Example: Data sent to /rtview/json/data/MyData1 would be output by RTView HTTP data attachments, where the "Handler Name:" is set to "DEFAULT_JSON_HANDLER", and the "Table Name:" is "MyData1". Likewise, data sent to /rtview/json/data/MyData2 would be output by RTView HTTP data attachments, where the "Handler Name:" is set to "DEFAULT_JSON_HANDLER", and the "Table Name:" is "MyData2". Different data can be input to different function chains by being sent to different URLs in this way. HTTP POST requests to /rtview/write/cache/<cache_name> will be handled by the DEFAULT_CACHE_WRITER, which will write the data to the current table of the named cache, <cache_name>. Since the data is written to the cache directly by the handler using the cache name in the URL, no data attachments need be configured in this case. For Example: Data sent to /rtview/write/cache/CACHE1 would be written to the current table in cache "CACHE1". Likewise, data sent to /rtview/write/cache/CACHE2 would be written to the current table in cache "CACHE2". Different data can be written to different caches by being sent to different URLs in this way.

21669: Enhanced caches with new trim option

An option has been added to the cache data source to remove rows periodically from a cache's history table according to its historyTimeSpan property. By default, that operation is performed only when new data is applied to the cache. The new option is useful in rare cases where new data may be applied to the cache at time intervals (e.g. 1 hour) that are longer than the cache's historyTimeSpan (e.g. 30 minutes). The new option can be specified on the command-line as follows: -cacheds:trimhist Or in CACHEOPTIONS.ini as follows: trimhist true Or in an rtview properties file as follows: sl.rtview.cache.trimhist=true If the new option is specified, the historyTimeSpan limit is checked on all caches every 30 seconds, approximately. The new option is disabled by default. If the new option is not specified, then the historyTimeSpan limit is only checked when new data is applied to the cache as in all prior releases.

21851: An issue with the handling of the onTermination event has been fixed

In a previous version, in task 21299, a bug was introduced to the onTermination() error handling. In some cases, it would cause all data from the microagent that sent the error to stop coming into RTView. This has been fixed.

Display Server

21772: Extra-bold font in Firefox fixed

In the previous release, objects using font index 7 (sans-serif bold) would appear extra bold in some versions of Firefox if the display server was configured to use the extended font feature with arimob.ttf assigned to font 7. This has been fixed.

21853: Fixed an issue with small numbers not updating to zero in the thin client

In previous releases, the value displayed in an obj_rect_ilv object would not change if the previous value was greater than zero and less than one, and a value of zero was applied. This problem occurred only in the thin client and is now fixed.

Object Library

21675: Enhanced charts with properties for legend text

Properties named legendTextFont and legendTextSize have been added to obj_trendgraph02, obj_bargraph, and obj_pie to allow the user to choose the font and size for legend text. Previously the legends on those objects always used SansSerif at 9 pixels (trend) or 10 pixels (bar and pie) . Those are now the default values for the new properties.

Scripts

21714: Added Unix scripts to create .war files for a given solution package

The script make_package_wars.sh has been added to the rtvapm distribution. Like make_package_wars.bat, it is used to create an initial set of war files for a given solution package. The war files are created in the <package>/webapps directory. After they are created, update_wars.bat/sh should be run to update them with the correct port numbers. The scripts should be run from the <package>/webapps directory. They take the package name as argument, e.g. "make_package_wars.sh bwmon".

21771: Fixed an issue where ports were misidentified

The rtvapm start/stop/status scripts, when testing the ports of a given server, would incorrectly identify a port as "taken" whose number contained the server's number with a leading or trailing digit. (For example finding 33675 in use and saying 3675 is taken.) This has been corrected.

Service Model

20803: Enhanced EM to support removal of CI's no longer in data server

EM has been enhanced to support removing CI's that are no longer in the backend data server. In previous releases, CI's were never removed from central EM even if they were no longer in the backend data server that hosted the data for that CI. With this change, the CI is removed from central EM when it is deleted from the data server that is hosting it.

Solution Package

21847: EM enhanced with Sender/Receiver Mode

EM has been enhanced to support a sender/receiver deployment option for all solution packages. The sender/receiver mode is an EM deployment model where the sp data that is collected in one data server (the sender) is sent to another data server (the receiver). The sender directly connects to sp data, populates its local sp caches then sends that cache data to the receiver. The receiver may or may not be configured to collect data as well. The sender does not generate alerts or store history - those are done in the receiver. This is useful in cases where you need to run a data server to collect sp data on a system that is not accessible from the system where you are running the ui and/or EM central servers. To configure your project for the sender/receiver deployment: 1. Confirm that both the sender and receiver data servers are running the same version of EM. This is a requirement for the sender/receiver deployment. 2. By default, the receiver will open an rtvagent port to receive cache data from the sender. Lookup the port number under rtvapm\pck\conf\rtvapm.pck.properties (where pck is the name of the solution package in your receiver) in this property: receiver.sl.rtview.rtvagent.port=1234 (where 1234 is the port number) 3. If that port is already in use, override it in the properties file for your receiver to set another port: receiver.sl.rtview.rtvagent.port=5678 4. If your sender will be unable to directly connect to the rtvagent port, deploy the RTVAgent Servlet and note the url of the servlet. 5. Run the receiver with the receiver property filter command line option: -propfilter:receiver 6. By default, the sender will send to the port you looked up in step 2 on the local system. To send to a different port, different system or to the rtvagent url, override the dataxfr.target property in the properties file for your sender: sender.sl.rtvapm.dataxfr.target=id=default url=<your url goes here> packages=all Some examples: sender.sl.rtvapm.dataxfr.target=id=default url=http://localhost:8068/miscmon_rtvagent packages=all sender.sl.rtvapm.dataxfr.target=id=default url=receiverhost:1234 packages=all Note that the target id is default. This will override the default value. 7. If you want your sender to send data to multiple receivers, add a dataxfr line for each receiver. Each line must have a unique id. You can optionally list the packages for which you want to send data (if you want to send different package data to different receivers) or specify all to send caches for all packages for which the sender is configured. For example: sender.sl.rtvapm.dataxfr.target=id=emsmon_target url=http://localhost:8068/emsmon_rtvagent packages=emsmon sender.sl.rtvapm.dataxfr.target=id=rtvmgr_target url=http://localhost:8068/emsmon_rtvagent packages=rtvmgr sender.sl.rtvapm.dataxfr.target=id=bwmon_target url=http://localhost:8068/bwmon_rtvagent packages=bwmon;hawkmon;hostbase Note that each target above has a unique id. You can optionally disable the default target as follows: sender.sl.rtvapm.dataxfr.target=id=default packages=__none 8. Run the sender with the sender property filter command line option: propfilter:sender UPGRADE NOTES In previous releases, some of the solution packages supported a sender/receiver deployment. This task has modified the previous implementation and made it available to all solution packages. Customers with existing projects from a previous release that were using the sender/receiver deployment will need to modify their properties files after upgrading in some cases: 1. If the project properties files overwrite the sender.sl.rtview.sub=$rtvAgentTarget property, they will need to change it to use the new sender.sl.rtvapm.dataxfr.target property using the url they had specified for the $rtvAgentTarget. For example, sender.sl.rtview.sub=$rtvAgentTarget:'localhost:3172' would be changed to sender.sl.rtvapm.dataxfr.target=id=default url=localhost:3172 packages=all 2. If the project properties files adds additional targets using the sender.sl.rtview.cache.config property, they will need to change it to use the new sender.sl.rtvapm.dataxfr.target property using the url they had specified for the $rtvAgentTarget and a new unique id. For example, sender.sl.rtview.cache.config=pck_rtvagent_sender.rtv $rtvAgentTarget:'otherhost:3172' sender.sl.rtvapm.dataxfr.target=id=target2 url=otherhost:3172 packages=all 3. If the project properties file did not overwrite either of the above, it just used the default sender/receiver properties, no changes are needed.

General

21659: Sender/Receiver servlet removed from Custom Solution Package

The rtvagent war is not included in the custom solution project because the sender-receiver capability is not implemented at this time.

21688: Downgraded bundled Tomcat to version 7.0 due to log errors

The Apache Tomcat server that was included with RTView Monitor for Solace and the RTView Enterprise Monitor for TIBCO has been changed from version 8 to version 7. This enabled more monitoring metrics, and addressed the following errors in the /servers/solmon/logs/dataserver.log file: ERROR: function <tomcatWebModuleStats04DeltaRate>, Table structure has changed; cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv ERROR: function <tomcatManagerStats77DeltaRate>, Table structure has changed; cannot save data., type:DELTARATEROWS, file:tomcat_cache.rtv

Solace

21697: Fixed an issue preventing Tomcat from stopping cleanly

A bug that prevented Tomcat from stopping cleanly on UNIX and Linux systems has been fixed. The CATALINA_PID variable is now defined in the Tomcat setenv.sh script for these systems. Also, the start_tomcat.sh script requirement of JAVA_HOME being set in the environment has been changed to require Java available in the PATH. This change will allow starting RTView processes at startup before the user environment has been set.

21786: All Endpoints Table display enhanced with two new check boxes

Two new check boxes to filter by Expired and Down have been added to the All Endpoints Table display.

21787: All VPNs Table display enhanced with two new check boxes

Two new check boxes to filter by Expired and Disabled have been added to the All VPNs Table display.

21788: All Clients Table display enhanced with two new check boxes

The All Clients Table display has been enhanced by adding two check boxes to filter by Expired and Internal. By default, Expired and Disabled check boxes are unchecked, meaning that only non-expired of the Primary Type Clients are shown. When checked, all Clients, expired and non-expired as well as Primary and Internal will be respectively shown.

21789: All CSPF Neighbors Table display enhanced with two new check boxes

Two new check boxes for State Ok and Expired have been added to the All CSPF Neighbors Table display. By default both check boxes are unchecked, meaning that all non-expired CSPF Neighbors are shown. When Ok is checked, only CSPF Neighbors with State=Ok are shown. When Expired is checked all CSPF Neighbors, expired and non-expired are shown in the table.

21790: All Bridges Table display enhanced with two new check boxes

Two new check boxes for "Disabled" and "Expired" have been added to the All Bridges Table display. By default the "Expired" check box is unchecked, meaning that only non-expired Bridges are shown, and the "Disabled" check box is checked, which shows all Bridges regardless of their Admin State. When "Disabled" is unchecked, only enabled Bridges with Admin State=Enabled are shown. When "Expired" is checked, all expired Bridges are shown in the table, in addition to the non-expired Bridges.

21799: CSPF cache enhanced with Ingress/Egress metrics

Ingress and Egress metrics for CSPF Neighbor Msg Routers have been added.


21800: New CSPF Ingress/Egress metrics are now available

Ingress/Egress metrics for CSPF Neighbor Msg Routers have been stored in history from the CSPH Neighbor cache. The table creation SQL statement for supported platforms is located in solmon/dbconfig directory. The name of the table is SOL_CSPF_NEIGHBOR. By default, data is being stored in history for this table. To disable storage of historical data, edit the sample.properties file and uncomment the following property: collector.sl.rtview.sub=$SOL_CSPF_NEIGHBOR_TABLE:''

21801: SolAppliances cache enhanced with two new metrics

Two new metrics have been included in the SolAppliances cache. Host Address and Connected. The later keeps track of the connection state of the Msg Router.

21803: Message Router Summary display enhanced with Host Address

The Host Address has been added to the header of the Msg Router Summary display.

21804: EM enhanced with a new alert

A new alert,SolMsgRouterNotConnected, has been added. This alert will be executed when the Msg Router is not ready for collecting monitoring data.

21807: SOLMON tables functionality enhanced

All tabular displays now select a row by single clicking and drill down to the corresponding summary by double clicking. The enhanced displays are the following: - Message Routers->All Message Routers Table - Neighbors-> CSPH Neigbors Table - VPNs->All VPNs Table - Clients->All Clients Table - Bridges-> All Bridges Table - Endpoints-> All Endpoints Table - Capacity Analysis-> All Msg Routers Capacity

21808: All Msg Routers Heatmap display has been enhanced

Two check boxes, "Connected" and "Expired", have been added to the All Msg Routers Heatmap display.

21809: Enhanced some displays to correctly align their contents

The Msg Router and the Capacity displays for the corresponding menu tags have been enhanced to correctly align their contents.

21810: Enhanced EM with a new page for CSPF Neighbors

The CSPF Neighbor Msg Router displays have been organised under a new menu tab named Neighbors.

21812: Msg Router VPN Activity display has been enhanced

The Msg Router VPN Activity display has been enhanced to show the most active VPNs sorted by Client Connections, Ingress/Egress bytes / sec and Pending Msgs. The number of VPNs shown is adjusted to the height of the window.

21814: EM enhanced with new metrics

In Msgs /sec and Out Msgs / sec have been added to the SOLMON-MSGROUTER CI Type as Key Metrics.

21817: Trend Value precision is now one decimal value in Client Summary display

The precision of the trend values has been changed to one decimal value in the Client Summary display.

21827: Enhanced EM by standardizing colors across multiple displays

The following displays have been improved to follow RTView EM standards on color trends: - Message Router Capacity Summary - Message Router Capacity Trends - Single Message Router Summary - Single Bridge Summary - Single Client Summary - Single Endpoint Summary - Single VPN Summary

TIBCO BusinessEvents

20670: About and Version Info displays added to TBEMON

Two new displays have been added to TBEMON: an About display that shows general information about the running application, and a Version Info display that provides detailed information about the libraries used for each of the TBEMON applications.

TIBCO BusinessWorks

21723: Fixed a bug on the All Engines table where engines misreported their statuses

When you drilled down to an engine from the All Engines table and returned to the table, the Active Processes column would display NaN or Not Available for every engine other than the one to which you drilled down. This has been fixed. Note: the Active Processes column will display NaN or Not Available for any engine whose status is STOPPED.

21781: Solution packages using Hawk enhanced with custom setup scripts for Unix

The solution packages that use the Hawk data adapter include bwmon, bw6mon, amxmon, and hawkmon. On Unix systems they require that Tibco RV be included in the environment variable LD_LIBRARY_PATH. Specifically, RV_ROOT must be defined and LD_LIBRARY_PATH must contain $RV_ROOT/lib. These packages now include custom_setup.sh files, which are automatically executed when rtview programs start up. These files will modify LD_LIBRARY_PATH correctly, whether it was previously defined or not.

21796: The monitor has been enhanced to support OSGi

RTView monitor for Tibco BusinessWorks has been enhanced with the ability to monitor BW applications deployed in BW6 AppSpaces using the new RTView OSGi Plugin for TIBCO BusinessWorks. An application using the OSGi plugin does not require the use of Hawk for monitoring purposed. For information on enabling and configuring the OSGi Plugin please refer to the documentation and/or the online README file.

21797: RTView enhanced to monitor BW inside a Docker container

RTView monitor for Tibco BusinessWorks has been enhanced with the ability to monitor BW applications deployed in Docker containers, using the new RTView OSGi Plugin for TIBCO BusinessWorks. For information on enabling and configuring the OSGi Plugin please refer to the documentation and/or the online README file.

21843: Data Types on the Monitor Process table have been optimized

In the BW6 Monitor Process table the columns Average Execution Time and Average Elapsed Time were displayed as type Long, where they should be Double. This has been corrected.

21844: RTView enhanced to monitor BW in PCF

RTView monitor for Tibco BusinessWorks has been enhanced with the ability to monitor BW applications deployed in Pivotal Cloud Foundry containers, using the new RTView OSGi Plugin for TIBCO BusinessWorks. For information on enabling and configuring the OSGi Plugin please refer to the documentation and/or the online README file.

21867: Fixed a column formatting issue in BW6

The BW6 AppNode table "Up Since" column actually represents the "uptime", or time the appnode has been running, but it was not formatted as a duration. This has been corrected.

21868: Fixed the default sort order for all BW6 tables

The display tables in the BW6 monitor are now sorted by default according to their index columns.

21893: History tables BW6_APPS and BW6_APPSLICES no longer created

The Bw6App and Bw6AppSlice caches were incorrectly creating database tables. These caches do not store their own history; their history metrics come from aggregations of the Bw6Process cache history. The BW6_APPS and BW6_APPSLICES tables have been removed from configuration files and database schemas.

TIBCO EMS

21755: Added new filter for EMS connections by User

A new filter by User Name has been added to the EMS Connections for Server display.

21848: EM enhanced with a new alternate alert for when EMS Consumers are stuck

An alternate alert to detect when EMS Consumers are stuck has been developed. The reason for that is the current emsConsumerStalled alert is based on the difference between: totalMsgSentCount > totalMsgAckCount AND elapsedSinceLastAck > the alert threshold. However, this may not be an accurate measure of consumer stalled for some customers in which all processed messages might not be acknowledged. In these scenarios, the following condition is more appropriate: currMsgSentCount > 0 AND elapsedSinceLastAck > the alert threshold The new alert is called emsConsumerStuck.

Version 3.5.0 Release Notes

Alerts

21663: New MQ alert for channel status has been added

A new alert, MqChannelInactive, has been created. This alert will be executed when non-system channels have the Status metric set to a value different than RUNNING.

General

21640: New Diagram Generator has been added

RTView Enterprise Monitor has been enhanced with a new Diagram Generator package. The Diagram Generator allows you to store node, link, and layout information in a database and generate diagrams based on this information. The CUSTOM tab in the emsample project has been enhanced to include the Diagram Generator administration displays for creating your own diagrams as well as a sample diagram.

Navigation

20951: Navtree now correctly follows user

Although the All Hawk Agents Table drills down to the Host Summary display for that agent, the Host Summary did not become highlighted in the navtree. This has been fixed.

RTVMGR

21554: Fixed an issue with JVM Summary display

A bug that prevented Start Time and Up Time to be available in the JVM Summary display when multiple versions of Java were used has been fixed. These two fields will be missing from the display when the process is executed with Java 1.6. To fix the solution, upgrade to a higher version.

RTView Core Functionality

Data Historian

21683: Fixed a retention / compaction issue

When a mixture of simple retention and retention via advanced compaction was used, only the first table using simple retention was processed for retention. This has been corrected.

Data Server

21648: Enhanced rtvquery servlet to handle +/- infinity and NaN

In prior releases, the rtvquery servlet encoded the numeric values NaN (not a number), positive infinity, and negative infinity in a json or jsonp response as "" (an empty string). This makes it impossible for a client application to distinguish between those three values, when processing a json or jsonp response. In this release, the rtvquery servlet supports a URL parameter to encode NaN, positive infinity, and negative infinity in a json or jsonp response as the strings "NaN", "Infinity", and "-Infinity" respectively. The new parameter is named "nanok" and a value of true specifies the new behavior. The default value is false. For example, the following URL specifies the new option: http://somehost/rtvquery/cache/MyCache/current?fmt=json&nanok=true The other response formats (xml, xmlrtv, js, text) supported by the rtvquery servlet have always used NaN, Infinity, and -Infinity. That behavior has not been changed, so the nanok=true parameter is not needed to make those values appear in the response in those formats.

21684: Enhanced rtvquery servlet to support CORS

The rtvquery (REST) servlet has been enhanced to support CORS (Cross-Origin Resource Sharing). A new optional property named AllowOrigins may now be specified in rtvquery.properties. The property value is a string that specifies which domains are allowed to send requests to the servlet. By default AllowOrigins is blank, which indicates that requests are allowed only from the same domain that hosts the rtvquery servlet (as in all prior releases). Specify a value of * to indicate that requests are allowed from any domain: AllowOrigins=* Or, specify a comma-separated list of the domains which may make requests, in this format: protocol://hostname_or_address:port For example: AllowOrigins=http://192.168.20.11:3456,https://SomeHost:6789

Data Sources

21646: A new servlet has been added for use with the HTTP Data Source

A new RTVPost Servlet has been added to RTView. This is a proxy servlet for use with the HTTP Data Source. It is useful for cases where an application cannot post directly to the application running the HTTP Data Source due to security or post access limitations. For RTView Enterprise Monitor users, this is useful for the NODEMON and DOCKERMON solution packages in the case where your node or docker application is outside the firewall and is limited to posting to port 80. The RTVPost servlet is in RTV_HOME\servlets\rtvpost\rtvpost.war. The following properties are supported in rtvpost.properties: proxyHost: The http host to which to post. The default is localhost. proxyPort: The http port to which to post. The default is 3275. proxyPath: The path to which to post. This is commented out by default. RTView Core users can modify RTV_HOME\servlets\rtvpost\rtvpost.properties and run the make_war script to rebuild the rtvpost.war file. RTView Enterprise Monitor users can run RTVAPM_HOME\common\bin\make_rtvpost_war from their project\webapps directory as follows: make_rtvpost_war appname -host:somehost -port:someport Where appname is the name of your application. The host and port options are optional. If not specified, the defaults above will be used. The appname argument is used to name the war file, appname_rtvpost.war. To modify the proxyPath, copy RTV_HOME\servlets\rtvpost\rtvpost.properties to your webapps directory, modify the proxyPath value and then run make_rtvpost_war as described above. To use the rtvpost war file, deploy it to your application server. HTTP posts should use the URL for rtvpost and will be forwarded to the specified proxyHost and proxyPort.

21658: HTTP REST DS

The RTView HTTP REST Data Adapter, is an extensible data adapter that allows RTView to interact with REST APIs by means of HTTP Requests. The Data Adapter provides an extensible framework with RTView, using the Apache HTTP Client to Make HTTP requests. Handlers are used to abstract the process of making an HTTP request. The RTVHttpRest adapter supports data attachments which will execute an HTTP Request, to get an HTTP Response, which can then be processed to extract a data table for use within RTView. The data attachments specify the handlers used for the various parts of making and processing an HTTP Request and Response. Default Handlers are available, and the user can implement custom handlers to extend functionality.There are examples of custom handlers in the custom/rtvhttprest directory of the RTView installation. Abstracting the HTTP Request / Response sequence in RTView Consider the following simplified execution of an HTTP Request using the Apache HTTP Client library which handles the response and updates a data attachment with GmsTabularData: // Get a HTTP Client CloseableHttpClient httpClient = getHttpClient(dataObj); // Get a HTTP Request HttpUriRequest request = getRequest(dataObj); // Execute request using client to get response CloseableHttpResponse response = httpClient.execute(request); // Handle response to get Tablular Data GmsTabularData table = getTabularData(response, dataObj, ...) // Update the data attachment(s) ds.storeData(dataObj, table); The above code can be used to interact with any HTTP REST API. The processing that varies has been abstracted out and can be supplied by pluggable handlers (java classes) which implement the appropriate interface. These can then be specified in the data attachment for the given HTTP Request and must be on the classpath of the RTView application at run time. The Attatch to RTVHttpRestData dialog contains the following fields: - Client Handler: A text field used to specify the fully qualified name of the java class used to implement the ClientHandler interface (com.sl.gmsjhttprestds.ClientHandler). The ClientHandler returns a CloseableHttpClient (client) that is used to execute a request (returned by a RequestHandler implementation) to return a response that is processed by a ResponseHandler. The DefaultClientHandler (com.sl.com.sl.gmsjhttprestds.DefaultClientHandler) can be used to return a default client. For more sophisticated client interactions a custom ClientHandler implementation can be written and used. See the RTView javadocs for more details. There are examples of custom handlers in the custom/rtvhttprest directory of the RTView installation. Typical uses of a custom ClientHandler implementation would be to set header fields required to interact with a REST API, e.g. Authentication tokens - Request Handler: A text field used to specify the fully qualified name of the java class used to implement the RequestHandler interface (com.sl.gmsjhttprestds.RequestHandler). The RequestHandler returns a HttpUriRequest (request) that is executed by a client handler to return a response that is processed by a ResponseHandler. The DefaultGetRequestHandler (com.sl.com.sl.gmsjhttprestds.DefaultGetRequestHandler) can be used to return a default HTTP GET request. Default request handlers are provided for all the HTTP request operations. Typical uses of a custom RequestHandler implementation would be to set header fields required to interact with a REST API (e.g. Authentication tokens) or process information supplied in the request string argument to enhance the contents of a request if it cannot be specified by the request URI alone. For more sophisticated request handling, a custom RequestHandler implementation can be written and used. See the RTView javadocs for more details. - Request: A Text field used to specify the URI used to make the request executed by the request handler. The Request Handler may use the request as is, or process it to extract additional information used in the request. The format of a URI, used by an HTTP request:[//[user:password@]host[:port]][/]path[?query][#fragment] - ResponseHandler: A text field used to specify the fully qualified name of the java class used to implement the ResponseHandler interface (com.sl.gmsjhttprestds.ResponseHandler) The ResponseHandler returns a GmsTabularData that is extracted by the RequestHandler from the response as a result of a request obtained from a RequestHandler being executed by a client obtained from a ClientHandler. The DefaultResponseHandler (com.sl.com.sl.gmsjhttprestds.DefaultResponseHandler) can be used to obtain default GmsTabularData containing information from the response. Typical uses of a custom ResponseHandler implementation would be to extract GmsTabularData from a given response. For more sophisticated response handling a custom ResponseHandler implementation can be written and used. See the RTView javadocs for more details. - Column(s): A combo box for specifying the names of the table columns to include in the result, or * (the default) for all columns. - Filter Rows: A checkbox to enable the following 2 fields: - Filter Column: The name(s) of the columns(s) to which the Filter Value should be applied. - Filter Value: The filter value(s) to be applied to the filter columns. See the RTView documentation for details on the format to be used for specifying filter values. Note that wild cards and regular expressions are not supported in the Filter Value field. For that type of filtering, various standard RTView functions are available.

21680: Fixed an issue with encrypted database passwords

In version 6.7, a problem was introduced that caused an error to print to the console for sl.rtview.properties.databasePassword property if the property value was encrypted. In the error message, the databasePassword in the error was shown in plain text. This problem has been fixed.

Functions

21647: ArrayIndexOutOfBoundsException has been fixed

In previous releases, it was possible to get an ArrayOutOfBoundsException when closing a display containing a composite that was configured with the substititons property. This has been fixed.

General

21638: Firefox now displays button states the same as other browsers

In the thin client in Firefox, a button control (obj_c1button) will now appear depressed when the user clicks on it, as it does in other browsers.

Object Library

21629: Style sheets are now correctly applied

In previous releases, the style sheet was not applied correctly to the icons in the object grid. The behavior was different in the viewer and the thin client. In the thin client, the style sheet was never applied to the icons in the object grid. In the viewer, the stylesheet properties always overrode the property values specified in iconProperties. This has been fixed so that both the viewer and thin client behave as follows: If a property value is specified in iconProperties, this value takes precedence over the style sheet value. Properties for which no value was specified in iconProperties will use the style sheet values. If you have an object grid in a display from a previous release that counts on the previous behavior, you have 2 options: 1. Modify the iconProperties value for your object grid so that all properties that should override the style sheet are specified and no properties that should not override the style sheet are specified. 2. Use the following command line option to revert to the old behavior: -objgriduseoldss

21666: Tree Grid support added to Table objects

The table object (obj_table02) now supports a "Tree Grid" mode. In this mode, the first column of the table behaves as a tree, allowing table rows to be expanded/collapsed in groups according to a hierarchy defined by the index columns in the data table. The new mode can be configured in the builder, but the feature is only fully implemented in the thin client. Three properties have been added to obj_table02 to support the new mode. These are visible only if webGridFlag is checked: webTreeGridFlag: check this to enable the new mode webTreeLabelColumn: the name of the column to be added as the tree (first) column of the table webTreeAggregateColumns: a list of column names and calculations to be applied to data columns in parent rows INDEX COLUMNS: To use the new mode, the table object's indexColumnNames property must be specified. Each index column in the data table (attached to the valueTable property) defines a level in the tree -- the first index column specifies the values for the top level of the tree, the second index column specifies the values for the second level in the tree, and so on. For example, here is a portion of a data table containing Major League Baseball (MLB) standings. The index columns are named League, Division, and Team: League Division Team W L American East Red Sox 93 69 American East Blue Jays 89 73 American Central Indians 94 67 American Central Tigers 86 75 American West Rangers 95 67 American West Mariners 86 76 National East Phillies 95 67 National East Mets 87 75 National Central Cubs 103 58 National Central Cardinals 86 76 National West Dodgers 91 71 National West Giants 87 75 (Note: The full MLB table has 5 teams in each division). The index column values in the above data table can be used to create a 3 level tree, as follows: > American > East Red Sox Blue Jays > Central Indians Tigers ... etc ... > National > East Phillies Mets ... etc DATA TABLE FORMAT: When tree grid mode is enabled, the data table is automatically converted to the format required for the mode, as follows: 1) A row is added to the table for each parent level in the tree. For example, when the MLB table above displayed in tree grid mode, it will contain 8 additional "parent" rows which don't appear in the original table. These rows are added for the parent levels in the tree, one for the American League, one for the National League, and one for each of the 3 divisions in each league (American East, American Central, American West, National East, National Central, National West). The data columns (W, L) for each of the parent rows is assigned a value of zero. This is because there is no data in the original table for the parent rows. 2) A new column is added to the beginning of the table to display the tree levels. By default the column is named "Node Label" but a different name can be specified in the webTreeLabelColumn property. 3) Columns named Node ID and Parent ID are added to the table. These define the parent-child relationships in the table, and are used by the thin client to construct the tree. These columns are automatically hidden, via the columnsToHide property. AGGREGATION: As mentioned earlier, the parent rows added to the data table will contain a zero in each numeric data column. The webTreeAggregateColumns can be configured to show aggregated values (sum, min, max, or average) in those data columns. The property expects a list of column name, calculation pairs, with semicolons between the pairs. For example, to show the sum of the W and L columns of the child rows in each parent row of the MLB table above: webTreeAggregateColumns: W,sum;L,sum With that configuration each Division row will show the sum of its teams W and L columns, and each League will show the sum of its divisions W and L columns. FILTER & SORT: In the thin client, all of the web grid filter and sort features are available, by clicking on the column header. There are a few differences to note. The column filter menu can be used to hide rows in the table. However, this does not affect the aggregate calculations (if any), since they are always performed on all rows in the table, visible or not. Also, a parent row will be shown if any of its children pass the filter test, even if the parent row itself does not pass the filter. For example, if the filter Team = Phillies is applied to the MLB table, only one row passes that filter but the table will display both of that row's ancestor rows, for a total of 3 rows: > National > East Phillies The column sort feature in the thin client applies the sort within each level. That is, the sort will reorder rows within a tree level but won't move rows between levels of the tree, and parent rows will still appear above the rows of their children. Limitations on webTreeGrid mode: - The webTreeGridMode behavior only works in thin client, and only in desktop browsers that support the web (HTML5) grid. In all other cases the table will not display a tree column. - The webTreeGridMode does not support server-side paging, filtering & sorting. This means that webTreeGridMode mode does not perform well on large data tables, because the entire data table must be downloaded to the browser. For best results it should only be applied to data tables with 1000 rows or fewer. The intended use is to display the contents of an indexed cache table, with fewer than 1000 rows. - The export to html/excel/pdf feature does not recognize webTreeGridMode and instead exports the entire table. Advanced use: If the data table attached to valueTable already contains rows for the parent levels of the tree, with columns named exactly "Node ID" and "Parent ID" that uniquely identify each row and its parent row, then the table won't be converted as described above. In this case the column to be used as the tree column should be identified by the webTreeLabelColumn property.

Scripts

21579: Fixed an issue with the scripts that make .war files

The new make_*_war scripts on Windows would change comment lines when changing host and port values in properties files. This has been corrected.

21681: Optimized the scripts that make .war files

The scripts used to make war files for the servlets now check that RTVAPM_HOME is defined before proceeding.

Solution Package

21687: EM enhanced with properties filter collector

The properties filter collector has been added to all cache configuration properties throughout all of RTView EM. This enhancement will allow the properties related with cache configuration to exist exclusively on the Data Server processes.

21692: Fixed an issue with proper shutdown of HSQLDB

Previously the HSQLDB instances provided with the following solution packages were not able to shut down cleanly using the stop_hsqldb command. MONGOMON DOCKERMON NODEMON This has been fixed.

General

21628: Custom project has been improved

The custom project in projects/emsample has been updated and its documentation has been corrected. Note the instructions for running the sample JMX app have changed, and now apply to Unix as well as Windows.

IBM Websphere Application Server

21591: Fixed an issue with the All Servers Detail display

A bug that prevented the correct population of the All Servers Detail display in a sender/receiver configuration has been fixed. This display has also been enhanced to horizontally adjust the height of the four tables proportionally to the window size.

MS SQL Server

21574: New Solution Package for MS SQL Server

The MSSQLMON Solution Package has been added to RTView EM. MS SQL Server Jar location -------------------------------------------------------------------------------- Provide the correct full path to the MS SQL Server JDBC jar in your sample.properties file: collector.sl.rtview.cp=%RTVAPM_HOME%/../ext/mssqlserver/sqljdbc4-4.0.jar Connection properties -------------------------------------------------------------------------------- Replace ConnStr, myUser, myPassword with your credentials. Notice that second line should match the substitutions $mssqlConnString with the sqldb connection name (ConnStr): collector.sl.rtview.sql.sqldb=ConnStr myUser myPassword jdbc:sqlserver://MyIP:1433 com.microsoft.sqlserver.jdbc.SQLServerDriver - false false collector.sl.rtview.cache.config=mssql_sources.rtv $mssqlConnString:ConnStr Historical Data -------------------------------------------------------------------------------- Enabled tables are: MSSQL_SERVERSTATS and MSSQL_PERFCOUNTERS. To disable them, add the following lines to your sample.properties file: collector.sl.rtview.sub=$MSSQL_SERVERSTATS_TABLE:'' collector.sl.rtview.sub=$MSSQL_PERFCOUNTERS_TABLE:'' Disabled tables are: MSSQL_DBSIZES, MSSQL_SERVERTABLESIZES, and MSSQL_WAITSTATS. To enable them, add the following lines to your sample.properties file: collector.sl.rtview.sub=$MSSQL_SERVERDBSIZES_TABLE:MSSQL_DBSIZES collector.sl.rtview.sub=$MSSQL_SERVERTABLESIZES_TABLE:MSSQL_SERVERTABLESIZES collector.sl.rtview.sub=$MSSQL_WAITSTATS_TABLE:MSSQL_WAITSTATS Cache Collection Periods (in sec) -------------------------------------------------------------------------------- Update Period for MssqlServerDatabaseSizes cache: collector.sl.rtview.sub=$mssqlDBSizeQueryInterval:300 Update Period for MssqlPerfCounters cache: collector.sl.rtview.sub=$mssqlPerfCounterQueryInterval:15 Update Period for MssqlServerStats cache; collector.sl.rtview.sub=$mssqlSystemStatsQueryInterval:15 Update Period for MssqlServerTableSizes cache: collector.sl.rtview.sub=$mssqlTableSizeQueryInterval:300 Update Period for MssqlWaitStats cache: collector.sl.rtview.sub=$mssqlWaitQueryInterval:15 Not used at the moment: collector.sl.rtview.sub=$mssqlQueryInterval:15 collector.sl.rtview.sub=$mssqlQueryPerfQueryInterval:15 Sender/Receiver -------------------------------------------------------------------------------- The dataserver to be used is MISCMON. The receiver should be executed with -propfilter:receiver property Sender: Option 1 Uncomment the following lines on the sender if you will connect through IP and port The sender should be executed with -propfilter:sender property sender.sl.rtview.sub=$rtvAgentName:MyAgentName sender.sl.rtview.sub=$rtvAgentTarget:'YourReceiverIpAddress:3972' Sender: Option 2 Uncomment the following lines on the sender if you will connect through agent servlet The sender should be executed with -propfilter:sender property sender.sl.rtview.sub=$rtvAgentName:MyAgentName sender.sl.rtview.sub=$rtvAgentTarget:'http://publicIPAddress/mssqlmon_rtvagent' CI Types -------------------------------------------------------------------------------- MSSQL-INSTANCE Index: DbConn Key Metrics -------------------------------------------------------------------------------- SQL CPU Used Memory In Use (%) Alerts -------------------------------------------------------------------------------- MssqlInstanceSqlCpuUsedHigh The percentage of CPU utilization on SQL processing has exceeded its threshold. Default thresholds are: Warning 10%, Alarm 15% MssqlInstanceUsedMemoryHigh The percentage of memory used by the SQL Server has exceeded its threshold. Default thresholds are: Warning 65%, Alarm 85% MssqlInstanceDeadlocksDetected The number of current deadlocks has exceeded its threshold. Default thresholds are: Warning 1, Alarm 2 MssqlInstanceLatchWaitsHigh The number of current latch waits has exceeded its threshold. Default thresholds are: Warning 15, Alarm 30 MssqlInstanceLockWaitsHigh The amount of seconds on lock waits has exceeded its threshold. Default thresholds are: Warning 15, Alarm 30 MssqlInstancePacketErrorsDetected The amount of current packet errors has exceeded its threshold Default thresholds are: Warning 1, Alarm 2

Node.js

21593: Enhanced Node Requests columns

In the All Requests Table, two columns have been added and two have been renamed. The previous column "Requests Per Sec" is now "Recent Requests Per Sec", and "Avg Response Time" is now "Recent Avg Resp Time". In both cases their respective data displayed values from the most recent polling period. The two new columns are "Requests Per Sec" and "Avg Response Time (ms)". These columns display their respective data as averaged since the monitored server began running. The renamed columns will continue to display the same data as in the previous release. Nothing has changed here, other than the column names. The new columns display their respective metrics as averaged during the lifetime of the server.

21594: Nodemon agent enhanced

A trim() API function has been added to the Nodemon agent which allows for more accurate grouping and analysis of URL response times.

21595: Enhanced Request URL column

With this release, query strings are removed from URLs before being added to the All Requests Table. This allows for more accurate grouping of similar URLs.

Solace

21335: Support for Solace VMRs has been added

We now support monitoring of Solace VMRs.

21587: Enhanced performance of SOLMON caches

To improve performance, an unneeded reference to the SolEndpoints cache has been removed from the function chain that populates the SolAppliances cache.

21589: SEMP version is now parameterized

To support the Solace VMR, the SEMP version has been parameterized with a substitution that will be included in the connection parameters to each physical or virtual Solace Message Router. The sample.properties file contains one example of the connection properties that includes the connection string name, $solConn, and the SEMP version, $solSempVersion. In the case of the VMR, the lowest version supported is 7.1.1. For the physical appliance, the lowest version supported is 6.2.

21603: Fixed an issue with heatmap metrics

A bug that prevented the drop down "Metric" from the All Msgs Routers Heatmap and the Al VPNs Heatmap to work correctly has been fixed.

21607: Enhanced various SOLMON displays

The main table shown in the Message Router-> Message Spool Table display now is anchored to the bottom of the window. Also the Message Router->Msg Router VPN Activity now has vertical resizing to adjust proportionally the height of the three graphs being shown.

21615: Enhanced SOLMON to differentiate between an Appliance and a VMR

The Solace platform has been added to the Single Message Router Summary. This information is located in the title of the upper left dividing rectangle in the display.

21624: Enhanced trends on multiple SOLMON displays

Trends from Message Router Summary and Single VPN Summary have been enhanced to include one decimal point on mouse over texts.

21655: Support Sender/Receiver architectures for Solace VMR

The sender/receiver configuration has been implemented for SOLMON. There are two options for the sender configuration: 1. Connecting to the receiver data server through IP address and port. This option requires accessibility between sender and receiver. 2. Connecting to the receiver data server through the agent servlet. This option requires an application server running in the receiver with solmon_rtvagent deployed. Instructions for both are below: Step 1. Determine SEMP version of the Solace Appliance or VMR Use SolAdmin and set its logging properties to INFO. To do so, follow these steps, which assume you have installed SolAdmin on Windows: Step 1.1. Go to the location where SolAdmin was installed. E.g. C:\Program Files (x86)\SolAdmin\ Step 1.2. Look in the bin directory and open the log4j.properties file in a text editor Step 1.3. Follow the instructions that are at the beginning of the file, which essentially explain that you should change the logging level to DEBUG and provide the full path to the logging file. For instance, if your directory is C:\Logs, your file should look like the example below. Leave the rest of the file unchanged. log4j.appender.A1.File=C:\Logs\soladmin.log # Categories log4j.category.com.solacesystems=DEBUG, A1 Step 1.4. Restart SolAdmin Step 2. Manage the Solace Appliance or VMR by using SolAdmin and searching for the SEMP version Step 2.1. Add as a Managed Router your instance Step 2.2. Go to soladmin.log and search in the SEMP requests for the semp-version tag Step 3. Add the correct SEMP version to the connection properties of your SOLMON properties file Edit your SOLMON sample.properties file, and replace the value of $solSempVersion with the one from the log file. Replace any underscores in the value from the log file with dots. For instance, 6_2 will become 6.2. collector.sl.rtview.http.conn=__name=YourVMR url=http://YourIP:8080/SEMP username=yourUser password=yourPwd collector.sl.rtview.cache.config=sol_cache_source.rtv $solConn:YourVMR $solSempVersion:7.2VMR Step 4. Add the sender properties in your SOLMON properties file Option 1: Connecting to the receiver through IP address and port # Sender properties sender.sl.rtview.sub=$rtvAgentName:MyVMRInstance sender.sl.rtview.sub=$rtvAgentTarget:'YourReceiverIpAddress:4172' Option 2: Connecting to the receiver through the agent servlet # Sender properties sender.sl.rtview.sub=$rtvAgentName:MyVMRInstance sender.sl.rtview.sub=$rtvAgentTarget:'http://publicIPAddress/solmon_rtvagent' Step 5. Start the sender Go to your project directory and start the sender as follows: rundata.sh/.bat -properties:sample -propfilter:sender Step 6. Go to the host where your receiver will run Step 6.1. Start the receiver Go to your project directory and start the receiver as follows: rundata.sh/.bat -propfilter:receiver Step 6.2. Verify that you are collecting data from the sender by opening a browser window to reach your deployed SOLMON instance. NOTE: Syslog data won't be sent from the senders. You'll need to configure syslog data from your VMRs and appliances on the receiver host.

21693: Enhanced SOLMON syslog event collection

To minimize performance in the SOLMON Solution Package in a sender/receiver configuration, Syslog events are not sent. In this configuration, Syslog events for the Solace Message Router or VMR should not be collected on the sender host. Instead, these events should have to be redirected to the receiver host.

21695: Fixed a properties file referencing issue in SOLMON

A bug that allowed references from other Solution Packages to exist in SOLMON has been fixed.

TIBCO ActiveSpaces

21089: Fixed a cosmetic issue in TASMON

The Heatmap/Table buttons on the All Members By Space table and heatmap displays had nonstandard borders. This has been corrected.

21581: Fixed an error in TASMON

in tasmon/conf/rtvapm.tasmon.properties, there was an error in a property: collector.sl.rtview.sub=$TAS_SEEDERS_TABLE: Should have been: collector.sl.rtview.sub=$TAS_SEEDERS_TABLE:'' This caused errors of the form: SQLException: ORA-00942: table or view does not exist while attempting: insert into "$TAS_SEEDERS_TABLE" This has been corrected.

TIBCO BusinessEvents

21568: New CI type added under TBEMON

A new CI Type, TBE-NODE, has been associated to TbeNodeConnectionLoss, TbeNodeObjectTableSize and TbeNodeObjectTablleExtIdSize alerts. This new CI Type solves the issue of blank CI and Primary Service when these alerts were executed under EM.

TIBCO BusinessWorks

21619: Limited engines no longer marked with red background

The BWMON Single Engine Summary display indicates a stopped engine with a red background. This was incorrectly applied to limited engines as well. This has been corrected

21620: Fixed alignment problem in certain displays

The background of some BWMON displays were slightly overlapping the display objects. This has been corrected.

21627: Engines no longer incorrectly marked as stopped

The BW Engine dropdown lists indicate stopped engines by "(X)". This was incorrectly applied to limited engines as well. This has been corrected.

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 table using 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.