[infinispan-issues] [JBoss JIRA] (ISPN-4132) Group-based eviction
Paul Ferraro (JIRA)
issues at jboss.org
Wed Apr 9 09:52:13 EDT 2014
[ https://issues.jboss.org/browse/ISPN-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12960516#comment-12960516 ]
Paul Ferraro commented on ISPN-4132:
------------------------------------
"So at any time it might make sense to keep in memory some of the attributes of S, but not all of them."
Not really. In WF/EAP, the sessions to be passivated are primarily expected to be abandoned sessions, that is, session that I expect to eventually expire. Our primary use case for passivation is *not* as a means to handle more active sessions that a given server can keep in memory - but rather to handle the abandoned, but not yet expired sessions. In this way, I would typically prefer to evict all entries of a presumably abandoned session over the attributes of an active session that have not been accessed recently. The likelihood that the former will be accessed before the latter is typically low.
But no, there isn't anything in the JEE standard about how one specifies how sessions are passivated.
Your point about this being too complex is certainly valid, so let's try a different tack...
What if we had the ability to specify that a given cache entry was never to be passivated automatically (i.e. like an immortal cache entry, but for eviction purposes)? Infinispan would then passivate based on a max-size of "auto-evictable" cache entries (i.e. some subset of the total entries in memory).
This way, I can leverage a passivation callback to manually passivate the non-auto-evictable session attributes for a given session and still be able to define my eviction settings based on a maximum number of sessions. WDYT?
> Group-based eviction
> --------------------
>
> Key: ISPN-4132
> URL: https://issues.jboss.org/browse/ISPN-4132
> Project: Infinispan
> Issue Type: Feature Request
> Components: Eviction
> Affects Versions: 6.0.2.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
>
> Currently, Infinispan only supports size-based eviction. We can configure a cache with a specific max-entries, so if the size exceeds this value infinispan will evict any surplus entries.
> However, if the cache has grouping enabled, it is perhaps more useful to use group-based eviction. In this scenario, max-entries would be interpreted as "max-groups", and infinispan would evict entire groups of cache entries if the number of groups exceeds this value.
> In WildFly, web sessions make use of grouping. A single web session will map to a single group of multiple cache entries, where the number of entries is not necessarily the same for a given session. In this case, evicting per cache entry does not make sense - all entries of a session should be evicted or not at all. Also, users can specify the max number of sessions they want to remain in memory. Until infinispan supports group-based eviction, translating this value to an appropriate max-entries is cumbersome and imprecise.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list