[
https://issues.apache.org/jira/browse/FLINK-12887?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883161#comment-16883161
]
Till Rohrmann commented on FLINK-12887:
---------------------------------------
Where are we using unfenced asynchronous operations in the Yarn RM which are
problematic? I guess I'm lacking a bit the bigger picture here [~xiaogang.shi].
Is this an actual problem in Flink or something you need to make it work with
your changes?
I think that the scenario you've described [~xiaogang.shi] cannot happen. If
you process a fenced {{RunAsync}} message, then you must have the same leader
session id as it was enveloped with. Hence, you will envelope it with the same
leader session as it had before again. Please correct me if I misunderstood the
scenario.
The problem why we don't directly schedule a scheduled {{RunAsync}} message is
that the {{AkkaInvocationHandler}} does not know anything about the underlying
{{AkkaRpcActor}}.
> Schedule UnfencedMessage would lost envelope info
> --------------------------------------------------
>
> Key: FLINK-12887
> URL: https://issues.apache.org/jira/browse/FLINK-12887
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Coordination
> Affects Versions: 1.9.0
> Reporter: TisonKun
> Priority: Major
>
> We provide {{runAsync}}, {{callAsync}} and {{scheduleRunAsync}} for
> {{MainThreadExecutable}}, while providing {{runAsyncWithoutFencing}} and
> {{callAsyncWithoutFencing}} additionally for {{FencedMainThreadExecutable}}.
> Let's think about a case when we want to schedule a unfenced runnable or any
> other unfenced message(currently, we don't have such code path but it's
> semantically valid.).
> 1. {{FencedAkkaRpcActor}} received an unfenced runnable with delay
> 2. It extracted the runnable from unfenced message and call
> {{super.handleRpcMessage}}.
> 3. {{AkkaRpcActor}} enveloped the message and schedule it by
> {{AkkaRpcActor#L410}}.
> However, {{FencedAkkaRpcActor#envelopeSelfMessage}} was called for envelope.
> Thus the unfenced message now become a fenced message.
> We can anyway implement {{scheduleRunAsyncWithoutFencing}} to schedule
> unfenced message directly by {{actorsystem.scheduler.scheduleOnce(...,
> dispatcher)}}, but with current codebase I notice that {{RunAsync}} has a
> wried {{atTimeNanos}}(i.e., delay) property. Ideally how to schedule a
> message is shown on what params ScheduleExecutorService called with, at least
> we cannot extract an unfenced message and envelop it into a fence message and
> then schedule it, which goes into wrong semantic.
> cc [~till.rohrmann]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
