Branch: refs/heads/master Home: https://github.com/xwiki-contrib/xwiki-helm Commit: f1dec9fdfd9cb645742b620dda533fb2493de9b1 https://github.com/xwiki-contrib/xwiki-helm/commit/f1dec9fdfd9cb645742b620dd... Author: lobnaelsammak <[email protected]> Date: 2026-05-06 (Wed, 06 May 2026) Changed paths: M charts/xwiki/templates/initialization-configmaps.yaml Log Message: ----------- HELM-114 fix(kubeping): drop CENTRAL_LOCK and COUNTER for JGroups 5.x compatibility (#56) The hardcoded JGroups stack in kubeping.xml ends with two protocols that no longer exist in JGroups 5.x. Every recent XWiki LTS image ships JGroups 5.x (e.g. jgroups-5.5.1.Final.jar in xwiki:lts-postgres-tomcat), so cluster.enabled=true currently fails channel initialisation at boot: ERROR ... Failed to start channel [kubeping] Caused by: java.lang.Exception: JGRP000002: unable to load protocol CENTRAL_LOCK (either with relative - CENTRAL_LOCK - or absolute - org.jgroups.protocols.CENTRAL_LOCK - class name) Result: cluster.enabled=true is silently broken on every modern image — caches diverge between pods, CSRF tokens issued by one pod are rejected by another, etc. Neither CENTRAL_LOCK nor COUNTER is used by XWiki's RemoteObservationManager (they are optional distributed-lock and distributed-counter primitives). Removing them is sufficient for cache invalidation. If distributed locking were needed in the future, the JGroups 5.x replacement would be <org.jgroups.protocols.CENTRAL_LOCK2 />. Co-authored-by: Lobna EL SAMMAK <[email protected]> To unsubscribe from these emails, change your notification settings at https://github.com/xwiki-contrib/xwiki-helm/settings/notifications