[
https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17599572#comment-17599572
]
ASF subversion and git services commented on WICKET-7002:
---------------------------------------------------------
Commit 8c770c4337cc2649385aea49f02d29a357ac7acf in wicket's branch
refs/heads/WICKET-7002 from Martijn Dashorst
[ https://gitbox.apache.org/repos/asf?p=wicket.git;h=8c770c4337 ]
WICKET-7002 Remove blocking code from Application#get/setMetaData
By replacing the datastructure for Application class's metaData field
with a ConcurrentHashMap we can remove the synchronization on the
application instance and speed up lookups of the metadata. For at least
one application this will remove 50% of all blocking calls.
> 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
> 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(n) 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)
