You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@calcite.apache.org by "Caizhi Weng (JIRA)" <ji...@apache.org> on 2018/08/23 09:19:00 UTC

[jira] [Updated] (CALCITE-2484) Dynamic table tests give wrong results when running tests concurrently.

     [ https://issues.apache.org/jira/browse/CALCITE-2484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Caizhi Weng updated CALCITE-2484:
---------------------------------
    Description: 
When running tests on the cluster of my company, I always experience the failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After investigation, I discover that it is triggered by the cache in {{DefaultSqlTestFactory}} introduced in [this commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].

The failure of the test case is because:

# In the current implementation, when a test class wants to use a {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so every class using this factory actually shares the same factory instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog reader, table is stored in root schema, and row type is stored in table, every class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use doesn't exist, two test cases using the same table name may read and modify the same row type instance, causing the result of the test to be incorrect, thus the failure of the test.

What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let every test class use a new instance of the factory, so that we can solve the concurrent modification problem.

  was:
When running tests on the cluster of my company, I always experience the failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After investigation, I discover that it is triggered by the cache in {{DefaultSqlTestFactory}} introduced in [this commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].

The failure of the test case is because:

# In the current implementation, when a test class wants to use a {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so every class using this factory actually shares the same instance.
# {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class actually shares the same {{cache}}.
# The key of {{cache}} is of {{SqlTestFactory}} type, as every class shares the same factory instance, every class actually shares the same cache key.
# As catalog reader is stored in cache, root schema is stored in catalog reader, table is stored in root schema, and row type is stored in table, every class actually has access to the same row type instance.
# As dynamic table will modify row type if a column name it wants to use doesn't exist, two test cases using the same table name may read and modify the same row type instance, causing the result of the test to be incorrect, thus the failure of the test.

What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let every test class use a new instance of the factory, so that we can solve the concurrent modification problem.


> Dynamic table tests give wrong results when running tests concurrently.
> -----------------------------------------------------------------------
>
>                 Key: CALCITE-2484
>                 URL: https://issues.apache.org/jira/browse/CALCITE-2484
>             Project: Calcite
>          Issue Type: Bug
>          Components: core
>            Reporter: Caizhi Weng
>            Assignee: Julian Hyde
>            Priority: Major
>
> When running tests on the cluster of my company, I always experience the failure of the test {{SqlValidatorTest::testDynamicStar2()}}. After investigation, I discover that it is triggered by the cache in {{DefaultSqlTestFactory}} introduced in [this commit|https://github.com/apache/calcite/commit/39c22f0c8b7b5b46a152f432e8708ce73ace1ef7].
> The failure of the test case is because:
> # In the current implementation, when a test class wants to use a {{DefaultSqlTestFactory}}, it will use {{DefaultSqlTestFactory.INSTANCE}}, so every class using this factory actually shares the same factory instance.
> # {{cache}} is a private member of {{DefaultSqlTestFactory}}, so every class actually shares the same {{cache}}.
> # The key of {{cache}} is of {{SqlTestFactory}} type. As every class shares the same factory instance, every class actually shares the same cache key.
> # As catalog reader is stored in cache, root schema is stored in catalog reader, table is stored in root schema, and row type is stored in table, every class actually has access to the same row type instance.
> # As dynamic table will modify row type if a column name it wants to use doesn't exist, two test cases using the same table name may read and modify the same row type instance, causing the result of the test to be incorrect, thus the failure of the test.
> What we need to do is to remove {{DefaultSqlTestFactory.INSTANCE}}, and let every test class use a new instance of the factory, so that we can solve the concurrent modification problem.



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