[
https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601300#comment-17601300
]
Martin Tzvetanov Grigorov commented on WICKET-7002:
---------------------------------------------------
The attached screenshot says that WebMarkupContainer:45 is one of the callers.
[https://github.com/apache/wicket/blob/wicket-9.x/wicket-core/src/main/java/org/apache/wicket/markup/html/WebMarkupContainer.java#L45]
does *not* call Application.getMetadata().
How should one read this "reverse call stack" ?
> Application metadata access should not require synchronization
> --------------------------------------------------------------
>
> Key: WICKET-7002
> URL: https://issues.apache.org/jira/browse/WICKET-7002
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-core
> Affects Versions: 8.14.0, 9.11.0
> Reporter: Martijn Dashorst
> Priority: Minor
> Fix For: 10.0.0, 9.12.0, 8.15.0
>
> Attachments: Screenshot 2022-09-02 at 17.18.44.png
>
>
> The methods getMetaData and setMetaData from Application have synchronized
> modifiers applied to them such that they block on the application instance.
> This can cause blocking issues. When I looked at the monitor usage in our
> application running in production the Application metadata locks are
> responsible for 57% of all monitor usage.
> I've included a screenshot of the monitor usage reverse call stacks.
> The implementation should be changed to a ConcurrentHashMap so we can remove
> the synchronization from the getter and setter, and just use the hashmap's
> O(1) lookup rather than MetaDataKey's O( 1) lookup. This will eliminate the
> blocking and (possibly) long lookups of metadata in the Application instance.
> Note this does not involve modifying the component, session or requestcycle
> metadata implementations (yet).
> IMO this should be backported to at least 9, as this is a semver compatible
> change.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
