[
https://issues.apache.org/jira/browse/IMPALA-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17132726#comment-17132726
]
Tim Armstrong commented on IMPALA-9706:
---------------------------------------
I had thought about this at one point with a group and I think it's basically
hard.
Often we know a thread belongs to a query (or is executing an operation on
behalf of a query) cause we store that in a thread-local variable. That can't
be 100% accurate for various reasons, but would probably be accurate 95% of the
time.
The problem then is actually communicating that the particular query caused the
crash in a timely manner (the process is crashing obviously, so can't really do
very much safely). The least crazy idea I heard is to have the crashing process
write the offending query ID to a file (or stdout, or somewhere else) and have
a watchdog process that broadcasts the fact that the query caused a crash to
whoever needs to know.
That is a fair bit of complexity though.
> Test that queries are not retried if they cause an impalad to crash
> -------------------------------------------------------------------
>
> Key: IMPALA-9706
> URL: https://issues.apache.org/jira/browse/IMPALA-9706
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
> Reporter: Sahil Takiar
> Priority: Major
>
> IMPALA-9199 adds the core functionality for retrying queries, but it does not
> contain any tests that validate a query is not retried if the query itself
> caused an impalad to crash. If a query causes an impalad to crash, it should
> not be retried because it will likely just cause the impalad to crash again.
> There may not be a straightforward way to do this. I'm not sure how Impala
> can differentiate between query "x" causing a crash vs. anything else that
> can cause an impalad to crash. However, opening this JIRA to (1) document
> that this could be an issue, and (2) brainstorm any ideas.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
