[ 
https://issues.apache.org/jira/browse/IMPALA-14160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18016088#comment-18016088
 ] 

Michael Smith commented on IMPALA-14160:
----------------------------------------

This looks like an issue in an upcoming version of Ozone: it's incorrectly 
reporting a file as not encrypted, then switching to encrypted later in the 
test. Trying to isolate what change caused it.

This also suggests two other changes we should do:
# Tuple caching shouldn't care whether a file is encrypted, as it doesn't 
change the unencrypted contents. So we should omit that from the tuple cache 
key.
# Impala testing should have caught this, but since it's temporary 
test_io_metrics.py doesn't fail in full test runs. We should have a test that 
does two things: verify the profile shows bytes are encrypted, and check for 
encryption on a newly created table.

> TestTupleCacheCluster.test_runtime_filters fails on Ozone
> ---------------------------------------------------------
>
>                 Key: IMPALA-14160
>                 URL: https://issues.apache.org/jira/browse/IMPALA-14160
>             Project: IMPALA
>          Issue Type: Bug
>          Components: Frontend
>    Affects Versions: Impala 5.0.0
>            Reporter: Joe McDonnell
>            Assignee: Michael Smith
>            Priority: Blocker
>
> On certain versions of Ozone, TestTupleCacheCluster.test_runtime_filters 
> fails with:
> {noformat}
> custom_cluster/test_tuple_cache.py:501: in test_runtime_filters
>     assertCounters(rerun_two_files_result.runtime_profile, 1, 0, 0, 
> num_matches=8)
> custom_cluster/test_tuple_cache.py:75: in assertCounters
>     assertCounter(profile, NUM_HITS, num_hits, num_matches)
> custom_cluster/test_tuple_cache.py:71: in assertCounter
>     assert len([v for v in values if v == val]) in num_matches, values
> E   AssertionError: [0, 0, 0, 1, 1, 0, ...]
> E   assert 2 in [8]
> E    +  where 2 = len([1, 1]){noformat}
> This is running "invalidate metadata" and expecting the cache keys not to 
> change. It seems to have been working until recently, so it is possible there 
> is some interaction with the version of Ozone.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to