Possible memory leak ?

[frgirard]

Proposal

Hello, it seems I noticed a memory leak in wiremock-standalone release. I first saw this leak with version 3.4.5, I updated to 3.5.4 and it seems to be still here.

In about 3 to 4 days, wiremock becomes unresponsive and stop working. The JVM has to be restarted.

Reproduction steps

Nothing special.

References

No response

[leeturner]

Hi, many thanks for the issue. Could you please give us a little more information about how you are running WireMock standalone:

• What startup parameters are you using
• Are you constraining the request log in any way
• Are you using a health endpoint for WireMock in your environment and if so is that via a stub you have created or the official admin health endpoint?

If you could provide the above information it will hopefully help us figure out what is happening

[frgirard]

Startup parameters:

java -XX:+UseSerialGC -Xms512m -Xmx512m -XX:MetaspaceSize=64M -XX:MaxMetaspaceSize=64M -XX:CompressedClassSpaceSize=16M -XX:+DisableExplicitGC -cp wiremock-standalonejar:cube-wiremock-extension.jar wiremock.Run --extensions="some transformer classes" --port 8080 --no-request-journal --async-response-enabled --disable-request-logging --global-response-templating --permitted-system-keys="..."

Health endpoint not used at the moment (will be).

I'll try to get a heapdump, but it will take a few days.

[frgirard]

I cannot disclose the heap dump file for security reasons, but I can provide the following information:

[leeturner]

Many thanks for the information. Could I just ask, what stub features they’re using in your tests? I might be useful to know in case it’s a specific matcher or helper (or other feature) that’s leaking

[frgirard]

We use some custom transformers. But I couldn't see any related class in the heap dump.

[leeturner]

What about any matchers that you might be using ?

[frgirard]

We're still investigating, but to me it seems that a cache fills up the heap (I can see HTTP or JSON responses in it)

[frgirard]

Maybe not a leak. We'll try to add "--max-template-cache-entries" to the command line.

[leeturner]

Interesting. Many thanks for the investigation you are doing

[frgirard]

--max-template-cache-entries: Set the maximum number of compiled template fragments to cache. Only has any effect when response templating is enabled. Defaults to no limit.

The "defaults to no limit" strategy seems reckless :)

[leeturner]

Yeah, would be really interested to know if that solves your issue or just uncovers something else

[frgirard]

The leak is fixed…

[leeturner]

That is great to hear. I'll talk to the team about maybe defaulting --max-template-cache-entries to a sensible value. Are you happy to close this issue now?

[frgirard]

Yes please. Thank you.

[leeturner]

Closed after solution found with setting --max-template-cache-entries