Réplication du service DynaCache pour HCL Digital Experience
Cette section décrit comment répliquer le service Dynacache dans HCL Digital Experience en personnalisant les propriétés de délai d'attente dans le fournisseur d'environnement de ressources WAS (REP).
Pourquoi et quand exécuter cette tâche
Les versions antérieures, jusqu'à HCL Digital Experience Portal 8.5 et 9.0, utilisent Dynamic Cache (DynaCache), un service de cache compatible avec les clusters qui permet à tous les membres du cluster d'HCL Portal de connaître les modifications de paire nom/valeur effectuées par n'importe quel membre.
Disposer d'un cache compatible avec les clusters n'a pas de sens pour HCL Digital Experience 9.5, car les versions se trouvent sur une configuration basée sur une conteneurisation ou un parc de portails. Pour contourner ce problème, un administrateur peut personnaliser les propriétés de délai d'attente dans l'environnement de ressources WAS pour répliquer le service DynaCache.
Optimisation des serveurs pour répliquer le service DynaCache dans votre environnement de conteneur
Procédure
db.cache.invalidation.read.freq= (délai d'attente en millisecondes) :- Délai entre les "lectures" de la table de base de données contenant les messages d'invalidation. Par défaut, le délai d'attente est de 1 minute (60 000 millisecondes). D'un point de vue pratique, cela signifie qu'il s'agit du délai d'attente le plus long avant qu'une invalidation dynacache ne soit "connue" sur chaque membre (par exemple Kubernetes, POD, agent de parc).
db.cache.invalidation.cleanup.freq= (délai en millisecondes) :- Délai qui, une fois atteint, entraîne la suppression de la table de base de données contenant des messages d'invalidation. Par défaut, le délai d'attente est de 10 minutes (600 000 millisecondes). Généralement, ce nombre doit être beaucoup plus grand que la fréquence "rouge" pour veiller à ce que les messages d'invalidation soient lus avant d'être supprimés.