[jira] [Resolved] (YUNIKORN-3364) Event stream history replay blocks forever if the client disconnects before the stream opens with a non-zero history request

["TingYao Huang (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/YUNIKORN-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

TingYao Huang resolved YUNIKORN-3364.
-------------------------------------
     Fix Version/s: 1.10.0
    Target Version: 1.10.0
        Resolution: Fixed

> Event stream history replay blocks forever if the client disconnects before the stream opens with a non-zero history request
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: YUNIKORN-3364
>                 URL: https://issues.apache.org/jira/browse/YUNIKORN-3364
>             Project: Apache YuniKorn
>          Issue Type: Bug
>          Components: core - scheduler
>            Reporter: Dale Richardson
>            Assignee: weichen lai
>            Priority: Minor
>              Labels: newbie, pull-request-available
>             Fix For: 1.10.0
>
>
> {{EventStreaming.CreateEventStream}} replays the event history to a new consumer with a bare blocking send ({{{}consumer <- event{}}}) *outside* the forwarder's select ({{{}event_streaming.go{}}}, the history-replay loop at stream open). If the requesting client closes the connection before the stream is really started, and it requested a non-zero history (not the default), that push blocks with no stop channel reachable: the forwarder goroutine, its consumer buffer and its {{seen}} map are pinned for the life of the process. Confirmed by the maintainer on PR #1124.
> Proposed fix: make the history-replay send selectable so {{{}stop{}}}/{{{}e.stopCh{}}} can reach it:
> {code:java}
> select {
> case consumer <- event:
> case <-stop:
>     close(consumer)
>     return
> case <-e.stopCh:
>     close(consumer)
>     return
> }
> {code}
> Then delete the {{events.(*EventStreaming).CreateEventStream}} exemption in {{{}pkg/common/leakcheck/leakcheck.go{}}}.
> Note: a second, test-only cause shares the same top frame (a test that creates a stream and never calls {{{}RemoveStream{}}}); it is tracked separately as the stream test-hygiene follow-up.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org