Notification Thread low memory warnings on XWiki 18.9.0 RC1

Summary: this is a real regression, but a cosmetic one. It comes from the Infinispan upgrade from 15.2.6.Final to 16.2.3 (XCOMMONS-3497). Infinispan 16.2 adds a JVM memory monitor that is enabled by default and logs this warning whenever the old generation is more than 85% full, including garbage that hasn't been collected yet. XWiki's caches are not affected: the dynamic resizing that reacts to the warning has nothing to manage with XWiki's configuration. The warning can still show up on a healthy production instance, so I suggest disabling the monitor by default in the XWiki Infinispan cache factory (xwiki-commons). The component should be Cache, not Notifications: "Notification Thread" is the JVM's JMX notification thread.

Details

Origin

• ISPN000977 is CONFIG.lowMemoryDetected(), logged by org.infinispan.commons.util.MemoryMonitor. That class is new in Infinispan 16.2 and doesn't exist in 15.2.6.
• GlobalComponentRegistry creates a MemoryMonitor for every cache manager, because GlobalMemoryMonitorConfiguration.ENABLED defaults to true. It sets a usage threshold on the old-gen memory pool at 85% of the pool's max.
• XWiki configures nothing about it: InfinispanCacheFactory only parses WEB-INF/cache/infinispan/config.xml and turns metrics off, so the defaults apply.

Impact on the caches: none

• The monitor also starts a DynamicMemoryResizer. On a low-memory or GC-pressure alert it shrinks memory containers by 20% of their original capacity per step, down to a floor of 10%, then grows them back once memory recovers.
• It only manages shared container-level memory containers (<memory-container>) that have dynamic-resize enabled, which defaults to false. If none qualifies, it doesn't even register as a listener.
• The config.xml XWiki ships only uses a per-cache <memory max-count="10000"/>, with no memory container. So XWiki's caches (documents, rights, …) are never shrunk, and the only effect is the log.

Can it happen in production with proper memory settings? Yes

• The monitor uses a usage threshold, not a collection usage threshold (which would only look at what is left after a GC). So the warning fires whenever the old gen currently holds more than 85%, dead objects included.
• It isn't logged only once: after each GC that brings usage back under 85% the alert is cleared, and the next time usage goes over the threshold it is logged again.
• With Parallel or Serial GC, the old gen is only collected when it's nearly full, so the warning will show up regularly whatever the heap size.
• With G1 (the default), concurrent marking usually starts well below 85%, so it happens less often. It still happens during allocation bursts (imports, exports, Solr indexing, large attachments, since humongous objects go straight to the old gen) and on instances where the caches legitimately take a large share of the heap. This part is an estimate: I haven't checked in the JDK source when HotSpot evaluates the usage threshold for each collector.
• With ZGC or Shenandoah, the monitor may disable itself and log a different warning (memoryThresholdMonitoringUnavailable).
• The same monitor can also log ISPN000978 (GC pause over 5s) and ISPN000979 (more than 20% of the time spent in GC over 60s).

The monitor is designed for Infinispan Server, where Infinispan owns the heap. Embedded in XWiki, Infinispan is not the main memory consumer and does nothing with the alert. An admin seeing ISPN000977 would think the cache layer has a memory problem when nothing is wrong.

Suggested fix: call memoryMonitor().enabled(false) on the global configuration builder in InfinispanCacheFactory, next to the existing metrics() call. Admins who want the monitor can still enable it in config.xml.