Nicolas Filotto created GTNPORTAL-3569: ------------------------------------------ Summary: Reduce the performance impact of the cache of the TemplateService in a cluster Key: GTNPORTAL-3569 URL: https://issues.jboss.org/browse/GTNPORTAL-3569 Project: GateIn Portal Issue Type: Enhancement Components: Performance Affects Versions: 3.8.8.Final Reporter: Nicolas Filotto While trying to identify the root cause of the performances regression between JPP 6.1.1 and JPP 6.2, I realized that the bug fix for https://issues.jboss.org/browse/GTNPORTAL-3410 is actually buggy and causes a significant performance regression. It is buggy because as the variable script of the class GroovyTemplate is transient, its value is not replicated over the cluster so far so good, the problem is that there is no synchronization mechanism to ensure that the value of this variable will be created only once even if we have several concurrent threads that try to access to its value, this is a real issue especially when we know that building the value of this particular variable has a significant cost. It causes a significant performance regression because it replaces an eXo Cache based on a ConcurrentHashMap with an eXo Cache based on ISPN in replicated mode, according to my micro benchmarks, the get method of a ConcurrentHashMap is 11 times faster than the get method of ISPN so when we know that the cache of the TemplateService is very frequently used we know that this configuration change will have a significant impact on performances -- This message was sent by Atlassian JIRA (v6.3.8#6338)