[jira] [Commented] (IMPALA-5119) Don't call CancelInternal() from Coordinator::UpdateFragmentExecStatus()

["Dan Hecht (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IMPALA-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16518544#comment-16518544 ] 

Dan Hecht commented on IMPALA-5119:
-----------------------------------

The {{lock_}} problem was solved with IMPALA-5384. For the remaining work, let's wait until after the coordinator RPCs have been converted to KRPC since that changes how / if we need to solve this further.

> Don't call CancelInternal() from Coordinator::UpdateFragmentExecStatus()
> ------------------------------------------------------------------------
>
>                 Key: IMPALA-5119
>                 URL: https://issues.apache.org/jira/browse/IMPALA-5119
>             Project: IMPALA
>          Issue Type: Sub-task
>          Components: Distributed Exec
>    Affects Versions: Impala 2.9.0
>            Reporter: Henry Robinson
>            Assignee: Dan Hecht
>            Priority: Major
>
> If it reports a bad status, {{UpdateFragmentExecStatus()}} will call {{UpdateStatus()}}, which takes {{Coordinator::lock_}} and then calls {{Cancel()}}. That method issues one RPC per fragment instance.
> In KRPC, doing so much work from {{UpdateFragmentExecStatus()}} - which is an RPC handler - is a bad idea, even if the RPCs are issued asynchronously. There's still some serialization cost.
> It's also a bad idea to do all this work while holding {{lock_}}. We should address both of these to ensure scalability of the cancellation path.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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