Loading...

XML

Word

Printable

QE Test Coverage:
-
Target Release:

7.2.z.GA
Workaround Description:

Hide

We're seeing undertow slowly continuing a memory consumption until we run out of heap space and start getting outofmemory errors. On analysis of the heapdump, the main suspect appears to be:

One instance of "io.undertow.server.protocol.http.HttpOpenListener" loaded by "sun.misc.Launcher$AppClassLoader @ 0xc0041e40" occupies 967,912,832 (95.19%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class loader>".

This happened immediately when moving from 1.4.22.Final to 2.0.16.Final. I suspect its being triggered by a poorly designed health check.

Show
We're seeing undertow slowly continuing a memory consumption until we run out of heap space and start getting outofmemory errors. On analysis of the heapdump, the main suspect appears to be: One instance of "io.undertow.server.protocol.http.HttpOpenListener" loaded by "sun.misc.Launcher$AppClassLoader @ 0xc0041e40" occupies 967,912,832 (95.19%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class loader>". This happened immediately when moving from 1.4.22.Final to 2.0.16.Final. I suspect its being triggered by a poorly designed health check.
Git Pull Request:
https://github.com/undertow-io/undertow/commit/183f36625b33bc10d22197b65c75ebb46af0f332

clones

UNDERTOW-1486 Out of memory errors

is incorporated by

JBEAP-15869 (7.2.z) Upgrade Undertow from 2.0.15 to 2.0.19