-
Bug
-
Resolution: Done
-
Blocker
-
None
-
None
-
https://gitlab.cee.redhat.com/undertow-io/undertow/-/merge_requests/81, https://gitlab.cee.redhat.com/undertow-io/undertow/-/commit/042a98f8915334f90c1505879c36594f31685469, https://gitlab.cee.redhat.com/undertow-io/undertow/-/commit/a69e612cb713e43cea70efac3314f404aab2316a, https://gitlab.cee.redhat.com/undertow-io/undertow/-/commit/db193d45ce513f5993ecd261dd027e245df2880c, https://github.com/undertow-io/undertow/pull/1557, https://github.com/undertow-io/undertow/pull/1559, https://gitlab.cee.redhat.com/undertow-io/undertow/-/merge_requests/116
When the remoting server receives the EOF and closes the connection (see here) during an http upgrade operation, the WriteTimeoutStreamSinkConduit channel will be unaware the connection was closed and its timeout expiration handle will be kept active for a while and associated with the WorkerThread. As a result, the whole tree of channels for that connection will not be garbage collected until that task is executed, causing a temporary memory leak.
This bug was uncovered as part of the investigation for WFLY-18700 and it is related to the stack trace shown in XNIO-427.
- causes
-
WFLY-18700 java.lang.OutOfMemoryError: Direct buffer memory
- Closed
- is incorporated by
-
WFCORE-6709 CVE-2023-5379 CVE-2024-1459 CVE-2024-1635 Upgrade Undertow to 2.3.12.Final
- Resolved
- is related to
-
JBEAP-26171 (8.0.z) OOM Error after node restart, in a 4 nodes cluster
- Closed
-
JBEAP-26462 (7.4.z) OOM Error after node restart, in a 4 nodes cluster
- Closed
-
XNIO-427 ClosedChannelException when NioSocketConduit.handleReady invokes write listener after read listener closes connection
- Closed
-
WFCORE-6707 CVE-2024-1635 Upgrade XNIO to 3.8.13.Final
- Resolved
-
WFCORE-6708 CVE-2024-1635 Upgrade JBoss Remoting to 5.0.28.Final
- Resolved