[
https://issues.jboss.org/browse/ISPN-10645?page=com.atlassian.jira.plugin...
]
Will Burns edited comment on ISPN-10645 at 9/25/19 12:12 PM:
-------------------------------------------------------------
This is expected behavior.
The 59 is due to entries expiring after 60 seconds, which means with an insertion rate of
1 per second will only have 59-60 entries in the cache at a time.
The cache dropping to a size of 2 is because of the access pattern and the fact that the
expiration reaper is disabled. Caffeine uses the TinyLFU algorithm for its eviction.
Effectively what happened is that it is Caffeine uses an eden space of 2 that store the
most recently added entries. Once this fills up it will add that entry into the main
space. Due to the access pattern it has determined the new entry promoted to the main
space should be immediately evicted. This causes the cache to have 2 "new"
entries that aren't expired and 118 that are expired and aren't being evicted. If
you enable the reaper it will clean these out sooner and never get to that point.
was (Author: william.burns):
This is expected behavior.
The 59 is due to entries expiring after 60 seconds, which means with an insertion rate of
1 per second will only have 59-60 entries in the cache at a time.
The cache dropping to a size of 2 is because of the access pattern and the fact that the
expiration reaper is disabled. Caffeine uses the TinyLFU algorithm for its eviction.
Effectively what happened is that it is Caffeine uses an eden space of 2 that store the
most recently added entries. Once this fills up it will add that entry into the main
space. Due to the access pattern it has determined the new entry should be immediately
evicted. This causes the cache to have 2 "new" entries that aren't expired
an 118 that are expired and aren't being evicted. If you enable the reaper it will
clean these out sooner and never get to that point.
Configured eviction bases on COUNT will unexpected start eviction to
early and might evict until the cache is empty
-------------------------------------------------------------------------------------------------------------------
Key: ISPN-10645
URL:
https://issues.jboss.org/browse/ISPN-10645
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 10.0.0.CR2
Reporter: Wolf-Dieter Fink
Assignee: Will Burns
Priority: Major
If a cache is populated and configured with eviction and maybe expiration the eviction
will start earlier than expected and the size count will go down to more or less 0.
Assume the cache is configured like this
<distributed-cache name="ExpirationCache">
<memory>
<binary eviction="COUNT" size="120"/>
</memory>
<expiration lifespan="60000"
interval="-1"/>
</distributed-cache>
The client is simple and add a new entry every second to keep the monitoring simple
minute 1 - entries are added up to ~59 without eviction
minute 2 - entries are added but the cache.size() is still 59
CLI check attribute number_of_entries and evictions for the cache
shows the same size and no eviction
minute 3 - continue adding, cache.size()==59 but
CLI shows the same size and increasing evictions
minute 4 - still adding but size() decrease as well as CLI n-o-e and evictions grow
The fact is that having less than 120 entries in the cache is unexpected as well as
remove more entries after a time.
The issue remain for
<off-heap> and <object> with object count.
as well as without exiration element or configured with interval - here the entries are
expiring but eviction will have effects as well and drop the cache content unexpected.
So it seems not releated to expiration at all
--
This message was sent by Atlassian Jira
(v7.13.8#713008)