Details
-
Suggestion
-
Resolution: Fixed
-
None
-
This race condition is more likely to be provoked by systems which are normally under a high load and were bounced due to an unexpected error, thus when they resume accepting HTTP requests they will receive several of them straight away thus being more prone to initialising the i18n resources in parallel.This race condition is more likely to be provoked by systems which are normally under a high load and were bounced due to an unexpected error, thus when they resume accepting HTTP requests they will receive several of them straight away thus being more prone to initialising the i18n resources in parallel.
-
2
-
Description
NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.
(Unnecessary) parallel initialisation of I18NBeans causes heavy contention leading to significant delays in the HTTP responses.
The symptom is that most HTTP workers will be waiting for a lock on a java.util.jar.JarFile instance.
"http-127.0.0.1-8091-46" daemon prio=3 tid=0x0000000008b15000 nid=0x6bb waiting for monitor entry [0xfffffd7bc7e83000] java.lang.Thread.State: BLOCKED (on object monitor) at java.util.zip.ZipFile.getEntry(ZipFile.java:302) - waiting to lock <0xfffffd7bfd0efdf8> (a java.util.jar.JarFile) at java.util.jar.JarFile.getEntry(JarFile.java:226) at java.util.jar.JarFile.getJarEntry(JarFile.java:209) ... at java.lang.ClassLoader.getResourceAsStream(ClassLoader.java:1341) at com.atlassian.plugin.impl.DefaultDynamicPlugin.getResourceAsStream(DefaultDynamicPlugin.java:53) at com.atlassian.plugin.impl.AbstractDelegatingPlugin.getResourceAsStream(AbstractDelegatingPlugin.java:190) at com.atlassian.confluence.util.i18n.PluginI18NResource.getPropertyResourceAsStream(PluginI18NResource.java:24) at com.atlassian.confluence.util.i18n.AbstractI18NResource.getBundle(AbstractI18NResource.java:26) at com.atlassian.confluence.util.i18n.AbstractI18NResource.getBundle(AbstractI18NResource.java:18) at com.atlassian.confluence.util.i18n.I18NResourceBundlesLoader.getResourceBundles(I18NResourceBundlesLoader.java:55) at com.atlassian.confluence.util.i18n.DefaultI18NBean.loadPluginI18NResources(DefaultI18NBean.java:149) at com.atlassian.confluence.util.i18n.DefaultI18NBean.<init>(DefaultI18NBean.java:76) at com.atlassian.confluence.util.i18n.DefaultI18NBeanFactory.getI18NBean(DefaultI18NBeanFactory.java:70) at com.atlassian.confluence.util.i18n.CachingI18NBeanFactory.getI18NBean(CachingI18NBeanFactory.java:31)
Given that it is CachingI18NBeanFactory's responsibility to cache a calculated I18NBean for a specific locale, the contention on individual JAR files is counter-productive, as in it hinders one specific thread of finishing the collection of all the i18n resources from the plugins. The suggested improvement is to only let one thread per locale produce the I18NBean and let the others wait until this is available. Thus you'd still have contention on the java.util.jar.JarFile instance level, e.g. one thread requesting the i18n resources from a plugin for English and another one requesting the i18n resources for the same plugin for German, but on a much smaller scale.
Attachments
Issue Links
- relates to
-
- Closed
- is related to
-
CSP-104254 Loading...
-
- mentioned in
-
-
-
-
-
-
-