Details
-
Improvement
-
Status: Closed
-
Major
-
Resolution: Fixed
-
i18n 2.2.8
-
None
Description
I ran into the performance issue described in SLING-2881 (JcrResourceBundleProvider clears the cache on mix:language changes) and updated the SLing I18N bundle to version 2.2.8.
However, with the preloadBundles flag set to false (the default), the system stalled after being put under load.
According to my analysis there were lots of cuncurrent HTTP requests, all requesting the i18n ResourceBundle. Because the cache was not yet initialized, each of them started loading it from the repository. The system practically came to a hold, and did not recover after removing the load (I waited ~10min). I believe it might have eventually recovered, as I could not identify a deadlock in a series of thred-dumps.
I suggest three improvements:
- Change the default of preloadBundles to "true". This should avoid having HTTP requests waiting for the cache to be initialized.
- Ensure each ResourceBundle is only loaded into cache once (when the cache is empty), in order to limit I/O.
- Adjust the queries for languageRootPaths to only return nodes that have a @jcr:language property.
The attached patch implements points 2 and 3. It includes a test that verifies correct concurrent behaviour. The test can be run against the current implementation and should fail (it did reliably fail on my machine).
Additionally, I verified the fix on a local Sling instance using Apache Bench (ab) and finally on a production system. The production system loaded the ResourceBundles for four languages and recovered from that load after a few seconds.
Could you kindly review the patch and apply the changes. Thank you.