[ https://issues.apache.org/jira/browse/WICKET-7002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17601334#comment-17601334 ]
Emond Papegaaij commented on WICKET-7002: ----------------------------------------- It is likely that the call stack is either collapsed or inlined by the hotspot compiler. In our application, the call comes from {{{}CdiConfiguration.get(application){}}}, which is done from the component injector for CDI when using the FALLBACK lookup strategy. > 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)