[JBoss JIRA] (ISPN-4132) Group-based eviction
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-4132:
----------------------------------
Summary: 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.
If the cache has grouping is enabled, however, 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
12 years
[JBoss JIRA] (ISPN-4132) Group-based eviction
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4132?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-4132:
-------------------------------
Description:
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.
was:
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.
If the cache has grouping is enabled, however, 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.
> 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
12 years
[JBoss JIRA] (ISPN-374) Add event handling to Hot Rod
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-374?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-374:
-------------------------------
Fix Version/s: 7.0.0.Final
> Add event handling to Hot Rod
> -----------------------------
>
> Key: ISPN-374
> URL: https://issues.jboss.org/browse/ISPN-374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: roadmap
> Fix For: 7.0.0.Alpha3, 7.0.0.Final
>
>
> Enable Hot Rod servers to send events asynchronously to registered clients over persistent connections. This would allow use cases such as clients maintaining L1 caches and these events could be used for servers to invalidate keys on the client side. See dev list thread for more info.
--
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
12 years
[JBoss JIRA] (ISPN-374) Add event handling to Hot Rod
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-374?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-374:
-------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha3)
> Add event handling to Hot Rod
> -----------------------------
>
> Key: ISPN-374
> URL: https://issues.jboss.org/browse/ISPN-374
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Labels: roadmap
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Enable Hot Rod servers to send events asynchronously to registered clients over persistent connections. This would allow use cases such as clients maintaining L1 caches and these events could be used for servers to invalidate keys on the client side. See dev list thread for more info.
--
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
12 years
[JBoss JIRA] (ISPN-263) Handle cluster partitions
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-263?page=com.atlassian.jira.plugin.s... ]
Mircea Markus updated ISPN-263:
-------------------------------
Fix Version/s: 7.0.0.Alpha4
7.0.0.Final
> Handle cluster partitions
> -------------------------
>
> Key: ISPN-263
> URL: https://issues.jboss.org/browse/ISPN-263
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Manik Surtani
> Assignee: Manik Surtani
> Labels: MERGE, roadmap, split_brain
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> JGroups already detects split brains and issues a callback. The cache layer needs to decide what to do. The idea is to implement a few canned policies (restart, wipe, etc) and allow custom handlers to be attached as well.
> Analogous to JBCACHE-471
--
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
12 years
[JBoss JIRA] (ISPN-3927) rethinking ISPN transactions
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3927?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3927:
--------------------------------
Fix Version/s: 7.0.0.Alpha4
(was: 7.0.0.Alpha3)
> rethinking ISPN transactions
> ----------------------------
>
> Key: ISPN-3927
> URL: https://issues.jboss.org/browse/ISPN-3927
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Mircea Markus
> Assignee: Ion Savin
> Labels: roadmap
> Fix For: 7.0.0.Alpha4, 7.0.0.Final
>
>
> Umbrella JIRA for several transaction related improvements:
> 1. Async options for commit/rollback
> - they don't really make sense as a user you don't get any guarantee on the status of the transaction
> - they complicate the code significantly
> - I think they should be removed
> 2. READ_COMMITTED
> - it has the same performance as REPEATABLE_READ, but offers less guarantees.
> - unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
> - I think it should be removed
> 3. Optimistic tx without Write Skew Check (WSC)
> - well, without WSC the transactions are not optimistic by definition
> - they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
> - suggestion: optimistic tx should *always* have WSC enabled (no option to configure it)
> - build our batching functionality on top of what currently is optimistic tx without WSC and document it as such
> 4. Remove 1PC option
> - I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing
> [1] http://markmail.org/thread/a7fjko4dyejxqgdy
> [2] https://github.com/infinispan/infinispan/pull/2177
> [3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
> [4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc
--
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
12 years