Hi Martin,
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.
Not really sure I understood your question correctly... the final
markup (debug mode enabled, hence the wicket tags are still visible)
received by the browser looks like this:
while the XHTML template looks like this:
Not sure this is relevant here but for historic reasons (many years ago
our application got migrated gradually from Struts2 to Wicket) we're
registering a custom IResourceFinder in WebApplication#init() that
handles "css/*" , "script/*" and "img/*" paths.
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
--
Tobias Gierke
Software Developer
Voipfuture GmbH Wendenstr. 4 20097 Hamburg Germany
Phone +49 40 688 9001 64 Fax +49 40 688 9001 99
Managing Directors Jan Bastian Eyal Ullert
Commercial Court AG Hamburg HRB 109896 VAT ID DE263738086
