You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Vuk Ercegovac (JIRA)" <ji...@apache.org> on 2018/03/08 16:48:00 UTC

[jira] [Resolved] (IMPALA-6602) TestQueryExpiration.test_query_expiration fails on Isilon with FINISHED rather than EXCEPTION state

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

Vuk Ercegovac resolved IMPALA-6602.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: Impala 2.13.0
                   Impala 3.0

> TestQueryExpiration.test_query_expiration fails on Isilon with FINISHED rather than EXCEPTION state
> ---------------------------------------------------------------------------------------------------
>
>                 Key: IMPALA-6602
>                 URL: https://issues.apache.org/jira/browse/IMPALA-6602
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Backend
>    Affects Versions: Impala 2.12.0
>            Reporter: Lars Volker
>            Assignee: Vuk Ercegovac
>            Priority: Blocker
>              Labels: broken-build
>             Fix For: Impala 3.0, Impala 2.13.0
>
>
> TestQueryExpiration.test_query_expiration failed on Isilon. It looks like an additional query expired while the test was running. It is marked as execute_serially though.
> Here is the relevant part of the log:
> {noformat}
> 23:20:15 =========================== short test summary info ============================
> 23:20:15 XFAIL custom_cluster/test_alloc_fail.py::TestAllocFail::()::test_alloc_fail_update[exec_option: {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0, 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold': 0} | table_format: text/none]
> 23:20:15   IMPALA-2925: the execution is not deterministic so some tests sometimes don't fail as expected
> 23:20:15 FAIL custom_cluster/test_query_expiration.py::TestQueryExpiration::()::test_query_expiration[exec_option: {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0, 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold': 0} | table_format: text/none]
> 23:20:15 =================================== FAILURES ===================================
> 23:20:15  TestQueryExpiration.test_query_expiration[exec_option: {'batch_size': 0, 'num_nodes': 0, 'disable_codegen_rows_threshold': 0, 'disable_codegen': False, 'abort_on_error': 1, 'debug_action': None, 'exec_single_node_rows_threshold': 0} | table_format: text/none] 
> 23:20:15 custom_cluster/test_query_expiration.py:104: in test_query_expiration
> 23:20:15     assert (client.get_state(default_timeout_expire_handle2) ==
> 23:20:15 E   assert 4 == 5
> 23:20:15 E    +  where 4 = <bound method BeeswaxConnection.get_state of <tests.common.impala_connection.BeeswaxConnection object at 0x38e6390>>(<tests.common.impala_connection.OperationHandle object at 0x38e64d0>)
> 23:20:15 E    +    where <bound method BeeswaxConnection.get_state of <tests.common.impala_connection.BeeswaxConnection object at 0x38e6390>> = <tests.common.impala_connection.BeeswaxConnection object at 0x38e6390>.get_state
> {noformat}
> [~vukercegovac] - I picked you randomly; feel free to find another person or assign back to me if you're swamped. I’ve seen this happen in a private Jenkins run. Please ping me if you would like access to the build artifacts.



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