Details

    • Target Release:
    • 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.

      Gliffy Diagrams

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                spyrkob Bartosz Spyrko-Smietanko
                Reporter:
                spyrkob Bartosz Spyrko-Smietanko
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: