Set the RTView application to run as a background process. When this option is specified, the GmsLauncher process and run scripts exit immediately after the RTView application is started, rather than continuing to run, thereby reducing the host system process count. However, note that:

Note: This option is only recognized on the command line and is not read from, or saved to, any RTView options (.ini) files.

Example:

-bg

Specifies the client access list to the Data Server. There are three access list options: client_blacklist, client_graylist, and client_whitelist. Clients listed on the Graylist are permitted access to the Data Server if they provide a trusted SSL certificate. By default, the client access lists are empty which means that any client can connect to the Data Server.

Note: Graylisting should be used only when necessary since it involves certificate management, delays from SSL handshaking, and overhead from data encryption.

Note: The client access list options can be specified as Data Server command line arguments, as options in the DATASERVER.ini file, or as entries in a properties file.

Specify a client hostname or IP address which may contain * characters as wildcards, or a range of IPv4 addresses in the format of n.n.n.n-n.n.n.n, where each n is a number between 0 and 255. For details, see Security.

Example:

run_dataserver -client_graylist:192.168.1.*

Prevent a deadlock condition that can occur in abnormal situations. If the server attempts to push data to a client that is connected via socket and the corresponding write operation on the client's socket stalls for more than the specified number seconds, the server will close the client's socket. Default is 0, which means the write to a client socket will never timeout.

This timeout avoids the potential for deadlock with other threads in the server that may be trying to access the same data table that was locked while being pushed to the client. The write to the client's socket may stall because of networking problems, or a deadlock or other error in the client that prevents it from reading its incoming data.

Example:

run_dataserver -client_write_timeout:(60)

Set the path of the XML output to a directory other than the local directory. You can specify both an absolute path or a relative path. Double quotes are required if the path contains spaces.

Example:

-dataout:"c:\rtview files\rtvdata.xml"

Add a data configuration (.rtv) file to the Data Server.

Example:

run_dataserver config.rtv

This argument is used, in conjunction with the -group_priority argument, to designate the primary and backup servers for a high availability (HA)server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode in the High Availability section.

Specify the hostname and port number of the other Data Server in this group. That is, when launching the primary server in the group, use the -group_member option to specify the hostname and port number of the backup server in the group. Conversely, when launching the backup server in the group, use the -group_member option to specify the hostname and port number of the primary server in the group. If a hostname is specified without a port number, port 3278 is assumed. Do not specify a URL for the rtvdata servlet.

Specifying the -group_member argument mitigates the need to specify the -standby:warm option. The server remains in standby mode until the primary server is determined. If the -group_member argument is specified and -group_priority is not, the -group_priority value defaults to a value of 1 (the lowest priority).

Example:

-group_member:otherhost:3278

This argument is used for the backup server in a high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode in the High Availability section. For an example of how to configure a server group on the command line, see Server Group Configuration Example.

The primary Data Server sends a ping message to the backup server every 5 seconds. The group_ping_timeout option determines the amount of time (in seconds) the backup server waits for a ping from the primary server before it assumes the primary server failed and takes over as primary. The default value is 30 seconds and 30 is also the minimum non-zero value. A value of 0 (zero) disables the ping timeout feature entirely.

This timeout argument is intended to detect rare cases where the primary Data Server is running and connected to the backup server and the primary server becomes unresponsive. If the primary Data Server terminates or the host on which it is running shuts down, the backup server detects this immediately regardless of the value of the group_ping_timeout or group_timeout properties, and takes over as the primary.

Example:

-group_ping_timeout:30

This argument is used, in conjunction with the -group_member argument, to configure the behavior of backup Data Servers in a redundant high availability (HA) server group. For details about HA server groups and configuring this in the Data Server GUI, see Active / Standby with auto-reset mode in the High Availability section. For an example of how to configure a server group on the command line, see Server Group Configuration Example.

There are two modes for this argument:

passive: The backup server does not activate the RTView global, cache, or alert data sources at startup. In this mode, the backup server only activates those data sources if it leaves standby mode because the primary server is unavailable. When the primary server is available again, the backup server returns to passive standby mode by deactivating the alert, cache, and global data sources.

Note: Since the passive standby mode activates several data sources during the failover process, cache data can be missed (which the active standby mode avoids).

active: The backup server activates the global and cache data sources at startup and begins collecting and storing data in caches as configured in the global and cache definition files. However, the backup server does not activate the alert data source at startup. In this mode, the backup server only activates the alert data source when if it leaves standby mode because the primary server is unavailable. When the primary server is available again, the backup server returns to active standby mode by deactivating the alert data source, and leaving the global and cache data sources activated. Since the active standby mode activates only one data source, the alert data source, during the failover process, cache data is less likely to be missed.

There is some cost associated with active standby mode because both the primary and backup server collect and store data in caches. For example, if a cache definition file defines SQL queries to collect data, in active standby mode both servers perform those SQL queries. Whereas in passive standby mode only the primary server performs the queries.

Note: The alert data source is inactive in the backup server in both active and passive standby mode, to avoid generation of duplicate alerts by the primary and the backup servers.

If no value is specified the default value is passive.

The group_standby_mode property can be also be specified as follows, where X is either passive or active:

DATASERVER.ini: group_standby_mode X

In a properties file: sl.rtview.dataserver.group_standby_mode=X

Example:

run_dataserver -group_standby_mode:active

The port number to use to expose JMX methods to monitor and manage the Data Server. There is no default port. If not specified, these JMX methods will not be accessible. See Managing the Data Server Using JMX

Example:

-jmxport:9997

Values:

-host - The name of the host. The default value is localhost. This value is overridden when -url is specified after it.

