# DataSource monitoring configuration (part 2) Here are the rest of the DataSource configuration items that determine who can monitor and manage a [DataSource application](index.md) through JMX, and what objects can be monitored and managed. For more DataSource monitoring configuration items, see [DataSource monitoring configuration (part 1)](datasource-datasource-monitoring-configuration-part-1.md). ## jmxcache-hash-size `jmxcache-hash-size` specifies the size of the hash table needed by this DataSource application’s JMX module. The value should be about twice the total number of mbeans that the application will create***__.__*** **Use in:** C **Syntax:** `jmxcache-hash-size ` **Type:** integer **Default value:** `100000` ## log-monitor-level `log-monitor-level` specifies the threshold at which log messages about a DataSource application’s events and errors are published to the [monitoring subsystem,](datasource-datasource-monitoring-and-management.md) to be viewed by a monitoring client such as the [Caplin Management Console](../cmc/index.md). You can override this setting _for the Event log only_ by specifying the [monitor-level](datasource-logging-configuration.md#monitor-level) option of the [add-log](datasource-logging-configuration.md#add-log) configuration item. **Use in:** C **Syntax:** `log-monitor-level ` **Type:** string **Default value:** `INFO` **Values accepted:** | LEVEL | DESCRIPTION | | --- | --- | | `DEBUG` | Sends all errors and events. | | `INFO` | Sends events and information regarding normal operation and all errors included in the `WARN`, `NOTIFY`, `ERROR` and `CRIT` debug levels. | | `WARN` | Sends minor errors and all errors included in the `NOTIFY`, `ERROR` and `CRIT` debug levels. | | `NOTIFY` | Sends errors regarding data corruptions and all errors included in the `ERROR` and `CRIT` debug levels. | | `ERROR` | Sends serious errors regarding network connections and all errors included in the `CRIT` debug level. | | `CRIT` | Sends critical errors that prevent the DataSource application from running. | ## monitor-module `monitor-module` defines the monitoring module that is to be loaded into the DataSource application. **Use in:** C You only need to use this configuration item if you’re writing your own DataSource application (such as a C-based Integration Adapter). For Liberator and Transformer, this configuration is predefined in the JMX Config blade that comes with these components. **Syntax:** `monitor-module jmx` ## monitor-moddir `monitor-moddir` defines the directory where the DataSource application’s JMX monitoring module is located. **Use in:** C You only need to configure this if you’re writing your own DataSource application (such as an Integration Adapter). For Liberator and Transformer, this configuration is predefined in the JMX Config blade that comes with these components. **Syntax:** `monitor-moddir DIRECTORY` **Type:** string **Default value:** `%r/lib` If the first two characters of DIRECTORY are `%r`, the directory is prefixed with the root directory ([application-root](datasource-run-time-environment-configuration.md#application-root)) of the DataSource application installation; for example `/liberator/lib` or `/myadapter/lib` ## object-latency-stat-period `object-latency-stat-period` defines the period, in seconds, over which latency statistics are calculated for viewing via an object’s `latency-chain` MBean attribute. At the end of this period, the data is reset and the calculation (averaging) starts again. **📌 NOTE**\ For more about the `latency-chain` MBean and how to view it, see How can I... [Monitor latency using the CMC](../cmc/cmc-monitor-latency-using-the-cmc.md). **Use in:** C **Syntax:** `object-latency-stat-period ` **Type:** integer **Default value:** `300` seconds (`5` minutes) ## object-monitoring-interval `object-monitoring-interval` defines the time interval in seconds at which Liberator monitors the state of its objects. **Use in:** Liberator only **Syntax:** `object-monitoring-interval ` **Type:** float **Default value:** `-1.0` To disable object monitoring, set this item to `-1.0` (the default). ## session-monitoring-interval `session-monitoring-interval` defines the time interval in seconds at which Liberator monitors the state of its sessions. **Use in:** Liberator only **Syntax:** `session-monitoring-interval ` **Type:** float **Default value:** `-1.0` To disable session monitoring, set this item to `-1.0` (the default). ## process-usage-period `process-usage-period` defines the time interval in seconds at which the DataSource application’s CPU time counters `user-cputime-total` and `system-cputime-total` are updated. These counters can be viewed through JMX monitoring. If you’re using the [Caplin Management Console](../cmc/index.md), you can see them in the Explorer tab under `rttpd.server.system` **Use in:** C **Syntax:** `process-usage-period ` **Type:** float **Default value:** `10` seconds. ## rmi-client-port `rmi-client-port` defines the port in this DataSource application that a JMX-enabled monitoring client, such as the [Caplin Management Console](../cmc/index.md), connects to. Alternatively, you can define this port in the DataSource application’s [jvm-options](datasource-java-jvm-configuration.md#jvm-options) configuration, as follows: ``` jvm-options -Drmi.client.port ``` Only define the port once, using _either_ `rmi-client-port` _or_ `jvm-options`. **💡 TIP**\ You should normally set the `rmi-client-port` value one higher than the value of [rmi-registry-port](#rmi-registry-port). **📌 NOTE**\ In the [Caplin Platform Deployment Framework](../deployment-framework/index.md), configuration macros are used to specify `rmi-client-port` for Liberator and Transformer; for example, `LIBERATOR${THIS_LEG}_JMX_RMI_CLIENT_PORT` See [Configuration macros and items](../deployment-framework/cdf-configuration-macros-and-items.md). **Use in**: C, Java **Syntax:** `rmi-client-port ` **Type:** integer **Default value:** `-1` (no port defined) ## rmi-registry-port `rmi-registry-port` defines a port in this DataSource application that a JMX-enabled monitoring client, such as the [Caplin Management Console](../cmc/index.md), uses to obtain monitored data. (It’s the port that’s used after the initial monitoring connection has been established to the port defined by [rmi-client-port](#rmi-client-port)). The registry port must be unique across all the DataSource applications executing on the same physical machine. So, when you implement an Integration Adapter, make sure its `rmi-registry-port` value is different to the settings used by Liberator and Transformer. Alternatively, you can define this port in the DataSource application’s [jvm-options](datasource-java-jvm-configuration.md#jvm-options) configuration, as follows: ``` jvm-options -Drmi.registry.port ``` Only define the port once, using _either_ `rmi-registry-port` _or_ `jvm-options`. **📌 NOTE**\ In the [Caplin Platform Deployment Framework](../deployment-framework/index.md), configuration macros are used to specify `rmi-registry-port` for Liberator and Transformer; for example, `LIBERATOR${THIS_LEG}_JMX_RMI_REGISTRY_PORT`. See [Configuration macros and items](../deployment-framework/cdf-configuration-macros-and-items.md). **Use in**: C, Java **Syntax:** `rmi-registry-port ` **Type:** integer **Default value:** `-1` (no port defined) --- **See also:** * Reference: [DataSource monitoring configuration (part 1)](datasource-datasource-monitoring-configuration-part-1.md) * Reference: [Run-time environment configuration](datasource-run-time-environment-configuration.md) * [DataSource configuration reference: Introduction](datasource-datasource-configuration-reference-introduction.md) * How Can I... [Configure DataSource monitoring](datasource-configure-datasource-monitoring.md) * [Features and concepts of DataSource monitoring and management](datasource-datasource-monitoring-and-management.md) * [Monitoring and Management in the Caplin Platform](../platform-architecture/monitoring-and-management.md) * [DataSource Configuration Syntax Reference](datasource-configuration-syntax.md) (PDF)