-
Type: Bug
-
Status: Resolved
-
Priority: Major
-
Resolution: Fixed
-
Affects Version/s: 10.10
-
Fix Version/s: 10.10-HF59, 2021.17
-
Component/s: Template Rendering
-
Release Notes Summary:Type mapping in Template Rendering addon is shared accross all cluster nodes.
-
Tags:
-
Backlog priority:750
-
Sprint:nxplatform #56
-
Story Points:3
Currently the type mapping which stores the template ids for each document type is stored in TemplateProcessorComponent#type2Template and therefore it is stored in the local JVM
This variable is initialized by 2 main methods:
- when a new template is created (or updated): it calls the asynchronous listener TemplateTypeBindingListener which updates the mapping in the "registerTypeMapping"
- when a new document is created: it calls the synchronous listener TemplateInitListener which will compute the mapping if it is currently null in the method TemplateProcessorComponent#getTypeMapping (note that the same method is also used in the first case to initialize the mapping before updating it)
Here we see at least 2 obvious problems:
- as the mapping is stored in the local JVM, when a new document is created, the mapping will be updated only on this node in the cluster
- as the mapping is updated asynchronously, it will be run on a worker node only, and all the portal nodes will miss the updates
A solution would be to save the type mapping in a common storage (distributed cache, KV store, etc)