Version 6.7.0 Release Notes
Alerts
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.
Configuration
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.
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.
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.
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.
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.
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.
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.
Monitor
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
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
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.
Alerts
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.
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.
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.
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 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
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
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.
21680: Fixed an issue with encrypted database passwords
In RTView 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.
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
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.
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
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.
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.
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.
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.
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
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.
Platform Support
21871: Support for Java 1.6 dropped
RTView is now built with Java 1.7.
Java 1.6 is no longer supported.
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
21561: Project directory now uses common .war scripts
The update_wars.bat/sh scripts in the project directories have been updated to
use the new make*war.bat/sh scripts in common/bin.
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.
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.
Version 6.6.0 Release Notes
Alerts
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.
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.
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.
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
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
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.
Data Model
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.
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.
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.
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.
General
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
Monitor
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.
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.
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.
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
RTView Core Functionality
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"
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.
Platform Support
21076: Windows 10 and Edge Browser support
Windows 10 and the Edge Browser are now supported by RTView products.
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.
Version 6.5.0 Release Notes
Alerts
19007: EmsQueues|TopicsProducer alerts overrides can now be set
EmsQueuesProducerCountHigh, EmsQueuesProducerCountLow,
EmsTopicsProducerCountHigh, and EmsTopicsProducerCountLow have been fixed to set
properly overrides.
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.
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.
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.
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.
Configuration
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.
20655: High Availability configuration finalized
An ommission that prevented out-of-the-box configuration of High Availability for
EMSMON has been fixed.
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.
Data Model
20104: Fixed errors in emsmon dataserver.log: alertConsumerStalled
An error in the dataserver log file about alertConsumerStalled has been fixed.
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.
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
Monitor
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
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.)
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.
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
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.
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.
Platform Support
20536: Support added for Red Hat Linux 7
RHEL 7 is now a supported platform for RTView.
RTVMGR
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.
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
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 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
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.
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
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
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.
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)
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.
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.
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
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.
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.
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.
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.
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
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)
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).
maxCharacters - The maximum number of characters that will be submitted to the
control's actionCommand. The default value is blank (no limit). The limit does
not restrict the length of the text in the control, instead the limit is checked
before the command is executed and if the limit is exceeded, the command is not
executed.
inputValidVarToSet - Attach to a local variable. This variable will be updated
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 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.
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.
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.
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.
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.
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
Servers
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 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
|