[JBoss JIRA] (ISPN-694) Create expiration notification for in-memory cache entries
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-694?page=com.atlassian.jira.plugin.s... ]
Dan Berindei edited comment on ISPN-694 at 4/7/14 3:12 AM:
-----------------------------------------------------------
[~william.burns] for now, remote gets are sent to all the owners, so unless all the get requests are coming from the primary owner, the other owners will see some activity on the key. But maxIdle with numOwners \!= 1 will become pointless once we introduce staggered gets (I still have the branch in my repo!)
With lifespan there are consistency problems as well: the exact moment the entry is created depends on the node, so it will expire at different times on different nodes. But I guess nobody that cares about consistency uses lifespan and/or maxIdle (except maybe [~pferraro]).
was (Author: dan.berindei):
[~william.burns] for now, remote gets are sent to all the owners, so unless all the get requests are coming from the primary owner, the other owners will see some activity on the key. But maxIdle with numOwners != 1 will become pointless once we introduce staggered gets (I still have the branch in my repo!)
With lifespan there are consistency problems as well: the exact moment the entry is created depends on the node, so it will expire at different times on different nodes. But I guess nobody that cares about consistency uses lifespan and/or maxIdle (except maybe [~pferraro]).
> Create expiration notification for in-memory cache entries
> ----------------------------------------------------------
>
> Key: ISPN-694
> URL: https://issues.jboss.org/browse/ISPN-694
> Project: Infinispan
> Issue Type: Feature Request
> Components: Eviction
> Environment: any
> Reporter: Edouard Boily
> Assignee: Galder Zamarreño
> Attachments: 01.patch
>
>
> Create a CacheEntryExpired notification and make EvictionManager send this notification when a cache entry is evicted because it is expired.
> Also mage sure the cache entry value is sent over in the event.
> CacheEntryEvicted notification should also send the entry value in the event.
--
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-4188) Upgrade to Hibernate ORM 4.2.11.Final
by Sanne Grinovero (JIRA)
Sanne Grinovero created ISPN-4188:
-------------------------------------
Summary: Upgrade to Hibernate ORM 4.2.11.Final
Key: ISPN-4188
URL: https://issues.jboss.org/browse/ISPN-4188
Project: Infinispan
Issue Type: Component Upgrade
Components: Loaders and Stores
Reporter: Sanne Grinovero
Assignee: Sanne Grinovero
Priority: Minor
Fix For: 7.0.0.Alpha3
The JPACacheStore is using the quite outdated version 4.2.2.Final : updating .
--
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 edited comment on ISPN-4132 at 4/4/14 10:36 AM:
-------------------------------------------------------------
I disagree. The likelihood that a given session attribute will be accessed is not independent of, but is correlated with, the access recency of the session with which it is associated. If a session was not accessed for a given period then we know for certain that its attributes were not accessed for at least as long.
The greater point I was trying to make is: it's not always meaningful to base eviction off of a maximum number of entries. WildFly can be configured to store sessions as either 2 entries per session (the default), or N+1 entries per session, where N is the number of attributes in the session. In both cases, all cache entries associated with a session make up a single group. As a user/administrator, I am more interested in specifying the maximum number of sessions (i.e. groups) to keep in memory - irrespective of the cache entry mapping implementation details, since the desired value of max-entries would differ widely based on the session mapping strategy.
was (Author: pferraro):
I disagree. The likelihood that a given session attribute will be accessed is not independent of, but is correlated with, the access recency of the session with which it is associated. If a session was not accessed for a given period then we know for certain that its attributes were not accessed for at least as long.
The greater point I was trying to make is: it's not always meaningful to base eviction off of a maximum number of entries. WildFly can be configured to store sessions as either 2 entries per session (the default), or N+1 entries per session, where N is the number of attributes in the session. In both cases, all cache entries associated with a session make up a single group. As a user/administrator, I am more interested in specifying the maximum number of sessions (i.e. groups) to keep in memory - irrespective of the cache entry mapping implementation details, since the effective value of max-entries would differ based on the session mapping strategy.
> 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-4132) Group-based eviction
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4132?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on ISPN-4132 at 4/4/14 10:35 AM:
-------------------------------------------------------------
I disagree. The likelihood that a given session attribute will be accessed is not independent of, but is correlated with, the access recency of the session with which it is associated. If a session was not accessed for a given period then we know for certain that its attributes were not accessed for at least as long.
The greater point I was trying to make is: it's not always meaningful to base eviction off of a maximum number of entries. WildFly can be configured to store sessions as either 2 entries per session (the default), or N+1 entries per session, where N is the number of attributes in the session. In both cases, all cache entries associated with a session make up a single group. As a user/administrator, I am more interested in specifying the maximum number of sessions (i.e. groups) to keep in memory - irrespective of the cache entry mapping implementation details, since the effective value of max-entries would differ based on the session mapping strategy.
was (Author: pferraro):
I disagree. The likelihood that a given session attribute will be accessed is not independent of, but is correlated with, the access recency of the session with which it is associated. If a session was not accessed for a given period then we know for certain that its attributes were not accessed for at least as long.
The greater point I was trying to make is: it's not always meaningful to base eviction off of a maximum number of entries. WildFly can be configured to store sessions as either 2 entries per session (the default), or N+1 entries per session, where N is the number of attributes in the session. In both cases, all cache entries associated with a session make up a single group. As a user/administrator, I am more interested in specifying the maximum number of sessions to keep in memory - irrespective of the cache entry mapping implementation details, since the effective value of max-entries would differ based on the session mapping strategy.
> 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-4132) Group-based eviction
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-4132?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-4132:
------------------------------------
I disagree. The likelihood that a given session attribute will be accessed is not independent of, but is correlated with, the access recency of the session with which it is associated. If a session was not accessed for a given period then we know for certain that its attributes were not accessed for at least as long.
The greater point I was trying to make is: it's not always meaningful to base eviction off of a maximum number of entries. WildFly can be configured to store sessions as either 2 entries per session (the default), or N+1 entries per session, where N is the number of attributes in the session. In both cases, all cache entries associated with a session make up a single group. As a user/administrator, I am more interested in specifying the maximum number of sessions to keep in memory - irrespective of the cache entry mapping implementation details, since the effective value of max-entries would differ based on the session mapping strategy.
> 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-4083) Do not invalidate null Transport
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4083?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo resolved ISPN-4083.
-------------------------------
Fix Version/s: 7.0.0.Alpha3
Resolution: Done
> Do not invalidate null Transport
> --------------------------------
>
> Key: ISPN-4083
> URL: https://issues.jboss.org/browse/ISPN-4083
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 7.0.0.Alpha1
> Reporter: Radim Vansa
> Assignee: Galder Zamarreño
> Priority: Minor
> Fix For: 7.0.0.Alpha3
>
>
> In RetryOnFailureOperation.execute, when the getTransport throws TransportException, we try to invalidate the transport. However, it may be still null - in that case the invalidation fails and WARNing is logged.
> Add a check preventing invalidation with null transport.
--
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