Uploaded image for project: 'Undertow'
  1. Undertow
  2. UNDERTOW-413

Out of Memory due to multiple ReadTimeoutStreamSourceConduit instances

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Done
    • 1.1.0.Final
    • 1.1.4.Final, 1.2.0.CR1
    • None
    • None
    • Hide

      I do not have a proper recreate for this. Set the timeout large and leave the server to run with some users for a while, then look at the heap for large instances of TreeSet. Our servers see a mix of both serving up interactive web pages and web services. I'm pretty sure the interactive pages are actively contributing to the problem, I don't know about the web-service calls.

      Show
      I do not have a proper recreate for this. Set the timeout large and leave the server to run with some users for a while, then look at the heap for large instances of TreeSet. Our servers see a mix of both serving up interactive web pages and web services. I'm pretty sure the interactive pages are actively contributing to the problem, I don't know about the web-service calls.

    Description

      When the HTTP read-timeout is set to a large value (1 hour+), Wildfly is running out of memory. Chasing this back, org.xnio.nio.WorkerThread is producing a large TreeSet for each i/o worker, as the delayWorkQueue. The tasks it contains are primarily instances of io.undertow.conduits.ReadTimeoutStreamSourceConduit$1
      These occur in large quantity (looking at 1500+ right now on our Dev server), do not appear to correlate to any active requests (1700+ instances observed on servers that have < 20 open sockets), and in our environment they consume an average of just under 1MB each - they each appear to hold a link to an org.ajax4jsf.io.CharBuffer where the bulk of memory is being held for each timeout request.

      I've not observed any other ill effects: sockets and open file handles do not appear to be leaking.

      Setting the HTTP read-timeout to a smaller value reduces the severity as memory the Read Timeouts hold is freed up with a shorter delay.

      Attachments

        Activity

          People

            sdouglas1@redhat.com Stuart Douglas
            epeters_jira Eric Peters (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: