[ https://issues.redhat.com/browse/WFLY-13514?page=com.atlassian.jira.plugi... ] Matěj Novotný commented on WFLY-13514: -------------------------------------- [~konbk] funy thing is, I cannot reproduce this manually. If I just try and GET that page from browser (repeatedly OFC), it never goes OOM. And if you monitor the memory usage, it goes up the same way on each request, but once you perform GC, it goes back down. Once our http listener gets notified about request ending, we proceed to bean destruction (calling pre-destroy callbacks), clearing caches and detaching bean storage so no further context manipulation gets propagated to request. But we don't really seem to remove beans from request at this point (we don't invoke {{HttpServletRequest.removeAttribute(key)}}) - we never did though. I guess we assume the request is deleted by Undertow once it is over which seems reasonable; but it is not what's happening with your reproducer. At least from the heap dump I was seeing that it is still kept as attribute under {{attributes io.undertow.servlet.spec.HttpServletRequestImpl @ 0xf878ef48}} which in turn was in session that was considered active. Maybe someone from Undertow team ([~flavia.rainone]?) would know more about how are requests handled in this case and whether {{HttpServletRequestImpl}} should under some circumstances survive a request ending? -- This message was sent by Atlassian Jira (v7.13.8#713008)