| 3.1. | Does JBoss Cache support eviction policies? |
| Yes. JBoss Cache currently supports multiple eviction policies such as LRU, MRU, and FIFO.
Users can also plug in their own eviction policy algorithms. See user
manual for details.
|
| 3.2. | Does JBoss Cache's eviction policy operates in
replication mode?
|
| Yes and no. :-) The eviction policy only operates in local mode. That is, nodes are
only evicted locally. This may cause the cache contents not to be
synchronized temporarily. But when a user tries to obtain the cached
contents of an evicted node and finds out that is null (e.g.,
get
returns null), it should get it from the
other data source and re-populate the data in the cache. During this
moment, the node content will be propagated and the cache content
will be in sync.
However, you still can run eviction policies with cache mode
set to either
REPL_SYNC
or
REPL_ASYNC
. Depending on your use case, you can
set multiple cache instances to have their own eviction policy
(which are applied locally) or just have selected instances with
eviction policies activated.
Also note that, with cache loader option, a locally evicted
node can also be persisted to the backend store and a user can
retrieve it from the store later on.
|
| 3.3. | Does JBoss Cache support
Region
?
|
| Yes. JBoss Cache has the notion of region where a user can
configure the eviction policy parameters (e.g.,
maxNodes
or
timeToIdleSeconds
)
A region in JBoss Cache denotes a portion of tree hierarchy,
e.g., a fully qualified name (
org.jboss.cache.Fqn
). For example,
a user can define
/org/jboss
and
/org/foocom
as two separate regions. But note
that you can configure the region programmatically now, i.e.,
everything has to be configured through the xml file.
|
| 3.4. | What are the
EvictionPolicyConfig
tag
parameters for
org.jboss.cache.eviction.LRUPolicy
?
|
| They are: Table 3.1. Parameters | eventQueueSize | A fine-tuning parameter where you can configure the size of the eviction notification
event queue. Defaults to 200,000.
| | wakeUpIntervalInSeconds | Interval where the clean up thread wakes to process
the sitting queue and sweep away the old data.
| | region | A area where each eviction policy parameters are
specified. Note that it needs a minimum of
/_default
region.
| | maxNodes | Max number of nodes allowed in the eviction queue. 0
means no limit.
| | timeToLiveInSeconds | Age (in seconds) for the node to be evicted in the
queue. 0 denotes no limit.
|
|
| 3.5. | I have turned on the eviction policy, why do I still get "out
of memory" (OOM) exception?
|
| OOM can happen when the speed of cache access exceeds the
speed of eviction policy handling timer. Eviction policy handler
will wake up every
wakeUpIntervalInSeconds
seconds to process the eviction event queue. So when the queue size is full, it will create a
backlog and cause out-of-memory exceptions to happen unless the eviction timer catches
up. To address this problem, in addition to increase the VM heap
size, you can also reduce the
wakeUpIntervaleInSeconds
so the timer thread
processes the queue more frequently.
The eviction queue size is configurable.
|