Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
i18n 2.5.10
-
None
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.
Attachments
Issue Links
- causes
-
SLING-10912 ConcurrentJcrResourceBundleLoadingTest fails with newBundleReplacesOldBundleAfterReload
-
- Closed
-
- links to