Example:

-host:localhost

-port - The port number for the Data Server. The default value is 9020. This value is overridden when -url is specified after it.

Example:

-port:9020

-silent - Specifies not to print out the progress of low level operations. -silent and -verbose are mutually exclusive.

Example:

-silent

-user - The user name for accessing the JMX Mbean with authentication. If you specify -user, also specify -password.

Example:

-user:fred

-password - The password for accessing the JMX Mbean with authentication. If you specify -password, also specify -user.

Example:

-password:secret

-url - The URL for accessing the (remote) JMX Mbean. If you specify -url, it must not contain spaces. URL strings are always used internally. Specifying -url overrides the use of –host and -port. The substitutions are similar to the following example.

Example:

-url:service:jmx:rmi:///jndi/rmi://localhost:9995/jmxrmi

-verbose - Specifies to print out the progress of low level operations. -silent and -verbose are mutually exclusive.

Example:

kill_dataserver -port:9995

-log4jprops - Specify the .properties file to use to format the Log4j log file. By default, sl.log4j.properties is used. Use this to provide a different property file name. The .properties file is searched for inside a .jar/.war file, then searched for in the current directory, and lastly searched for in the %RTV_HOME%/lib directory. The filename can have a path preceding it. For example, C:\mydir\my.log4j.properties.

For example:

-log4jprops:mylogfile.properties

-log4jlevel - Specify the Log4j Level. INFO is used by default. Valid values are:

FATAL: Indicates a severe error that likely causes the application to abort.

ERROR: Indicates an event that might not cause the application to abort.

WARN: Indicates a potentially harmful event.

DEBUG: Indicates detailed informational about events for debugging the application.

INFO: Indicates informational messages about the progress of the application at coarse-grained level.

For example:

-log4jlevel:INFO

Specify the redirection of output and error messages to a file. The RTView application output and error message streams are redirected to the specified file. The file is created if it does not exist. By default, if the file does exist, its previous contents are cleared.

If the name of the log file contains the string DDDD (four upper case D characters), the string is replaced with the current local date and time using the format yyMMdd_HHmmss. For example, if we execute the following command on Sep 27 2012 at 3:55:43 PM:

run_dataserver -logfile:DataServer_DDDD.log

a log file named DataServer_120927_155543.log is produced. In most cases, this is a unique filename so that the previous log file, if any, remains unchanged. Over time, a large number of log files can accumulate so it is advisable to periodically purge the old files. On Linux, the logrotate utility can be used to automate this.

Note: The -logfile option is only recognized on the command line and is not read from, or saved to, any RTView options (.ini) files.

Example:

run_dataserver -logfile:DataServer.log

Pass RTView login information into all data sources that have the Use Client Credentials option enabled.

Note: Some data sources do not support this feature. For information on Application Options for your data source, refer to the Data Sources section of this documentation.

Example:

-passclientlogin

Specify to identify applications running as background processes. This option tags a unique identifier onto RTView server instances, enabling you to differentiate between multiple instances of those RTView applications. This option allows you to stop a particular instance without eliminating the other instances. If no process name is specified, the RTView application name is used as the process name.

For example,

run_builder-processName:XX

adds the following JVM option to the Java call:

-DPROCESS_NAME=XX

Where XX is the value you specified for the -processName argument.

Note: Values with spaces cannot be used for this option on Unix.

Example:

-processName:XX

Send all data over the socket regardless of whether or not it has been updated.

Example:

-sendalldata

Run a backup Data Server without the overhead of maintaining the Alert and Cache data sources.

The following actions will be delayed until the backup server has become the primary:

Note: Although the -standby:warm option reduces overhead because data sources do not provide data until a failover, it is important to note that Alert and Cache data definitions will not start collecting data until the first client connects. Therefore, any previous alert state or cached data from the primary server will not be available to the backup.

Example:

run_dataserver -standby:warm

Set the default timezone for interpreting and displaying dates. Include a Java timezone ID or a custom ID, such as "GMT-8:00". Unrecognized IDs will be treated as GMT. See Timezone ID Values for more information.

If you run the RTView Builder with a valid timezone parameter and then save Application Options, the timezone information will be persisted.

To prevent the persisted timezone value from being used, pass "none" as the timezone ID.

Example:

-timezone:US/Eastern

-timezone:none

Specifies to print out the progress of low level operations. -silent and -verbose are mutually exclusive.

Example:

-verbose

Specifies name of a database connection, as defined on the SQL tab, in which to store Audit Alert Action information.

Example:

-actionauditdb:ALERTBD

Specifies the rate, in seconds, to remove cleared alerts.

Example:

-alertcleartime:3

Enables/disables all alerts in the active alert definition files.

Example:

-alertds:enabled:false

Specifies the duration, in seconds, to wait after startup to begin executing alerts.

Example:

-alertinitdelay:5

If true and configured, alert actions will be stored to the specified database table.

Example:

-enableactionaudit:true

If true, the AlertTable Count column increments for an alert when new data is received even if the Last Update Time has not changed. This can cause invalid Counts for alerts attached to caches.

If false or not specified, the AlertTable Count column increments for an alert only if the Last Update Time has also updated. This is the default behavior.

Example:

-ignorelutforcount:true

For alerts with multiple index columns, create a unique alert index by concatenating all of the index column values. Value can be any string, except the following:

Default is tilde (~).

Example:

-multipleindexdelim:~

Clears all alerts for the alert engine from the Alert Persistence database on startup and no persisted alerts will be loaded.

Note: If you are persisting alerts for more than one alert engine in the same database, alerts for other alert engines will not be removed.