[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=16426816#comment-16426816
]
ASF subversion and git services commented on DELTASPIKE-1277:
-
Commit 0ec1c1e5bca85141ddbe164d50743c13b572e73b in deltaspike's branch
refs/heads/master from [~struberg]
[ https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;h=0ec1c1e ]
DELTASPIKE-1335 DELTASPIKE-1277 fix reportChangeListener
Also implement the config change callback in the new
ConfigurableTestConfigSource
> 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
>Assignee: Mark Struberg
>Priority: Major
> 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
(v7.6.3#76005)
[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=16425333#comment-16425333
]
Mark Struberg commented on DELTASPIKE-1277:
---
Implemented together with [~elexx] and committed in 04cf7acd667d27ed8fa and
73cb1ca7ab185a09.
> 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
>Assignee: Mark Struberg
>Priority: Major
> 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
(v7.6.3#76005)
[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=16084084#comment-16084084
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hmm, not sure why it would prevent to log changes more than today. In case of
no cache we shouldnt hit any cache IMHO.
Logging a wrong value is as bad as using a wrong value at runtime because IIRC
this log statement was "ops" intended so it would lead to a misunderstanding of
the system which is quite dangerous.
What's the blocker - technically -to bypass any cache if cache is disabled?
Directly going to the ConfigResolver (configsources) sounds doable and a good
option to me. Am I missing something?
> 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=16083964#comment-16083964
]
Alexander Falb commented on DELTASPIKE-1277:
Yes we could, but then again, we would not be able to log any changes, if we
don't load the last value from the cache. On the other hand, maybe logging
should be done in the not-yet-existing CacheManager (during a put of a new
value into the manager) rather than in the PropertyBuilder? But removing
{{logChanges()}} would change the API of PropertyBuilder.
What do you mean with, we could get corrupted data if we read the same key
twice? I can only think of getting wrong log output. ie when having 2
PropertyBuilder with the same key, both with caching disabled and logging
enabled. If we call getValue on the 1st, changing the value and calling
getValue on the 2nd, the second one would log a change even if it never ever
resolved the value before.
> 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=16083879#comment-16083879
]
Alexander Falb commented on DELTASPIKE-1277:
Thanks for the feedback!
* Yes we need to write to some sort of cache, even if caching is disabled. If
not we could not log changes. Ofc we could use the internal cache for this (the
{{T lastValue}} i removed) but I dont see the pro for this. But the cached
value is only returned if {{cacheTimeMs > 0}} otherwise it gets reloaded.
* No particular reason. I just didn't want to clutter the commit with a
refactoring. But I totally agree, the 1200+ lines of ConfigResolver is way to
much, it really needs a refactoring.
I like the ConfigCacheManager idea! Although Deltaspike currently compiles
against Java 6 (afair), so we would need to update that first.
> 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=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)
[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=16080333#comment-16080333
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hi Alexander,
yes this map would be a good entry point. We can't use a cdi bean yet because
1. it must work in extensions themself so no bean yet, 2. there are some
workarounds for ears and some containers so even if less elegant the map is
more reliable for now. The type resolvers always being contextual you should be
able to use this map to get the "current" tracker/storage. ConfigResolver has
the role of storage today, I'm not sure it fully fit the perf requirements
since you can get a slow config source but adding a light cache with eviction
on top of it would be easy. In term of internal refactoring it would just
require to store a ConfigContext per classloader instead of just
sources/converters etc to be able to add more contextual data to it IMO. I'm
sure there are other solution but I don't see any blocker to do it.
wdyt?
> 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: 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=16080324#comment-16080324
]
Alexander Falb commented on DELTASPIKE-1277:
Hi Romain,
I'm not sure about which storage by application you are talking about. The
{{Map configSources}}?
Having a service (Bean or just some static methods) to retrieve all
PropertyBuilders created by the application would be the goal. Ofc an iterator
of them would provide even more options than a simple {{getByKey}}, like the
proposed {{refreshValue("key")}}. But I'm still not sure where to collect all
the created PropertyBuilders.
Alex
> 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: 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=16066657#comment-16066657
]
Romain Manni-Bucau commented on DELTASPIKE-1277:
Hi Alexander,
patch looks good to me (just wonder if signature should ve TypeResolver
refresh() instead of void forceRefresh() but we are really at the detail level)
Now I have to admit i like the other propose and even more if wired to a
deltaspike service (understand a CDI bean) since it would allow for instance to
have a /evict endpoint not requiring to track all resolver instances which
pollutes (today) the code for a technical concern. We already have a storage
"by application" for the sources/config so it seems not hard to have a cache
storage mapped on it. Only trick will be to have a nice key preventing conflict
between resolver (string key doesnt work right?) but nothing we can't solve.
Hope it helps a bit to move forward
Romain
> 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: 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=16066638#comment-16066638
]
Alexander Falb commented on DELTASPIKE-1277:
The problem I am trying to solve is mostly regarded to unit tests. When testing
a service that uses _Resolvers_ with caching enabled it's not possible to load
a new value if one is already cached.
Another idea to forcefully reload cached values would be some sort of global
eviction. I had some {{ConfigResolverUtils.refreshValue("key")}} in mind. From
a usage point of view I would prefer this to the solution provided by the
patch, because there would be no need the get hold of the actual resolver. But
on the other hand all resolvers then have to register to some global
registration point. That also sounded not that "fun" to implement, so I finally
decided to propose a minimally invasive and simple solution, to get some early
feedback. But if you are interested I could work on the other idea too.
> 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: 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)
