[
https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17953697#comment-17953697
]
Daniel Stoch commented on WICKET-7002:
--------------------------------------
I think this change broke compatibility: when calling setMetaData(key, null)
now NPE is raised, in previous implementation passing a null object clears meta
data.
> 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-M1, 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)
