spark-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From liancheng <>
Subject [GitHub] spark pull request: [SPARK-6910] [SQL] Support for pushing predica...
Date Sat, 18 Jul 2015 10:26:41 GMT
Github user liancheng commented on the pull request:
    Investigated the following 3 build failure samples:
    Firstly, this issue couldn't be steadily reproduced, and only showed up on Jenkins occasionally.
 An obvious guess is that it's probably a concurrency bug and only occurs within highly concurrent
jobs (the Jenkins server has 32 cores, while our laptops have only 8 or less).
    Secondly, all 3 build failures behaved extremely consistently: 18 `ParquetDataSourceOffMetastoreSuite`
test cases involving partitioned Hive metastore Parquet tables failed altogether.  It seems
that some **internal Hive state** got corrupted before this test suite was executed.  However,
this PR only updates the read path and doesn't introduce any extra state.  So my guess is
that, this PR doesn't introduce but just somehow triggers an existing issue.  The root cause
probably lies in some initialization phase, e.g. `HiveContext` initialization, or testing
partitioned table creation in `ParquetDataSourceOffMetastoreSuite.beforeAll()`.
    And I got another interesting finding after single step debugging a failed test case.
 The following stacktrace snippet appears in all 3 build failures:
    Caused by: MetaException(message:Filtering is supported only on partition keys of type
          | at org.apache.hadoop.hive.metastore.parser.ExpressionTree$FilterBuilder.setError(
          | at org.apache.hadoop.hive.metastore.parser.ExpressionTree$LeafNode.getJdoFilterPushdownParam(
          | at org.apache.hadoop.hive.metastore.parser.ExpressionTree$LeafNode.generateJDOFilterOverPartitions(
          | at org.apache.hadoop.hive.metastore.parser.ExpressionTree$LeafNode.generateJDOFilter(
          | at org.apache.hadoop.hive.metastore.parser.ExpressionTree.generateJDOFilterFragment(
          | at org.apache.hadoop.hive.metastore.ObjectStore.makeQueryFilterString(
          | at org.apache.hadoop.hive.metastore.ObjectStore.getPartitionsViaOrmFilter(
          | at org.apache.hadoop.hive.metastore.ObjectStore.access$500(
          | at org.apache.hadoop.hive.metastore.ObjectStore$4.getJdoResult(
          | at org.apache.hadoop.hive.metastore.ObjectStore$4.getJdoResult(
            at org.apache.hadoop.hive.metastore.ObjectStore$
    The marked code path showed above is actually NEVER executed in normal cases.  To be more
specific, the `getJdoResult()` method in [the anonymous `GetListHelper` object] [1] is never
called in [`GetHelper<T>.run()`] [2].  Instead, only the `getSqlResult()` method is
called.  And we can see that this behavior is controlled by `doUseDirectSql`, which is [partially
decided] [3] by [`ObjectStore.directSql.isCompatibleDatastore`] [4].  Since `ObjectStore`
is initialized while initializing `HiveContext`, `ObjectStore.directSql.isCompatibleDatastore`
is probably the corrupted Hive internal state.
    Haven't got any clue how this state gets corrupted yet.  My guess is that there is a race
condition during `HiveContext` initialization.  For example, maybe the underlying Derby database
is not fully created while `ObjectStore` is been initialized.

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at or file a JIRA ticket
with INFRA.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message