RTView® | TIBCO® EMS Monitor
Release Notes


Version 6.4.0 Release Notes

Alerts

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.

19941: Updated description of EmsConsumerStalled alert

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

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.


Configuration

19160: Additions to projects/sample folder

The emsmon/projects/sample folder was missing some useful files. This has been corrected.

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

Data Model

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.

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.

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.

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

General

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.

19546: Fixed "serverActivity3WithSeverity" function error

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

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.


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.

Monitor

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.

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.

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.

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.

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

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.

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.

19544: Improve visibility of Consumer ID from EMS Consumer Summary

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

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.

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.

20233: Fixed typos in Consumers display

Typos in Ems Consumers for Server have been fixed.

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.


20585: Corrected units in EMS Server Summary

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


Navigation

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

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.

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.

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

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.

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.

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 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.

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

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

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

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.

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

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.

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.

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

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.

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.

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.

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.

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.


General

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

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.

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.

Platform Support

19592: Support Chrome as a browser 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.

Servers

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

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

Timing / Performance

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.


Version 6.3.0 Release Notes

Alerts

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.

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).

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.

Data Model

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.

General

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.

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

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.

Monitor

18814: Password column removed from server table

The Password column in the Server Table section of EMS Single Server Tables display has been removed.

Version 6.2.0 Release Notes

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


Alerts

18128: Add alert descriptions to alerts

Alert descriptions were added to EMS alerts.

18179: 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


18252: Custom handler and custom alert command added to sample project

EMS Monitor has been enhanced with an optional custom package that lets you define custom functions and commands. The custom package code is in %RTVAPM_HOME%\emsmon\projects\sample\custom\src\com\sl\rtvapm\custom. To build the custom package classes, run %RTVAPM_HOME%\emsmon\projects\sample\custom\src\make_classes.bat. This will build the classes and output them in %RTVAPM_HOME%\emsmon\projects\sample\custom\lib\rtvapm_custom.jar. You may modify the custom function handler, RtvApmFunctionHandler.java, to implement custom functions for use in custom displays. The custom function handler api is described in the RTView Classic documentation under Customization->Custom Functions and Customization->Customization API. You may modify the custom command handler, RtvApmCommandHandler.java, to implement custom commands for use in custom displays or as alert notification commands. The custom command handler api is described in the RTView Classic documentation under Customization->Custom Commands and Customization->Customization API. To enable these classes, include %RTVAPM_HOME%\common\conf\custom_handlers.properties in your command line: -properties:%RTVAPM_HOME%/common/conf/custom_handlers The RtvApmCommandHandler class contains a sample alert notification command named my_alert_command. You can use this example as a starting place to implement your own custom alert notification command. To use the my_alert_command custom command for alert notifications, uncomment the sl.rtview.alert.alertcommand line in %RTVAPM_HOME%\common\conf\custom_handlers.properties.


18330: Alerts fired for standby servers

FT standby servers on EMSMON don't trigger alerts now.

18369: EmsServerStaleData alert fixed

The EmsServerStaleData alert now works as intended; it fires for active servers but does not trigger for fault-tolerant servers

Configuration

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.

Deployment

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


Monitor

18096: Trend charts in EMSMON now configured for history

Trend graphs for the following dashboards have been improved to display historical data: 1. ems_allroutes_forserver.rtv 2. ems_alldurables_forserver.rtv (needed: 3. ems_server_trends 4. ems_alltopics_forserver 5. ems_topic_summary 6. ems_server_summary 7. ems_queue_summary 8. ems_allconsumers_forserver 9. ems_allqueues_forserver 10. ems_server_trends 11. ems_allproducers_forserver

Servers

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.

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.

Version 6.1.0 Release Notes

Deployment

17662: Support deployment of Windows services on 64 bit platforms

EMS Monitor can be installed as Windows Services on 32 and 64 bit platforms.

General

17958: All tabular views now have max rows

The display of tables in EMS Monitor has been improved as follows: the display-side limit on the number of rows in a table has been increased to 100,000 so (in almost all cases) all rows of data will always be available.

17978: About display added

A new About display has been included under the RTView Servers subcategory. This display contains information about version, build date, and data sources.

Monitor

17704: New alerts for low producers/consumers of queues

The following alert definitions have been added to EMS Monitor: EmsQueuesConsumerCountLow EmsQueuesProducerCountLow These alerts by default have a warning threshold of 15 and an alarm threshold of 5.

17984: Changed topic and queue detail trend colors for consistency

The line colors of the trends in the Single Topic Summary and Single Queue Summary trends have been changed to be consistent with related displays (e.g. All Topics for Server).

Navigation

17360: Historical Time Range Navigation provided for all trend charts

All displays containing trend charts in the EMSMON package have been enhanced to include button that will invoke a Time Range Navigation Dialog, permitting the selection of a historical time range for data shown in the trend chart. Selecting the "..." button to the right of the Time Range dropdown selector will invoke the dialog. Once invoked, select the desired end time for the trend using the Calendar control, or enter it in the text field provided. Once entered, hit the Apply button to activate this time range. Hit the "Return to Now" button to restore the trend chart to the current time. Limitation: On the All Durables For Server display, the Total Pending Msgs (top) trace in the trend graph is not configured for historical data. Whenever you bring up the display it will begin redrawing from the origin.


Platform Support

17602: Support iPad deployment

EMS is now supported on iPad safari browsers.

Servers

17501: Clicking on pending count in heatmap view should list servers

The All Servers Heatmap and All Servers Grid displays have been enhanced such that clicking on the Pending value field will drill down to the All Servers Table display

 

 
SL, SL-GMS, GMS, RTView, SL Corporation, and the SL logo are trademarks or registered trademarks of Sherrill-Lubinski Corporation in the United States and other countries. Copyright © 1998-2013 Sherrill-Lubinski Corporation. All Rights Reserved.
 
 
 

JMS, JMX and Java are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. They are mentioned in this document for identification purposes only.

 
 
 

Third Party Notice Requirements