Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Duplicate
-
Impala 2.6.0
-
None
-
Standard jenkins job env
Description
Failed. The umbrella job running it is: http://sandbox.jenkins.cloudera.com/job/impala-umbrella-build-and-test/1946/
Failure message:
21:06:00 =================================== FAILURES =================================== 21:06:00 _____________________________ TestHS2.test_get_log _____________________________ 21:06:00 [gw0] linux2 -- Python 2.6.6 /data/jenkins/workspace/impala-umbrella-build-and-test/repos/Impala/bin/../infra/python/env/bin/python 21:06:00 hs2/hs2_test_suite.py:44: in add_session 21:06:00 fn(self) 21:06:00 hs2/test_hs2.py:285: in test_get_log 21:06:00 assert "Error converting column" in log 21:06:00 E assert 'Error converting column' in 'Query 2048526ab13c52b8:37743b8e25b5b4ae: 0% Complete (0 out of 3)\n' 21:06:00 ---------------------------- Captured stderr setup ----------------------------- 21:06:00 -- executing against localhost:21000 21:06:00 use default; 21:06:00 21:06:00 SET sync_ddl=1; 21:06:00 -- executing against localhost:21000 21:06:00 drop database if exists `hs2_db` cascade; 21:06:00 21:06:00 generated xml file: /data/jenkins/workspace/impala-umbrella-build-and-test/repos/Impala/logs/ee_tests/results/TEST-impala-parallel.xml 21:06:00 FAIL hs2/test_hs2.py::TestHS2::()::test_get_log 21:06:00 ======== 1 failed, 969 passed, 82 skipped, 9 xfailed in 1652.44 seconds ========
It's looking for the error result in the log response but seeing a progress message instead, and further the progress message is at 0% complete.
The query does execute; you can see the execution in the Impala logs. It doesn't show the error/result there.
Note it's running in parallel test set, so there is other concurrent activity.
The test itself first executes the query, checks response, fetch results and checks that response, and then gets the log. So, either the checks do not actually wait for the error and validate as it looks, or the progress messages are lagging somehow. If the former, it seems the test needs to be fixed, and the TGetLog is only to show current status, so if the query isn't done, you'd not expect to see the error. If the status is lagging in that the query is actually done but the TGetLog response doesn't see it, it may be a product bug.
./ee_tests/impalad.impala-boost-static-burst-slave-0967.vpc.cloudera.com.jenkins.log.INFO.20160621-193939.27395
I0621 20:44:04.710809 27653 admission-controller.cc:436] Schedule for id=2048526ab13c52b8:37743b8e25b5b4ae in pool_name=default-pool cluster_mem_needed=64.
00 MB PoolConfig: max_requests=-1 max_queued=200 max_mem=-1.00 B
I0621 20:44:04.710870 27653 admission-controller.cc:441] Stats: agg_num_running=3, agg_num_queued=0, agg_mem_reserved=48.34 MB, local_host(local_mem_admit
ted=1.79 GB, num_admitted_running=3, num_queued=0, backend_mem_reserved=48.34 MB)
I0621 20:44:04.710887 27653 admission-controller.cc:447] Admitted query id=2048526ab13c52b8:37743b8e25b5b4ae
I0621 20:44:04.710919 27653 coordinator.cc:384] Exec() query_id=2048526ab13c52b8:37743b8e25b5b4ae
I0621 20:44:04.711160 27653 plan-fragment-executor.cc:91] Prepare(): query_id=2048526ab13c52b8:37743b8e25b5b4ae instance_id=2048526ab13c52b8:37743b8e25b5b4
af
I0621 20:44:04.711606 27653 plan-fragment-executor.cc:201] descriptor table for fragment=2048526ab13c52b8:37743b8e25b5b4af
tuples:
Tuple(id=0 size=96 slots=[Slot(id=0 type=INT col_path=[2] offset=8 null=(offset=0 mask=8) slot_idx=3 field_idx=-1), Slot(id=1 type=BOOLEAN col_path=[3] off
set=2 null=(offset=0 mask=1) slot_idx=0 field_idx=-1), Slot(id=2 type=TINYINT col_path=[4] offset=3 null=(offset=0 mask=2) slot_idx=1 field_idx=-1), Slot(i
d=3 type=SMALLINT col_path=[5] offset=4 null=(offset=0 mask=4) slot_idx=2 field_idx=-1), Slot(id=4 type=INT col_path=[6] offset=12 null=(offset=0 mask=10)
slot_idx=4 field_idx=-1), Slot(id=5 type=BIGINT col_path=[7] offset=32 null=(offset=1 mask=1) slot_idx=8 field_idx=-1), Slot(id=6 type=FLOAT col_path=[8] o
ffset=16 null=(offset=0 mask=20) slot_idx=5 field_idx=-1), Slot(id=7 type=DOUBLE col_path=[9] offset=40 null=(offset=1 mask=2) slot_idx=9 field_idx=-1), Sl
ot(id=8 type=STRING col_path=[10] offset=48 null=(offset=1 mask=4) slot_idx=10 field_idx=-1), Slot(id=9 type=STRING col_path=[11] offset=64 null=(offset=1
mask=8) slot_idx=11 field_idx=-1), Slot(id=10 type=TIMESTAMP col_path=[12] offset=80 null=(offset=1 mask=10) slot_idx=12 field_idx=-1), Slot(id=11 type=INT
col_path=[0] offset=20 null=(offset=0 mask=40) slot_idx=6 field_idx=-1), Slot(id=12 type=INT col_path=[1] offset=24 null=(offset=0 mask=80) slot_idx=7 fie
ld_idx=-1)] tuple_path=[])
I0621 20:44:04.712061 27653 coordinator.cc:547] starting 1 fragment instances for query 2048526ab13c52b8:37743b8e25b5b4ae
I0621 20:44:04.713042 18520 fragment-mgr.cc:36] ExecPlanFragment() instance_id=2048526ab13c52b8:37743b8e25b5b4b0 coord=impala-boost-static-burst-slave-0967
.vpc.cloudera.com:22000 fragment instance#=0
I0621 20:44:04.713452 13604 plan-fragment-executor.cc:91] Prepare(): query_id=2048526ab13c52b8:37743b8e25b5b4ae instance_id=2048526ab13c52b8:37743b8e25b5b4
b0
I0621 20:44:04.713913 13605 plan-fragment-executor.cc:310] Open(): instance_id=2048526ab13c52b8:37743b8e25b5b4af
I0621 20:44:04.713973 27653 impala-hs2-server.cc:788] ExecuteStatement(): return_val=TExecuteStatementResp {
01: status (struct) = TStatus {
01: statusCode (i32) = 0,
},
02: operationHandle (struct) = TOperationHandle {
01: operationId (struct) = THandleIdentifier {
01: guid (string) = "\xb8R<\xb1jRH \xae\xb4\xb5%\x8e;t7",
02: secret (string) = "\xb8R<\xb1jRH \xae\xb4\xb5%\x8e;t7",
},
02: operationType (i32) = 0,
03: hasResultSet (bool) = true,
},
}
I0621 20:44:04.714815 13604 plan-fragment-executor.cc:201] descriptor table for fragment=2048526ab13c52b8:37743b8e25b5b4b0
tuples:
...
Attachments
Issue Links
- duplicates
-
-
- Resolved
-