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
