• Icon: Bug Report Bug Report
    • Resolution: Won't Fix
    • Icon: L3 - Default L3 - Default
    • 7.2.x, 7.3.x, 7.4.x, 7.5.x
    • None
    • engine
    • None

      The class org.camunda.bpm.engine.impl.persistence.deploy.DeploymentCache caches deployed resources (BPMN, CMMN, DMN models) and can be accessed by multiple threads in parallel. Internally it uses HashMaps. HashMaps are not thread-safe (e.g. chance for infinite loops when putting in parallel, see http://javaeesupportpatterns.blogspot.de/2012/08/java-7-hashmap-vs-concurrenthashmap.html).

      Probability of problem occurrence: very low (apparently no user ever had one so far, at least we did not notice)
      Worst-case damage: rather high (users might violate SLAs they give to the users of their process applications)

        This is the controller panel for Smart Panels app

            [CAM-4867] Deployment Cache is not thread-safe

            We should fix this with as limited impact on performance as possible.

            Daniel Meyer added a comment - We should fix this with as limited impact on performance as possible.

            According to the linked article, the difference between HashMap and ConcurrentHashMap isn't too big and that would at least solve the infinite loop possibility.

            Perhaps we should also think about testing parallel access to the DeploymentCache which would make us aware of concurrency issues in our own code.

            Thorben Lindhauer added a comment - According to the linked article, the difference between HashMap and ConcurrentHashMap isn't too big and that would at least solve the infinite loop possibility. Perhaps we should also think about testing parallel access to the DeploymentCache which would make us aware of concurrency issues in our own code.

            This is fixed from 7.6 onward

            Daniel Meyer added a comment - This is fixed from 7.6 onward

            We are closing this ticket as part of our backlog grooming. Reasons:

            • This problem does likely not exist anymore

            Thorben Lindhauer added a comment - We are closing this ticket as part of our backlog grooming. Reasons: This problem does likely not exist anymore

              Unassigned Unassigned
              thorben.lindhauer Thorben Lindhauer
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: