Monitoring cache

The number of records a JVM caches depend on many factors including the type of transaction, the data that it retrieves, the breadth of functionality used, and possibly seasonality.

For example, an agent that is configured to Schedule Orders only caches records that is used by the Schedule transaction. An application server, in contrast, serves a broad range of transactions and typically requires more memory for the cache. An application server that services both Distributed Order Management (DOM) and Sterling Store Inventory Management (SIM) likely caches more records than one that only services DOM.

You can monitor cache usage from the System Management Console. Go to the Detail page for an application server or the Sterling Order Management System Software agent. Press the "Table Level Cache" button.

Cache drop messages

The cache manager produces the following message, at the log4j1 WARN level, to report cache flushes:


   2011-02-11 13:10:44,753:WARN   :main: Clearing cache. Number
    cached=7787,Lists cached=2,Singletons cached=2: YFS_ResourceDBCacheHome

The "number cached" refers to the cached records (OBJECTS). The "Lists cached" refers to the LIST WHERE clauses. The "Singletons cached" refers to the "SELECT WHERE clauses".

YFS_HEARTBEAT

Sterling Order Management System Software records an entry into the YFS_HEARTBEAT table for each application server and each Sterling Order Management System Software server that starts up. These entries enable Sterling Order Management System Software to manage servers and to broadcast cached data updates to them. When a Sterling Order Management System Software server is shut down normally, the corresponding YFS_HEARTBEAT record is removed.

When a Sterling Order Management System Software server ends abnormally (or whenever an application server ends) the corresponding record can remain in the YFS_HEARTBEAT table even though it no longer points to a valid running server. These pointers to servers that are no longer running are known as "stale entries." Large number of stale entries could slow down the management of the servers. For example, the cache refresh broadcast will have to try to notify the servers pointed by the stale entries.

Periodically, each JVM updates its status in its YFS_HEARTBEAT record. By default, that refresh interval is set to yantra.statistics.persist.interval / 2 or 5 minutes.

To eliminate stale entries from the JNDI tree, you should run the Health Monitor agent.