You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "ASF subversion and git services (Jira)" <ji...@apache.org> on 2020/04/09 03:24:00 UTC
[jira] [Commented] (IMPALA-8857) test_kudu_col_not_null_changed may
fail because client reads older timestamp
[ https://issues.apache.org/jira/browse/IMPALA-8857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17078877#comment-17078877 ]
ASF subversion and git services commented on IMPALA-8857:
---------------------------------------------------------
Commit 49cdd785637c82d7ba3f38be7e5c13e2b7272c2e in impala's branch refs/heads/master from Thomas Tauber-Marshall
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=49cdd78 ]
IMPALA-8857: Fix flaky Kudu tests with external inserts
There are several Kudu related tests that are inherently flaky because
they insert rows into a Kudu table from the python Kudu client and
then scan the table from an Impala client even though no guarantees
are made about the consistency of operations from different clients.
This patch fixes this by adding a query option
'kudu_snapshot_read_timestamp_micros' which sets the timestamp at
which to perform Kudu snapshot reads.
The tests are then modified to set the timestamp to be equal to the
latest observed timestamp returned by the client that did the inserts
(plus 1 microsecond which the Kudu python client adds automatically
in latest_observed_timestamp() for this use case).
Change-Id: I5b787f6542dc31dcd846f19576a060a89aec891d
Reviewed-on: http://gerrit.cloudera.org:8080/15633
Reviewed-by: Impala Public Jenkins <im...@cloudera.com>
Tested-by: Impala Public Jenkins <im...@cloudera.com>
> test_kudu_col_not_null_changed may fail because client reads older timestamp
> ----------------------------------------------------------------------------
>
> Key: IMPALA-8857
> URL: https://issues.apache.org/jira/browse/IMPALA-8857
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
> Affects Versions: Impala 3.3.0
> Reporter: Tim Armstrong
> Assignee: Thomas Tauber-Marshall
> Priority: Critical
> Labels: flaky
>
> {noformat}
> uery_test/test_kudu.py:242: in test_kudu_col_not_null_changed
> assert len(cursor.fetchall()) == 100
> E assert 61 == 100
> E + where 61 = len([(0, None), (2, None), (4, None), (11, None), (12, None), (19, None), ...])
> E + where [(0, None), (2, None), (4, None), (11, None), (12, None), (19, None), ...] = <bound method HiveServer2Cursor.fetchall of <impala.hiveserver2.HiveServer2Cursor object at 0x7fe82c051550>>()
> E + where <bound method HiveServer2Cursor.fetchall of <impala.hiveserver2.HiveServer2Cursor object at 0x7fe82c051550>> = <impala.hiveserver2.HiveServer2Cursor object at 0x7fe82c051550>.fetchall
> {noformat}
> I believe this is a flaky tests, since there's no attempt to pass the timestamp from the kudu client that did the insert to the impala client that's doing the reading.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org