[JBoss JIRA] (ISPN-4144) Cleanly shutdown intermediate M/R cache
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-4144?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-4144:
-----------------------------------
1) I wouldn't call clear, this operation has to lock all entries and this would most certainly cause slow down
2) Clear wouldn't get rid of the logs: if one node is not shut down yet and the others already are (and the rebalance is triggered), this node becomes owner of some new *segments*. Then it finds that there is no live owner of these segments and logs the warning. See, it's all about segment ownership, not entries.
I am not sure whether the ability to disable rebalance is currently implemented cache-wise or globally - if the latter is the case, we should probably consider more fine-grained operation.
> Cleanly shutdown intermediate M/R cache
> ---------------------------------------
>
> Key: ISPN-4144
> URL: https://issues.jboss.org/browse/ISPN-4144
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
>
> For intermediate per task caches we simply remove that cache from cache manager. This operation is cluster wide but it still triggers rebalancing which in turn possibly creates logs that might raise false alarms for admins. Investigate if calling clear before removing cache from cache manager and/or disabling rebalancing for intermediate cache leads to a "cleaner" cache shutdown.
--
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-4144) Cleanly shutdown intermediate M/R cache
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-4144?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic updated ISPN-4144:
--------------------------------------
Description: For intermediate per task caches we simply remove that cache from cache manager. This operation is cluster wide but it still triggers rebalancing which in turn possibly creates logs that might raise false alarms for admins. Investigate if calling clear before removing cache from cache manager and/or disabling rebalancing for intermediate cache leads to a "cleaner" cache shutdown.
> Cleanly shutdown intermediate M/R cache
> ---------------------------------------
>
> Key: ISPN-4144
> URL: https://issues.jboss.org/browse/ISPN-4144
> Project: Infinispan
> Issue Type: Feature Request
> Reporter: Vladimir Blagojevic
> Assignee: Vladimir Blagojevic
>
> For intermediate per task caches we simply remove that cache from cache manager. This operation is cluster wide but it still triggers rebalancing which in turn possibly creates logs that might raise false alarms for admins. Investigate if calling clear before removing cache from cache manager and/or disabling rebalancing for intermediate cache leads to a "cleaner" cache shutdown.
--
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-2916) Group-based expiration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-2916:
-------------------------------
Description:
Now that WildFly represents a web session as a group of cache entries (instead of a single entry containing an atomic map), there are a few hurdles preventing us from leveraging infinispan-managed expiration.
One of which is the fact that expiration of cache entries within a group *must* be atomic. It would be very bad if a request arrives for a session whose entries are in the process of being expired. The expiration thread should obtain a lock on *all* the keys for a group (or at least some pre-determined "primary" key), so that late session access doesn't result in session attributes mysteriously disappearing (because they were independently expired). This can also cause integrity constraint violations if cache entries reference other entries in the group. e.g. currently the "primary" cache entry for a session (keyed by session id), contains a set of attribute names. These names correspond to other cache entries that contain the value of a given attribute for that session.
was:
Now that WildFly represents a web session as a group of cache entries (instead of a single entry containing an atomic map), there are a few hurdles preventing us from leveraging infinispan-managed expiration.
One of which is the fact that expiration of cache entries within a group *must* be atomic. It would be very bad if a request arrives for a session whose entries are in the process of being expired. The expiration thread should obtain a lock on *all* the keys for a group, so that late session access doesn't result in session attributes mysteriously disappearing (because they were independently expired). This can also cause integrity constraint violations if cache entries reference other entries in the group. e.g. currently the "primary" cache entry for a session (keyed by session id), contains a set of attribute names. These names correspond to other cache entries that contain the value of a given attribute for that session.
> Group-based expiration
> ----------------------
>
> Key: ISPN-2916
> URL: https://issues.jboss.org/browse/ISPN-2916
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.2.5.Final
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
>
> Now that WildFly represents a web session as a group of cache entries (instead of a single entry containing an atomic map), there are a few hurdles preventing us from leveraging infinispan-managed expiration.
> One of which is the fact that expiration of cache entries within a group *must* be atomic. It would be very bad if a request arrives for a session whose entries are in the process of being expired. The expiration thread should obtain a lock on *all* the keys for a group (or at least some pre-determined "primary" key), so that late session access doesn't result in session attributes mysteriously disappearing (because they were independently expired). This can also cause integrity constraint violations if cache entries reference other entries in the group. e.g. currently the "primary" cache entry for a session (keyed by session id), contains a set of attribute names. These names correspond to other cache entries that contain the value of a given attribute for that session.
--
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-3979) JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-3979?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on ISPN-3979:
------------------------------------
Can this be addressed for 7.0?
> JdbcStringBasedStore loading of Key2StringMapper class is too restrictive
> -------------------------------------------------------------------------
>
> Key: ISPN-3979
> URL: https://issues.jboss.org/browse/ISPN-3979
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.1.Final
> Reporter: Paul Ferraro
> Assignee: Dan Berindei
> Priority: Critical
>
> Currently the Key2StringMapper of a JdbcStringBasedStore is specified to the JdbcStringBasedStoreConfigurationBuilder as a class name. Yes, there is a method that accepts a Class<? extends Key2StringMapper>, but that simply stores the getName() of the Class! The JdbcStringBasedStore loads the class using the class loader of the JdbcStringBasedStore class (via Class.forName(...). This is too restrictive. At the very least, JdbcStringBasedStore should use the classLoader defined in the cache Configuration (i.e. via ConfigurationBuilder.classLoader()) to load the class. Why not also allow the JdbcStringBasedStoreConfigurationBuilder to specify a Key2StringMapper instance?
> I would really like to make use of Key2StringMapper in WildFly to allow users the option to persist web sessions and SFSBs via the JdbcStringBasedStore (instead of the binary bucket-based store), but the current mechanism is incompatible with use cases where the Key2StringMapper is not known to class loader of the infinispan module.
--
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-2916) Group-based expiration
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/ISPN-2916?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated ISPN-2916:
-------------------------------
Description:
Now that WildFly represents a web session as a group of cache entries (instead of a single entry containing an atomic map), there are a few hurdles preventing us from leveraging infinispan-managed expiration.
One of which is the fact that expiration of cache entries within a group *must* be atomic. It would be very bad if a request arrives for a session whose entries are in the process of being expired. The expiration thread should obtain a lock on *all* the keys for a group, so that late session access doesn't result in session attributes mysteriously disappearing (because they were independently expired). This can also cause integrity constraint violations if cache entries reference other entries in the group. e.g. currently the "primary" cache entry for a session (keyed by session id), contains a set of attribute names. These names correspond to other cache entries that contain the value of a given attribute for that session.
was:While exploring the possibility of replacing single cache entries containing atomic maps with multiple cache entries using the grouping api, it occurred to me that to do this would require auto-eviction/expiration to be atomic for a group. Otherwise, we would run the risk of integrity constraint violations when cache entries are automatically expired or evicted.
> Group-based expiration
> ----------------------
>
> Key: ISPN-2916
> URL: https://issues.jboss.org/browse/ISPN-2916
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Affects Versions: 5.2.5.Final
> Reporter: Paul Ferraro
> Assignee: Mircea Markus
>
> Now that WildFly represents a web session as a group of cache entries (instead of a single entry containing an atomic map), there are a few hurdles preventing us from leveraging infinispan-managed expiration.
> One of which is the fact that expiration of cache entries within a group *must* be atomic. It would be very bad if a request arrives for a session whose entries are in the process of being expired. The expiration thread should obtain a lock on *all* the keys for a group, so that late session access doesn't result in session attributes mysteriously disappearing (because they were independently expired). This can also cause integrity constraint violations if cache entries reference other entries in the group. e.g. currently the "primary" cache entry for a session (keyed by session id), contains a set of attribute names. These names correspond to other cache entries that contain the value of a given attribute for that session.
--
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