[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)
