MCS uses caching in order to avoid accessing the repository for policies that have been retrieved recently. The caches can be monitored and managed by a JMX based client. JMX is a mechanism that allows administrators to monitor and dynamically manage resources in running applications. These resources are represented by MBeans, and a repository of MBeans is called an MBean server. In MCS, there are three MBeans for each policy type (image, layout, theme, etc.) and for each pipeline cache: one for managing a cache (CacheMBean), one for accessing cache statistics (StatisticsMBean), and one for periodic monitoring of various cache statistics (MonitorMBean). In addition, there is an MBean that allows administrators to manage a collection of cache MBeans as a group (CacheCollectionMBean).
MCS uses caching in order to avoid accessing the repository for policies that have been retrieved recently. The caches can be monitored and managed by a JMX based client. JMX is a mechanism that allows administrators to monitor and dynamically manage resources in running applications. These resources are represented by MBeans, and a repository of MBeans is called an MBean server. In MCS, there are three MBeans for each policy type (image, layout, theme, etc.) and for each pipeline cache: one for managing a cache (CacheMBean), one for accessing cache statistics (StatisticsMBean), and one for periodic monitoring of various cache statistics (MonitorMBean). In addition, there is an MBean that allows administrators to manage a collection of cache MBeans as a group (CacheCollectionMBean).
The MonitorMBean and StatisticsMBean interfaces are very similar. The main difference between them is that StatisticsMBean updates the properties values after taking a snapshot of statistics, i.e. after executing the StatisticsMBean.takeSnapshot() method, whereas MonitorMBean updates the properties values every time their accessor method is called. Therefore, MonitorMBean is intended to be used by JMX clients that can repeatedly (every N seconds) poll an MBean and construct a graph showing how the value of a given property changes over time. Note, however, that values returned for two different properties, even if called at the same time, are not guaranteed to be synchronized with one another.
The management section in the mcs-config.xml file can contain two mutually exclusive elements that configure access to an MBean server. The jndi-mbean-server element specifies that MCS will register its MBeans with the specified JNDI resource. This element should be used when MCS is deployed on the application server that allows arbitrary objects to be stored in JNDI. The platform-mbean-server element specifies that MCS will register its MBeans into the platform MBean server. This element should be used when MCS is deployed on the application server that exports a fixed set of MBean servers through JNDI.
The role attribute of the management element can be used to differentiate between MBeans registered by two instances of MCS running within the same application server.
Copy the com.volantis.synergetics.management-jndi-impl-6.3.1.jar file from the ${MCS_HOME}/ext directory to the common libs directory of your application server. .
If your application server exports a fixed set of MBean servers, then you must skip this step.
<Resource name="management/MBeanFactory"
auth="Container"
type="javax.management.MBeanServer"
factory="com.volantis.openapi.synergetics.impl.management.jndi.MBeanServerObjectFactory"/>If your application server exports a fixed set of MBean servers, then you must skip this step.
Configure the MBean server in mcs-config.xml. If your application server supports custom objects in JNDI, then add the jndi-mbean-server element. Make sure it points to the JNDI datasource specified previously.
<management>
<jndi-mbean-server initial-context="/mcs" name="management/MBeanFactory"/>
</management>If your application server exports a fixed set of MBeanServers through JNDI, then add the platform-mbean-server element.
<management>
<platform-mbean-server/>
</management>-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=9004
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=falseJMX-compliant clients can be used to monitor and manage caches using JMX technology. When the client establishes the connection with an application server, it obtains information from the MBeans in the connected JMX agent, and displays available information. JConsole is an example of a JMX-compliant client. It can connect to a Java virtual machine running on the local or remote system. Refer to Using JConsole to Monitor Applications for further information.
MCS provides four MBean interfaces.
An MBean for managing a collection of cache MBeans as a group.
An MBean for managing a cache.
An MBean for periodic monitoring of various cache statistics.
An MBean for accessing cache statistics.
Refer to the MCS JavaDocs for further information.
The CacheCollectionMBean interface consists of the following methods:
| Method | Description |
|---|---|
| dumpState(contents) | Dumps the state of the cache to the log file, ${MCS_HOME}/webapps/mcs.war/logs/mcs.log by default. The content parameter specifies if the contents of the cache, i.e. the objects cached must be dumped. The possible values are: 'true' and 'false'. |
| dumpStatistics() | Takes a snapshot of the statistics and dumps them to the log file, ${MCS_HOME}/webapps/mcs.war/logs/mcs.log by default. |
| flush() | Flushes the contents of the cache. |
| getCacheNames() | Returns the names of the cache MBeans contained within this collection. |
| resetStatistics() | Resets the statistics to their initial values. |
The CacheMBean interface consists of the following methods:
| Method | Description |
|---|---|
| dumpState(contents) | Dumps the state of the cache to the log file, ${MCS_HOME}/webapps/mcs.war/logs/mcs.log by default. The content parameter specifies if the contents of the cache, i.e. the objects cached must be dumped. The possible values are: 'true' and' false'. |
| dumpStatistics() | Takes a snapshot of the statistics and dumps them to the log file, ${MCS_HOME}/webapps/mcs.war/logs/mcs.log by default. |
| flush() | Flushes the contents of the cache. |
| resetStatistics() | Resets the statistics to their initial values. |
The MonitorMBean interface consists of the following methods:
| Method | Description |
|---|---|
| getAddMissCount() | Returns the number of queries that could not be satisfied by the cache, i.e. missed, and so resulted in a new entry being added. |
| getEntryCount() | Returns the total number of entries in the cache. |
| getHighWaterMark() | Returns the highest number of entries. |
| getHitCount() | Returns the hit count for the cache. This is the number of queries that could be satisfied by the cache. |
| getHitRate() | Returns the hit rate. |
| getMaxEntries() | Returns the maximum number of entries in the cache. |
| getPruneCount() | Returns the number of entries that have been pruned. |
| getQueryCount() | Returns the total number of queries on the cache. |
The StatisticsMBean interface consists of the following methods:
| Method | Description |
|---|---|
| getAddMissCount() | Returns the number of queries that could not be satisfied by the cache, i.e. missed, and so resulted in a new entry being added. |
| getCacheStrategy() | Returns the cache strategy. |
| getEntryCount() | Returns the total number of entries in the cache. |
| getHighWaterMark() | Returns the highest number of entries. |
| getHighWaterMarkTime() | Returns the time at which StatisticsMBean.getHighWaterMark() was set. |
| getHitCount() | Returns the hit count for the cache. This is the number of queries that could be satisfied by the cache. |
| getHitRate() | Returns the hit rate. |
| getMaxEntries() | Returns the maximum number of entries in the cache. |
| getPruneCount() | Returns the number of entries that have been pruned. |
| getPruneTime() | Returns the time at which the last prune took place. A prune occurs when an entry is removed, either because it has expired, or space needs to be made for a new entry. |
| getQueryCount() | Returns the total number of queries. |
| getSnapshotTime() | Returns the time at which the snapshot was taken. |
| getStartTime() | Returns the time from which these statistics were gathered. This is either the time at which the cache was created, or the last time at which the statistics were reset, whichever is most recent. |
| resetStatistics() | Resets the statistics to the values they would have had if the application had only just been started, although with a populated cache, i.e. start time and high water mark time are set to the current time; snapshot time and prune time are invalidated, i.e. treated as though no snapshots/prunes have occurred; max entries and entry count remain the same; high water mark is set to the current entry count; hit count, add/miss count, prune count and query count are set ot '0'. |
| takeSnapshot() | Takes a snapshot of statistics. All statistics have to be accessed atomically as they are constantly changing and getting them separately could result in inconsistent values. This will atomically update the other fields making sure that they are self consistent. The statistics are aggregated either from when the cache was created, or they were reset using StatisticsMBean.resetStatistics(). |
You configure the log file in mcs-jlog.xml. Initially, com.volantis.cache.impl.mbeans.DumperUtilities uses the default appender, i.e. cache statistics are dumped to the mcs.log file found in the ${MCS_HOME}/webapps/mcs.war/logs/ directory.
<category name="com.volantis.cache.impl.mbeans.DumperUtilities">
<priority value="info"/>
<appender-ref ref="ASYNC"/>
</category>You can always create your own appender in the mcs-jlog.xml file, and then change the reference in the com.volantis.cache.impl.mbeans.DumperUtilities category.