Identify the CN objects retaining the Maven forwarding heap
Find the retaining owner and add a public API reproducer; CN collection pauses explain the Maven wait, but the old process ended before its final histogram.
Find the retaining owner and add a public API reproducer; CN collection pauses explain the Maven wait, but the old process ended before its final histogram.
RE-VERIFY: 2026-10-23 UTC. Live process identity, route counters and public timings were rechecked in this lane. The earlier CN process ended during collection, so its final retaining owner cannot be recovered from the available summaries.
Remaining work: identify the CN object owner that retained nearly the whole heap before 09:54 UTC, then reproduce the ownership condition through the public API before changing source.
Observed: Maven app PID 3511491 on port 38737 answered direct host requests in 3–4 ms. Old CN PID 666261 accepted host-loopback TCP but did not complete TLS within 40 seconds. The old CN 45-second recording contains 39.537945 seconds of collection pauses (87.86%); post-collection heap remains roughly 789–802 MB with a configured 768 MiB heap. The application recording is nearly idle.
The unit received an external stop at 09:54:00; old CN exited with status 143 and replacement PID 2833373 started at 09:54:26. This lane performed no lifecycle operation. The unchanged Maven app then served public requests in 137–153 ms. Replacement live histograms total 63.81, 68.25 and 71.27 MB, so the old state has not recurred here.
Request evidence: a matched 335.41-second window has 77,669 route admissions and 77,698 access completions; median duration 5 ms, p95 64 ms. This machine (71.198.229.18) is a major client, together with 104.248.75.129 and several other addresses. Multiple clients and coordinates contribute. Roughly half this machine's requests in a separate five-minute window return 304. One active local test has an isolated temporary cache, but it is not demonstrated as the cause of the CN memory state.
Source: deployed CN revision https://github.com/CodexCoder21Organization/ContainerNursery/commit/d84bf644622f542e94c788ced3f40fe2853b846a; HttpsFacadeProvider.kt:2694 creates the TLS socket, :2711 begins its handshake. The profile also samples URL JSON parsing; these allocation locations do not identify the retaining owner. A pre-existing 06:51 class histogram has 232.73 MB of byte arrays, but its command flags are unknown and it is not a final-state owner map.
Durable work: https://github.com/CodexCoder21Organization/ContainerNursery/tree/wip/laneKDIR-evidence . The evidence directory includes findings, counter/client/path summaries, five thread summaries per process, heap comparisons, selected JFR events and hashes. All work is evidence only. No source change, reliable reproducer, reversal, complete suite, PR, merge, publication or deployment was performed by this lane. No code was deployed or published from this branch.
Next experiment: obtain any independently captured final-state histogram for PID 666261; otherwise observe the same retained-state condition in the current CN process and collect the permitted class histogram before any lifecycle action. Use the class growth to choose a public API ownership test. Current JFR samples have no object reference paths. Do not raise timeouts or change limits to quiet the symptom.
Recorded agent work, including concurrent agents
No model usage has been recorded for this handoff yet.
Record work with handoff-cli usage report hf-2026-10-23-identify-the-cn-objects-retaining-the-maven-forwarding-heap.
No status reports yet.
Moves it out of every priority list and into ArchiveArea.