Uploaded image for project: 'Jira Data Center'
  1. Jira Data Center
  2. JRASERVER-13516

FieldLayoutSchemeImpl caching is not thread-safe


    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: High High
    • 3.12
    • None
    • None

      FieldLayoutSchemeImpl.java has a number of thread-safety issues. Firstly it uses a HashMap as its cache and does not synchronise access or mutable operations. Fortunately it doesn't get mutated very often so we don't see problems with this very often.

      Worse is that it suffers from a race-condition at startup, where it is lazily initialised. This initialisation depends on the nullness of the schemeEntities reference, but other threads can see a partially initialised schemeEntities cache, which if it doesn't have the default entry in it yet leads to the following:

      [webwork.util.ServletValueStack] METHOD: "fieldHidden", exception:
              at com.atlassian.jira.issue.fields.layout.field.FieldLayoutSchemeImpl.getFieldLayoutId(FieldLayoutSchemeImpl.java:107)
              at com.atlassian.jira.issue.fields.layout.field.enterprise.EnterpriseFieldLayoutManager.getFieldLayout(EnterpriseFieldLayoutManager.java:73)
              at com.atlassian.jira.web.bean.FieldVisibilityBean.isFieldHidden(FieldVisibilityBean.java:163)
              at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

      Also, the access to the schemeEntities reference itself is not safe, so it is possible multiple threads could be initialising multiple schemeEntities maps.

      Please note that null has a special value in this map, so ConcurrentHashMap is not a drop-in replacement, and doesn't fix the visibility and unsafe publication problems.

            Unassigned Unassigned
            jed Jed Wesley-Smith (Inactive)
            0 Vote for this issue
            2 Start watching this issue