This issue should be backported to Meridian 2016 as well. Reopening to address this.

Edit
PR for backport for foundation-2016: https://github.com/OpenNMS/opennms/pull/932

I took a database dump from demo.opennms.org and tried reproducing the slowlyness on my local system with the latest snapshot of OpenNMS Horizon 18.0.1.
In the past, I also tried this a couple of times, but were never able to reproduce the slowlyness mentioned above.

This time I took a Java Heap Dump from demo.opennms.org and analyzed it with the "Eclipse Memory Analyzer Tool" (or Eclipse MAT) and ran the "Leak Suspects":

• Problem 1: 3,152 instances of "org.opennms.features.vaadin.nodemaps.internal.MapWidgetComponent", loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x5cee2b970" occupy 2,064,099,736 (44.77%) bytes.

• Problem 2: 1,194 instances of "org.opennms.features.topology.app.internal.TopologyUI", loaded by "org.apache.felix.framework.BundleWiringImpl$BundleClassLoaderJava5 @ 0x5cee336e8" occupy 1,435,601,152 (31.14%) bytes.

Investigating the problems revealed, that:

• The WidgetManager holds references to all TopologyUI's ever created, even if a user's session is no longer valid and

• The MapWidgetComponent schedules a Runnable with a fixed rate, which is still running, even if a user's session is no longer valid

To address this issue both UIs need to cleanup properly when the session is destroyed.

Vaadin provides a "SessionDestroyedListener" for this scenario, which is added to both UIs, to clean up properly.

The Pull Request can be found here: https://github.com/OpenNMS/opennms/pull/896 and should solve the mentioned slowlynes. However, we should keep an eye on it when 18.0.1 is released.

Moved to project "OpenNMS" as it is a bug.