You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Dirk Rudolph (Jira)" <ji...@apache.org> on 2019/12/12 16:18:00 UTC
[jira] [Updated] (SLING-8915) Lazily replace previously cached
ResourceBundles on reload when preloading enabled
[ https://issues.apache.org/jira/browse/SLING-8915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Dirk Rudolph updated SLING-8915:
--------------------------------
Description:
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
was:
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). 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
> 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
>
> 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)