Sahil Takiar created IMPALA-7816:
------------------------------------
Summary: Race condition in
HdfsScanNodeBase::StopAndFinalizeCounters
Key: IMPALA-7816
URL: https://issues.apache.org/jira/browse/IMPALA-7816
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 3.1.0
Reporter: Sahil Takiar
Assignee: Sahil Takiar
While working on IMPALA-6964, I noticed that sometimes the runtime profile for
a {{HDFS_SCAN_NODE}} will include {{File Formats: PARQUET/NONE:2}} and
sometimes it won't (depending on the query). However, looking at the code, any
scan of Parquet files should include this line.
I debugged the code and there seems to a be a race condition where
{{HdfsScanNodeBase::StopAndFinalizeCounters}} can be called before
{{HdfsParquetScanner::Close}} is called for all the scan ranges. This causes
the {{File Formats}} issue above because {{HdfsParquetScanner::Close}} calls
{{HdfsScanNodeBase::RangeComplete}} which updates the shared object
{{file_type_counts_}}, which is read in {{StopAndFinalizeCounters}} (so
{{StopAndFinalizeCounters}} will write out the contents of
{{file_type_counts_}} before all scanners can update it).
{{StopAndFinalizeCounters}} can be called in two places:
{{HdfsScanNodeBase::Close}} and in {{HdfsScanNode::GetNext}}. It can be called
in {{GetNext}} when {{GetNextInternal}} reads enough rows to cross the query
defined limit. So {{GetNext}} will call {{StopAndFinalizeCounters}} once the
limit is reached, but not necessarily before the scanners are closed.
I'm able to re-produce this locally by using the queries:
{code:java}
select * from functional_parquet.lineitem_sixblocks limit 10 {code}
The runtime profile does not include {{File Formats}}
{code:java}
select * from functional_parquet.lineitem_sixblocks order by l_orderkey limit
10 {code}
The runtime profile does include {{File Formats}} I tried to simply remove the
call to {{StopAndFinalizeCounters}} from {{GetNext}} but that doesn't seem to
work. It actually caused several other RP messages to get deleted (not entirely
sure why).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
