[MAGNOLIA-6580] Replacement for ObservationUtil Created: 04/Mar/16  Updated: 29/Aug/17  Resolved: 07/Apr/16

Status: Closed
Project: Magnolia
Component/s: core
Affects Version/s: 5.3.9
Fix Version/s: 5.4.6

Type: Bug Priority: Critical
Reporter: Dominik Kunz Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: support
Remaining Estimate: 0d
Time Spent: 2.5h
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MGNLSITE-58 Site module duplicates workspace list... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Sprint: Kromeriz 38
Story Points: 5

 Description   

We rely heavily on observed configurations injected through Guice in our application. We experienced a growing heap usage during our load tests and the heap dump shows that ~1.5 GB are occupied by the class org.apache.jackrabbit.core.observation.ObservationDispatcher.

Further investigations show that the activeConsumers HashSet of the ObservationDispatcher has grown to ~320000 entries, these EventConsumers all have the info.magnolia.cms.util.ObservationUtil$DeferringEventListener associated as event listener, which is used to compute the hashCode of the EventConsumer along with the hashCode of the associated Session.

So now as the info.magnolia.cms.util.ObservationUtil$DeferringEventListener does not implement hashCode() nor equals(), an added EventConsumer does never get removed, thus each request adds the EventConsumers again and again and heap usage grows.

This is how EventConsumers are added in Jackrabbit(irrelevant parts removed), where it can be seen clearly that removal is based on hashCode() implementation.

    /**
     * Adds or replaces an event consumer.
     * @param consumer the <code>EventConsumer</code> to add or replace.
     */
    void addConsumer(EventConsumer consumer) {
        synchronized (consumerChange) {
            if (consumer.getEventListener() instanceof SynchronousEventListener) {
               /****   8< ------   SNIP ----- */
            } else {
                // remove existing if any
                activeConsumers.remove(consumer);
                // re-add it
                activeConsumers.add(consumer);
                // reset read only consumer set
                readOnlyConsumers = null;
            }
        }
    }

I currently cannot test if Magnolia 5.4 is also affected but from a quick code review it should be the same problem, as well as Magnolia 5.2.

Let me know if you need more information



 Comments   
Comment by Evzen Fochr [ 09/Mar/16 ]

just moving back to in progress

Generated at Mon Feb 12 04:15:51 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.