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.