[jira] [Comment Edited] (DELTASPIKE-1277) Force refresh of cached config values
[ https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082350#comment-16082350 ] Alexander Falb edited comment on DELTASPIKE-1277 at 7/11/17 3:09 PM: - (Uploaded central_caching.patch) This is a first try of how a central cache could work. It is far from perfect, because of the dynamic nature of cache-keys containing projectstage and/or parameters. There are at least a dozen of unit tests missing covering all sorts of loading a projectstaged/parameterized keys, caching it, changing the other value, reloading it and so on, but I think this could be a start at least. What do you think? was (Author: elexx): This is a first try of how a central cache could work. It is far from perfect, because of the dynamic nature of cache-keys containing projectstage and/or parameters. There are at least a dozen of unit tests missing covering all sorts of loading a projectstaged/parameterized keys, caching it, changing the other value, reloading it and so on, but I think this could be a start at least. What do you think? > Force refresh of cached config values > - > > Key: DELTASPIKE-1277 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Reporter: Alexander Falb > Attachments: central_caching.patch, forcerefresh.patch > > > When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled, > there is no way of bypassing the cache and forcefully reloading the value > from underlying datasources. > The attached patch is a proposal of creating such an mechanism. It introduces > a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this > method by resetting the {{reloadAfter}} field and adds a unit test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (DELTASPIKE-1277) Force refresh of cached config values
[ https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Falb updated DELTASPIKE-1277: --- Attachment: central_caching.patch This is a first try of how a central cache could work. It is far from perfect, because of the dynamic nature of cache-keys containing projectstage and/or parameters. There are at least a dozen of unit tests missing covering all sorts of loading a projectstaged/parameterized keys, caching it, changing the other value, reloading it and so on, but I think this could be a start at least. What do you think? > Force refresh of cached config values > - > > Key: DELTASPIKE-1277 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Reporter: Alexander Falb > Attachments: central_caching.patch, forcerefresh.patch > > > When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled, > there is no way of bypassing the cache and forcefully reloading the value > from underlying datasources. > The attached patch is a proposal of creating such an mechanism. It introduces > a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this > method by resetting the {{reloadAfter}} field and adds a unit test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DELTASPIKE-1277) Force refresh of cached config values
[ https://issues.apache.org/jira/browse/DELTASPIKE-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16082443#comment-16082443 ] Romain Manni-Bucau commented on DELTASPIKE-1277: Really looks close to what I have in mind. I have however some questions after the patch review (some unclear area): - if not using caching do we still "cache" in the shared cache? If not we can try to do it I think otherwise if you read twice the same key the behavior is now different from what it is today (you can get a corrupted data) - any reason to not move to a ConfigContext and add another Map (tried to write it in previous comment but re-reading it was maybe not clear): I think it would be beneficial to store all config contextual (per classloader) data in a single structure (I called it ConfigContext but any other name is good). It would allow to have all the data you can need in all related places and avoid to clear cache in config source method for instance ;) Once these small tech-y details "fixed"/"discussed" I'd like to have a small iteration on the API. Maybe having a "ConfigCacheManager" can be beneficial instead of polluting the ConfigResolver itself (even if it delegates, it is purely in term of API here) and we should surely embrace more java 8 - just providing functional interface but not having any strong adherance): {code} // surely added as a bean but also accessible from the ConfigContext for extensions? public interface ConfigCacheLManager { void clear(); void remove(String key); void removeIf(BiPredicate predicate); // for all cached values, if the predicate matches then remove } {code} Nice thing about the removeIf is it allows to manage easily (startsWith/endsWith) groups of keys (startsWith("app.database.")). Hope it makes sense > Force refresh of cached config values > - > > Key: DELTASPIKE-1277 > URL: https://issues.apache.org/jira/browse/DELTASPIKE-1277 > Project: DeltaSpike > Issue Type: Improvement > Components: Configuration >Reporter: Alexander Falb > Attachments: central_caching.patch, forcerefresh.patch > > > When using a {{TypedResolver}} or {{UntypedResolver}} with caching enabled, > there is no way of bypassing the cache and forcefully reloading the value > from underlying datasources. > The attached patch is a proposal of creating such an mechanism. It introduces > a {{void forceRefresh()}} method to the {{TypedResolver}}, implements this > method by resetting the {{reloadAfter}} field and adds a unit test. -- This message was sent by Atlassian JIRA (v6.4.14#64029)