BigMemory 4.4.0 | Product Documentation | BigMemory Max Configuration Guide | Configuring Nonstop Operation | Tuning for Nonstop Timeouts and Behaviors
 
Tuning for Nonstop Timeouts and Behaviors
You can tune the default timeout values and behaviors of nonstop caches to fit your environment.
Tuning for Network Interruptions
For example, in an environment with regular network interruptions, consider disabling immediateTimeout and increasing timeoutMillis to prevent timeouts for most of the interruptions.
For a cluster that experiences regular but short network interruptions, and in which caches clustered with Terracotta carry read-mostly data or there is tolerance of potentially stale data, you may want to set timeoutBehavior to localReads.
Tuning for Slow Cache Operations
In an environment where cache operations can be slow to return and data is required to always be in sync, increase timeoutMillis to prevent frequent timeouts. Set timeoutBehavior to noop to force the application to get data from another source or exception if the application should stop.
For example, a cache.acquireWriteLockOnKey(key) operation may exceed the nonstop timeout while waiting for a lock. This would trigger nonstop mode only because the lock couldn't be acquired in time. Using cache.tryWriteLockOnKey(key, timeout), with the method's timeout set to less than the nonstop timeout, avoids this problem.
Bulk Loading
If a nonstop cache is bulk-loaded using the Bulk-Load API, a multiplier is applied to the configured nonstop timeout whenever the method net.sf.ehcache.Ehcache.setNodeBulkLoadEnabled(boolean) is used. The default value of the multiplier is 10. You can tune the multiplier using the bulkOpsTimeoutMultiplyFactor system property:
-Dnet.sf.ehcache.nonstop.bulkOpsTimeoutMultiplyFactor=10
Note that when nonstop is enabled, the cache size displayed in the Terracotta Management Console is subject to the bulkOpsTimeoutMultiplyFactor. Increasing this multiplier on the clients can facilitate more accurate size reporting.
This multiplier also affects the methods:
net.sf.ehcache.Ehcache.getAll()
net.sf.ehcache.Ehcache.removeAll()
net.sf.ehcache.Ehcache.removeAll(boolean)
Printing Stack Traces on Exceptions
You can turn on additional logging (at the INFO level) for nonstop timeouts using:
-Dnet.sf.ehcache.nonstop.printStackTraceOnException=true
This is a dynamic property that can also be managed programmatically:
System.setProperty(PRINT_STACK_TRACE_ON_EXCEPTION_PROPERTY, "true")
This property logs the stack trace for the nonstop thread. Note that, with this property set, log files can become very large in environments in which a large number of timeouts occur.