sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konrad Windszus (Jira)" <j...@apache.org>
Subject [jira] [Resolved] (SLING-8915) Lazily replace previously cached ResourceBundles on reload when preloading enabled
Date Thu, 19 Dec 2019 08:44:00 GMT

     [ https://issues.apache.org/jira/browse/SLING-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Konrad Windszus resolved SLING-8915.
------------------------------------
    Resolution: Fixed

Fixed in https://github.com/apache/sling-org-apache-sling-i18n/commit/95eb584a2dbcc2f7b599f4e5f3d16498d2cd6a55.
[~diru] Thanks for the contribution.

> Lazily replace previously cached ResourceBundles on reload when preloading enabled
> ----------------------------------------------------------------------------------
>
>                 Key: SLING-8915
>                 URL: https://issues.apache.org/jira/browse/SLING-8915
>             Project: Sling
>          Issue Type: Improvement
>          Components: i18n
>    Affects Versions: i18n 2.5.10
>            Reporter: Dirk Rudolph
>            Priority: Major
>             Fix For: i18n 2.5.16
>
>          Time Spent: 40m
>  Remaining Estimate: 0h
>
> In the default configuration of the JcrResourceBundleProvider a change to a message entry
in an already cached ResourceBundle simply removes the cached entry. Loading the bundle again
with the previous change in place happens the next time the ResourceBundle is used, commonly
as part of the next request serving content with the given locale+basename.
> This works fine as long as loading the JcrResourceBundle is a matter of a few milliseconds
but in our case loading the bundle takes up to 10% of an individual requests effective response
time. Additionally we see further negative impact as a message entry is in many cases changed
not only for one locale but for multiple at once.
> Assuming we can enable preloading, I want to propose to instead of removing the cached
ResourceBundles (clear-and-set), still serve them and replace them once the reloaded ResourceBundle
is created (replace). It will add the time for creating the new instance of the ResourceBundle
to the execution of the background thread without blocking requests accessing the still valid
cache. This will work fine for reloading individual bundles [1]. How much sense it makes for
reloading all bundles I don't have data for yet.
> [1] https://github.com/apache/sling-org-apache-sling-i18n/blob/master/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java#L363



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message