It's of course a delicate topic and it needs a full investigation, but looking at the code of both setMetaData and getMetaData I think we could reduce the synchronization overloading by making Application#metadata volatile and removing synchronized from getMetaData. In addition I think setMetaData should always return a new copy of Application#metadata to ensure a proper synchronization among threads, but I'm not 100% sure about this.
Just some 2 cents... On Fri, Sep 2, 2022 at 8:46 AM Martijn Dashorst <martijn.dasho...@gmail.com> wrote: > Heya! > > In a performance dump for a production issue I was looking through the > monitors that were in use during request processing and I noticed that a > lot of request threads were blocking on Application.getMetaData. > > This method is synchronized because it uses an array of metadata and goes > through that array in search of the key. > > I'm no rocket scientist, but shouldn't that metadata field just be a > ConcurrentHashMap so we can remove the blocking synchronization on the > application object? > > Martijn > > <http://wicketinaction.com> > -- Andrea Del Bene. Apache Wicket committer.
