[
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). 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
> 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
> Time Spent: 10m
> 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)
