What is the url for any of the problematic resources in the generated HTML ? The resources' urls are not related to page *instances*, so I don't expect to see anything like pageId, renderCount and behaviorId in them.
On Wed, Jan 11, 2023 at 2:17 PM Tobias Gierke <tobias.gie...@voipfuture.com.invalid> wrote: > Hi guys, > > I'm currently investigating a memory leak inside our application (running > Wicket 8.14.0). Sorry for the large amount of images in this (HTML) mail > but the issue is rather complicated and as the saying goes, "A picture is > worth a thousand words". > > Inspecting the CachingResourceStreamLocator's internal ConcurrentHashMap > reveals that around 500.000 of the cache entries are all related to a set > of only 5 *static* resources: > > Further digging into the cache map's content reveals that the reason for > this duplication is that the > org.apache.wicket.core.util.resource.locator.caching.CachingResourceStreamLocator$CacheKey > instances used as keys in the map for these 5 static resources only deviate > by their "style" attribute: > > Note that this output was generated by parsing the heap dump using some > custom tooling I wrote (as Eclipse MAT is not powerful enough to do this > via OQL/Calcite) where I parsed all the CacheKey field values and then > concatenated them as a string like so: > > to generate CSV output in "map key;map value" format. Also note the > somewhat mangled looking style values with the trailing '.' (I > double-checked my program output against Eclipse MAT and both agree that > the strings are indeed ending with a trailing dot). > > Since we're never calling WebSession#setStyle(), this looks weird to me. > One of the URLs being parsed is an AJAX callback URL generated by an > onclick AjaxEventBehaviour attached to a button: > > I stepped through the Wicket code and this URL gets parsed by > org.apache.wicket.resource.ResourceUtil > > I checked how the AJAX callback URL is generated and noticed that what is > mistaken as "style" by ResourceUtil is "<render count>.<behaviour id>": > > > The weird thing about all of this is that the issue seems to only affect 5 > static application-level resources (though we obviously use a lot more > static application-level resources everywhere) and 4 out of those 5 > resources are used by a single WebPage of our application only (the login > page). > > Since our application is rather old (>10 years) and - for various reasons > - quite deeply integrated with Wicket internals, I wouldn't rule out that > we're doing something wrong (I checked our custom CSRFMapper since it shows > up in the stack trace but couldn't see any obvious relationship to the > observed behaviour). > > Any ideas ? > > Cheers, > Tobias >
