You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Tim Armstrong (JIRA)" <ji...@apache.org> on 2018/04/24 22:01:00 UTC

[jira] [Created] (IMPALA-6920) Multithreaded scans are not guaranteed to get a thread token immediately

Tim Armstrong created IMPALA-6920:
-------------------------------------

             Summary: Multithreaded scans are not guaranteed to get a thread token immediately
                 Key: IMPALA-6920
                 URL: https://issues.apache.org/jira/browse/IMPALA-6920
             Project: IMPALA
          Issue Type: Bug
          Components: Backend
    Affects Versions: Impala 2.12.0
            Reporter: Tim Armstrong
            Assignee: Tim Armstrong


So what happens is that we reserve an optional token for the first scanner thread but that can be taken by any other operator in the same fragment. What happens in one fragment in TPC-DS q18a is:
1. The hash join grabs an extra token for the join build. I guess it does this early so it gets an optional token before other fragments can grab them.
2. The scan node reserves an optional token in Open(). This optional token is already in use by the hash join.
3. The scan node tries to start the first scanner thread, but there are no optional tokens available, so it can't start any.
4. Eventually the optional token is given up and the scanner thread can start.

If #4 always happens without the scan making progress, then no deadlock is possible, but if there's any kind of circular dependency, this can deadlock.



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