[jira] [Work started] (IMPALA-9921) Parse errors in ToSqlUtils.hiveNeedsQuotes should not be printed to impalad.ERROR
[
https://issues.apache.org/jira/browse/IMPALA-9921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on IMPALA-9921 started by Quanlong Huang.
--
> Parse errors in ToSqlUtils.hiveNeedsQuotes should not be printed to
> impalad.ERROR
> -
>
> Key: IMPALA-9921
> URL: https://issues.apache.org/jira/browse/IMPALA-9921
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
>Reporter: Quanlong Huang
>Assignee: Quanlong Huang
>Priority: Critical
>
> Impala planner will check whether an ident needs to be quoted in toSql
> outputs by using the HiveLexer (org.apache.hadoop.hive.ql.parse.HiveLexer).
> However, when there are parse errors from HiveLexer, the error messages will
> be printed to stderr which is redirected to impalad.ERROR. Actually, these
> error messages only means the ident needs to be quoted. They should have a
> lower log level and shouldn't be printed to impalad.ERROR.
> A possible solution is to extend HiveLexer and override the
> displayRecognitionError() as HiveLexerX does. We can also consider using
> HiveLexerX directly.
> *Reproduction*
> {code:java}
> impala-shell> select 'hello' as `你好`;
> {code}
> Some error messages are printed in impalad.ERROR:
> {code:java}
> line 1:0 no viable alternative at character '你'
> line 1:1 no viable alternative at character '好'
> line 1:0 no viable alternative at character '你'
> line 1:1 no viable alternative at character '好'
> line 1:0 no viable alternative at character '你'
> line 1:1 no viable alternative at character '好'
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Comment Edited] (IMPALA-9741) Support query iceberg table by impala
[ https://issues.apache.org/jira/browse/IMPALA-9741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152439#comment-17152439 ] WangSheng edited comment on IMPALA-9741 at 7/7/20, 2:35 AM: Hi [~tarmstrong],[~boroknagyz],[~vihangk1], I have already completed a version of query iceberg table by impala. The main design is treated iceberg table as an unpartitioned hdfs table, including theses functions: # identity iceberg file format by table property; # push down iceberg partition column predicates to iceberg, to filter data files need to be scanned; This is a simple version, and some code may be not good, hope you can give some advice, thanks a lot. Here is the gerrit url: https://gerrit.cloudera.org/#/c/16143/ was (Author: skyyws): Hi [~tarmstrong],[~boroknagyz],[~vihangk1], I have already completed a version of query iceberg table by impala. The main design is treated iceberg table as an unpartitioned hdfs table, including theses functions: # identity iceberg file format by table property; # push down iceberg partition column predicates to iceberg, to filter data files need to be scanned; This is a simple version, and some code may be not good, hope you can give some advice, thanks a lot. Here is the gerrit url: https://gerrit.cloudera.org/#/c/16143/ > Support query iceberg table by impala > - > > Key: IMPALA-9741 > URL: https://issues.apache.org/jira/browse/IMPALA-9741 > Project: IMPALA > Issue Type: Sub-task >Reporter: WangSheng >Assignee: WangSheng >Priority: Major > Attachments: select-iceberg.jpg > > > Since we have submit an patch of supporting create iceberg table by impala in > IMPALA-9688, we are preparing to implement iceberg table query by impala. But > we need to read the impala and iceberg code deeply to determine how to do > this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Comment Edited] (IMPALA-9741) Support query iceberg table by impala
[ https://issues.apache.org/jira/browse/IMPALA-9741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152439#comment-17152439 ] WangSheng edited comment on IMPALA-9741 at 7/7/20, 2:32 AM: Hi [~tarmstrong],[~boroknagyz],[~vihangk1], I have already completed a version of query iceberg table by impala. The main design is treated iceberg table as an unpartitioned hdfs table, including theses functions: # identity iceberg file format by table property; # push down iceberg partition column predicates to iceberg, to filter data files need to be scanned; This is a simple version, and some code may be not good, hope you can give some advice, thanks a lot. Here is the gerrit url: https://gerrit.cloudera.org/#/c/16143/ was (Author: skyyws): Hi [~tarmstrong],[~boroknagyz],[~vihangk1], I have already completed a version of query iceberg table by impala. The main design is treated iceberg table as an unpartitioned hdfs table, including theses functions: # identity iceberg file format by table property; # push down iceberg partition column predicates to iceberg, to filter data files need to be scanned; This is a simple version, and some code may be not good, hope you can give some advice, thanks a lot. Here is the gerrit url: https://gerrit.cloudera.org/#/c/16143/ > Support query iceberg table by impala > - > > Key: IMPALA-9741 > URL: https://issues.apache.org/jira/browse/IMPALA-9741 > Project: IMPALA > Issue Type: Sub-task >Reporter: WangSheng >Assignee: WangSheng >Priority: Major > Attachments: select-iceberg.jpg > > > Since we have submit an patch of supporting create iceberg table by impala in > IMPALA-9688, we are preparing to implement iceberg table query by impala. But > we need to read the impala and iceberg code deeply to determine how to do > this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9741) Support query iceberg table by impala
[ https://issues.apache.org/jira/browse/IMPALA-9741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152439#comment-17152439 ] WangSheng commented on IMPALA-9741: --- Hi [~tarmstrong],[~boroknagyz],[~vihangk1], I have already completed a version of query iceberg table by impala. The main design is treated iceberg table as an unpartitioned hdfs table, including theses functions: # identity iceberg file format by table property; # push down iceberg partition column predicates to iceberg, to filter data files need to be scanned; This is a simple version, and some code may be not good, hope you can give some advice, thanks a lot. Here is the gerrit url: https://gerrit.cloudera.org/#/c/16143/ > Support query iceberg table by impala > - > > Key: IMPALA-9741 > URL: https://issues.apache.org/jira/browse/IMPALA-9741 > Project: IMPALA > Issue Type: Sub-task >Reporter: WangSheng >Assignee: WangSheng >Priority: Major > Attachments: select-iceberg.jpg > > > Since we have submit an patch of supporting create iceberg table by impala in > IMPALA-9688, we are preparing to implement iceberg table query by impala. But > we need to read the impala and iceberg code deeply to determine how to do > this. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-9921) Parse errors in ToSqlUtils.hiveNeedsQuotes should not be printed to impalad.ERROR
Quanlong Huang created IMPALA-9921:
--
Summary: Parse errors in ToSqlUtils.hiveNeedsQuotes should not be
printed to impalad.ERROR
Key: IMPALA-9921
URL: https://issues.apache.org/jira/browse/IMPALA-9921
Project: IMPALA
Issue Type: Improvement
Components: Frontend
Reporter: Quanlong Huang
Assignee: Quanlong Huang
Impala planner will check whether an ident needs to be quoted in toSql outputs
by using the HiveLexer (org.apache.hadoop.hive.ql.parse.HiveLexer). However,
when there are parse errors from HiveLexer, the error messages will be printed
to stderr which is redirected to impalad.ERROR. Actually, these error messages
only means the ident needs to be quoted. They should have a lower log level and
shouldn't be printed to impalad.ERROR.
A possible solution is to extend HiveLexer and override the
displayRecognitionError() as HiveLexerX does. We can also consider using
HiveLexerX directly.
*Reproduction*
{code:java}
impala-shell> select 'hello' as `你好`;
{code}
Some error messages are printed in impalad.ERROR:
{code:java}
line 1:0 no viable alternative at character '你'
line 1:1 no viable alternative at character '好'
line 1:0 no viable alternative at character '你'
line 1:1 no viable alternative at character '好'
line 1:0 no viable alternative at character '你'
line 1:1 no viable alternative at character '好'
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-9920) BufferPoolTest.WriteErrorBlacklistHolepunch failed on FindPageInDir check
Wenzhe Zhou created IMPALA-9920: --- Summary: BufferPoolTest.WriteErrorBlacklistHolepunch failed on FindPageInDir check Key: IMPALA-9920 URL: https://issues.apache.org/jira/browse/IMPALA-9920 Project: IMPALA Issue Type: Bug Components: Backend Affects Versions: Impala 4.0 Environment: BUILD_TAG jenkins-impala-cdpd-master-core-ubsan-108 Reporter: Wenzhe Zhou Assignee: Tim Armstrong Attachments: buffer-pool-test.ERROR BufferPoolTest.WriteErrorBlacklistHolepunch failed with following error messages: Error Message Value of: FindPageInDir(pages[NO_ERROR_QUERY], good_dir) != NULL Actual: false Expected: true Stacktrace /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/runtime/bufferpool/buffer-pool-test.cc:1763 Value of: FindPageInDir(pages[NO_ERROR_QUERY], good_dir) != NULL Actual: false Expected: true Saw following messages in buffer-pool-test.ERROR log file: F0702 14:17:08.745453 8976 reservation-tracker.cc:389] Check failed: bytes <= unused_reservation() (1024 vs. 0) F0702 14:17:14.581707 12727 reservation-tracker.cc:389] Check failed: bytes <= unused_reservation() (1024 vs. 0) F0702 14:17:14.671219 12728 reservation-tracker.cc:389] Check failed: bytes <= unused_reservation() (1024 vs. 0) F0702 14:17:14.840062 12940 buffer-pool.cc:216] Check failed: page_handle->is_pinned() F0702 14:17:15.167520 13459 buffer-pool.cc:493] Check failed: spilling_enabled() F0702 14:17:15.326829 13946 reservation-tracker.cc:389] Check failed: bytes <= unused_reservation() (1024 vs. 0) E0702 14:17:17.119957 16180 tmp-file-mgr.cc:334] Error for temporary file '/tmp/impala-scratch/:_354de439-8418-4013-8ebe-55214f8396c5': Disk I/O error on impala-ec2-centos74-m5-4xlarge-ondemand-1884.vpc.cloudera.com:22000: open() failed for /tmp/impala-scratch/:_354de439-8418-4013-8ebe-55214f8396c5. Access denied for the process' user errno=13 E0702 14:17:17.270885 16570 tmp-file-mgr.cc:334] Error for temporary file '/tmp/buffer-pool-test.0/impala-scratch/:_21e8f7c1-2a63-44d5-8a5c-4ba78e9acb6e': Disk I/O error on impala-ec2-centos74-m5-4xlarge-ondemand-1884.vpc.cloudera.com:22000: open() failed for /tmp/buffer-pool-test.0/impala-scratch/:_21e8f7c1-2a63-44d5-8a5c-4ba78e9acb6e. Access denied for the process' user errno=13 E0702 14:17:17.436445 16964 tmp-file-mgr.cc:334] Error for temporary file '/tmp/buffer-pool-test.0/impala-scratch/:_78d2ef68-254a-4738-baf6-6e80b3b1ee2a': Disk I/O error on impala-ec2-centos74-m5-4xlarge-ondemand-1884.vpc.cloudera.com:22000: open() failed for /tmp/buffer-pool-test.0/impala-scratch/:_78d2ef68-254a-4738-baf6-6e80b3b1ee2a. Access denied for the process' user errno=13 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9884) TestAdmissionControllerStress.test_mem_limit failing occasionally
[
https://issues.apache.org/jira/browse/IMPALA-9884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152376#comment-17152376
]
Tim Armstrong commented on IMPALA-9884:
---
This test was tricky because it's trying to test an inherently
non-deterministic admission control algorithm. Will see if I can reproduce by
looping.
> TestAdmissionControllerStress.test_mem_limit failing occasionally
> -
>
> Key: IMPALA-9884
> URL: https://issues.apache.org/jira/browse/IMPALA-9884
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 4.0
>Reporter: Vihang Karajgaonkar
>Assignee: Tim Armstrong
>Priority: Blocker
> Labels: broken-build, flaky
>
> Recently, I saw this test failing with the exception trace below.
> {noformat}
> custom_cluster/test_admission_controller.py:1782: in test_mem_limit
> {'request_pool': self.pool_name, 'mem_limit': query_mem_limit})
> custom_cluster/test_admission_controller.py:1638: in run_admission_test
> assert metric_deltas['dequeued'] == 0,\
> E AssertionError: Queued queries should not run until others are made to
> finish
> E assert 1 == 0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-9888) Materialise truncations in sort
[ https://issues.apache.org/jira/browse/IMPALA-9888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Armstrong updated IMPALA-9888: -- Priority: Trivial (was: Minor) > Materialise truncations in sort > > > Key: IMPALA-9888 > URL: https://issues.apache.org/jira/browse/IMPALA-9888 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Reporter: Tim Armstrong >Priority: Trivial > > Related to IMPALA-7020, it would be useful to materialise truncations, e.g. > if we had an "ORDER BY cast(s as varchar(4))". Currently we would include 's' > in the sort tuple if it was referenced like this in the ORDER BY and the cast > expr is not one of the result exprs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-9888) Materialise truncations in sort
[ https://issues.apache.org/jira/browse/IMPALA-9888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Armstrong reassigned IMPALA-9888: - Assignee: (was: Tim Armstrong) > Materialise truncations in sort > > > Key: IMPALA-9888 > URL: https://issues.apache.org/jira/browse/IMPALA-9888 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Reporter: Tim Armstrong >Priority: Minor > > Related to IMPALA-7020, it would be useful to materialise truncations, e.g. > if we had an "ORDER BY cast(s as varchar(4))". Currently we would include 's' > in the sort tuple if it was referenced like this in the ORDER BY and the cast > expr is not one of the result exprs. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-9902) Add rewrite of TPC-DS q38
[ https://issues.apache.org/jira/browse/IMPALA-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim Armstrong resolved IMPALA-9902. --- Fix Version/s: Impala 4.0 Resolution: Fixed > Add rewrite of TPC-DS q38 > - > > Key: IMPALA-9902 > URL: https://issues.apache.org/jira/browse/IMPALA-9902 > Project: IMPALA > Issue Type: Test > Components: Infrastructure >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Major > Labels: tpcds > Fix For: Impala 4.0 > > > TPC-DS q38 uses intersect, but we can do something equivalent with > subqueries. This seems worth adding to our test suite. > We already have something similar with q8 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9902) Add rewrite of TPC-DS q38
[ https://issues.apache.org/jira/browse/IMPALA-9902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152375#comment-17152375 ] ASF subversion and git services commented on IMPALA-9902: - Commit 24f24b131f0c40efe2aaff3ebcff9fe1cdeb6c88 in impala's branch refs/heads/master from Tim Armstrong [ https://gitbox.apache.org/repos/asf?p=impala.git;h=24f24b1 ] IMPALA-9902: add rewrite of TPC-DS q38 I generated the query with dsqgen and then rewrote it to avoid intersect. Testing: Compared results to hive running the original version of the query. Change-Id: I81807683aa265a946729e15156bd2e33724103e1 Reviewed-on: http://gerrit.cloudera.org:8080/16118 Reviewed-by: Tim Armstrong Reviewed-by: Joe McDonnell Tested-by: Impala Public Jenkins > Add rewrite of TPC-DS q38 > - > > Key: IMPALA-9902 > URL: https://issues.apache.org/jira/browse/IMPALA-9902 > Project: IMPALA > Issue Type: Test > Components: Infrastructure >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Major > Labels: tpcds > > TPC-DS q38 uses intersect, but we can do something equivalent with > subqueries. This seems worth adding to our test suite. > We already have something similar with q8 -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9453) S3 build failed with many strange symptoms
[
https://issues.apache.org/jira/browse/IMPALA-9453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152347#comment-17152347
]
Wenzhe Zhou commented on IMPALA-9453:
-
It happened in recent build with similar symptom, i.e. lots of incorrect
results for s3 build, but impalad did not crash.
> S3 build failed with many strange symptoms
> --
>
> Key: IMPALA-9453
> URL: https://issues.apache.org/jira/browse/IMPALA-9453
> Project: IMPALA
> Issue Type: Bug
>Affects Versions: Impala 3.4.0
>Reporter: Tim Armstrong
>Assignee: Sahil Takiar
>Priority: Blocker
> Labels: broken-build, crash
>
> There were a lot of incorrect results:
> {noformat}
> uery_test/test_mt_dop.py:49: in test_mt_dop
> self.run_test_case('QueryTest/mt-dop', new_vector)
> common/impala_test_suite.py:690: in run_test_case
> self.__verify_results_and_errors(vector, test_section, result, use_db)
> common/impala_test_suite.py:523: in __verify_results_and_errors
> replace_filenames_with_placeholder) common/test_result_verifier.py:456: in
> verify_raw_results VERIFIER_MAP[verifier](expected, actual)
> common/test_result_verifier.py:278: in verify_query_result_is_equal
> assert expected_results == actual_results E assert Comparing
> QueryTestResults (expected vs actual): E 7300 != 6990
> Stacktrace
> query_test/test_mt_dop.py:49: in test_mt_dop
> self.run_test_case('QueryTest/mt-dop', new_vector)
> common/impala_test_suite.py:690: in run_test_case
> self.__verify_results_and_errors(vector, test_section, result, use_db)
> common/impala_test_suite.py:523: in __verify_results_and_errors
> replace_filenames_with_placeholder)
> common/test_result_verifier.py:456: in verify_raw_results
> VERIFIER_MAP[verifier](expected, actual)
> common/test_result_verifier.py:278: in verify_query_result_is_equal
> assert expected_results == actual_results
> E assert Comparing QueryTestResults (expected vs actual):
> E 7300 != 6990
> Standard Error
> ERROR:test_configuration:Comparing QueryTestResults (expected vs actual):
> 7300 != 6990
> {noformat}
> The impalads eventually crashed:
> {noformat}
> F0302 00:50:55.607841 483 parquet-page-reader.cc:67]
> e24eb0839fa75423:8ac0bf730002] Check failed: col_end <
> file_desc.file_length (7010 vs. 7010)
> *** Check failure stack trace: ***
> @ 0x4f7277c google::LogMessage::Fail()
> @ 0x4f74021 google::LogMessage::SendToLog()
> @ 0x4f72156 google::LogMessage::Flush()
> @ 0x4f7571d google::LogMessageFatal::~LogMessageFatal()
> @ 0x2e3a520 impala::ParquetPageReader::InitColumnChunk()
> @ 0x2e37dee impala::ParquetColumnChunkReader::InitColumnChunk()
> @ 0x2cd8000 impala::BaseScalarColumnReader::Reset()
> @ 0x2c91239 impala::HdfsParquetScanner::InitScalarColumns()
> @ 0x2c8775a impala::HdfsParquetScanner::NextRowGroup()
> @ 0x2c85c2a impala::HdfsParquetScanner::GetNextInternal()
> @ 0x2c8403e impala::HdfsParquetScanner::ProcessSplit()
> @ 0x28b826b impala::HdfsScanNode::ProcessSplit()
> @ 0x28b7440 impala::HdfsScanNode::ScannerThread()
> @ 0x28b679d
> _ZZN6impala12HdfsScanNode22ThreadTokenAvailableCbEPNS_18ThreadResourcePoolEENKUlvE_clEv
> @ 0x28b8d91
> _ZN5boost6detail8function26void_function_obj_invoker0IZN6impala12HdfsScanNode22ThreadTokenAvailableCbEPNS3_18ThreadResourcePoolEEUlvE_vE6invokeERNS1_15function_bufferE
> @ 0x20aa1e9 boost::function0<>::operator()()
> @ 0x266a84a impala::Thread::SuperviseThread()
> @ 0x2672ace boost::_bi::list5<>::operator()<>()
> @ 0x26729f2 boost::_bi::bind_t<>::operator()()
> @ 0x26729b5 boost::detail::thread_data<>::run()
> @ 0x3e98b19 thread_proxy
> @ 0x7f8c2ccefe24 start_thread
> @ 0x7f8c2985b34c __clone
> {noformat}
> {noformat}
> F0302 00:50:41.466794 32643 parquet-page-reader.cc:67]
> dd48a46583bea9c8:e3be6412] Check failed: col_end <
> file_desc.file_length (7010 vs. 7010)
> *** Check failure stack trace: ***
> @ 0x4f7277c google::LogMessage::Fail()
> @ 0x4f74021 google::LogMessage::SendToLog()
> @ 0x4f72156 google::LogMessage::Flush()
> @ 0x4f7571d google::LogMessageFatal::~LogMessageFatal()
> @ 0x2e3a520 impala::ParquetPageReader::InitColumnChunk()
> @ 0x2e37dee impala::ParquetColumnChunkReader::InitColumnChunk()
> @ 0x2cd8000 impala::BaseScalarColumnReader::Reset()
> @ 0x2c91239 impala::HdfsParquetScanner::InitScalarColumns()
> @ 0x2c8775a
[jira] [Commented] (IMPALA-1995) Flaky test: PlannerTest.testHbase: splits for HBASE KEYRANGE not set up correctly.
[
https://issues.apache.org/jira/browse/IMPALA-1995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152304#comment-17152304
]
Wenzhe Zhou commented on IMPALA-1995:
-
Happened again in a recent build.
section SCANRANGELOCATIONS of query:
select * from functional_hbase.stringids
where id > '5'
and tinyint_col = 5
Actual does not match expected result:
HBASE KEYRANGE 5\0:9
^^
HBASE KEYRANGE 9:
NODE 0:
Expected:
HBASE KEYRANGE 5\0:7
HBASE KEYRANGE 7:
NODE 0:
> Flaky test: PlannerTest.testHbase: splits for HBASE KEYRANGE not set up
> correctly.
> --
>
> Key: IMPALA-1995
> URL: https://issues.apache.org/jira/browse/IMPALA-1995
> Project: IMPALA
> Issue Type: Task
> Components: Frontend
>Affects Versions: Impala 2.3.0, Impala 3.2.0
>Reporter: Alexander Behm
>Assignee: Joe McDonnell
>Priority: Critical
> Labels: broken-build, flaky, test-infra
> Fix For: Impala 2.13.0, Impala 3.1.0
>
>
> Looks like testdata/bin/split-hbase.sh does not always set up the ranges in
> the way we want. See failure below.
> Example run:
> http://sandbox.jenkins.cloudera.com/job/impala-master-cdh5-trunk/1090/
> {code}
> Stack Trace:
> java.lang.AssertionError: section SCANRANGELOCATIONS of query:
> select * from functional_hbase.alltypessmall
> where id < 5
> actual result doesn't match expected result:
> HBASE KEYRANGE port=16202 3:7
> ^^^
> HBASE KEYRANGE port=16203 7:
> HBASE KEYRANGE port=16203 :3
> NODE 0:
> expected:
> HBASE KEYRANGE port=16201 :3
> HBASE KEYRANGE port=16202 3:7
> HBASE KEYRANGE port=16203 7:
> NODE 0:
> section SCANRANGELOCATIONS of query:
> select * from functional_hbase.stringids
> where id < '5'
> and tinyint_col = 5
> actual result doesn't match expected result:
> HBASE KEYRANGE port=16201 1:3
> ^^^
> HBASE KEYRANGE port=16202 3:5
> HBASE KEYRANGE port=16203 :1
> NODE 0:
> expected:
> HBASE KEYRANGE port=16201 :3
> HBASE KEYRANGE port=16202 3:5
> NODE 0:
> section SCANRANGELOCATIONS of query:
> select * from functional_hbase.alltypesagg
> where bigint_col is not null and bool_col = true
> actual result doesn't match expected result:
> HBASE KEYRANGE port=16201 1:3
> ^^^
> HBASE KEYRANGE port=16202 3:7
> HBASE KEYRANGE port=16203 7:
> HBASE KEYRANGE port=16203 :1
> NODE 0:
> expected:
> HBASE KEYRANGE port=16201 :3
> HBASE KEYRANGE port=16202 3:7
> HBASE KEYRANGE port=16203 7:
> NODE 0:
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9919) Bad Impala Performance after a period of time
[ https://issues.apache.org/jira/browse/IMPALA-9919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152109#comment-17152109 ] Tim Armstrong commented on IMPALA-9919: --- The most likely explanation based on the large # of threads is the thrift RPC stack causing problems. https://blog.cloudera.com/scalability-improvement-of-apache-impala-2-12-0-in-cdh-5-15-0/ talks a bit about the thread issue for context. Probably IMPALA-2567 would fix this on its own, and the later scalability improvements would help further - IMPALA-2990 IMPALA-7984. IMPALA-7239 could also be contributing. Those symptoms would also be explained if your system is low on memory and swapping. I don't think there are any actions the Apache Impala project can take on this unless we have a lot more details or it reproduces on a later version. > Bad Impala Performance after a period of time > - > > Key: IMPALA-9919 > URL: https://issues.apache.org/jira/browse/IMPALA-9919 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.10.0 > Environment: OS: CentOS 6.9 >Reporter: Vagelis Nomikos >Priority: Major > Labels: performance > > Our cluster is consisting of about 60 Impala nodes. After a period of time > and after executing some "heavy" queries the performance of the cluster > becomes bad and the Impala is not responding after a period of time. We > observed that day after day the Impala Resident memory and the running > threads of the machine keep growing even if we do not run queries. Everytime > we perform an Impala restart everything seems to work fine for a period of > time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9784) Support uncorrelated scalar subqueries in HAVING
[ https://issues.apache.org/jira/browse/IMPALA-9784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152116#comment-17152116 ] ASF subversion and git services commented on IMPALA-9784: - Commit 2dca55695ef3c208ece543ad36bece2a985cf8da in impala's branch refs/heads/master from Shant Hovsepian [ https://gitbox.apache.org/repos/asf?p=impala.git;h=2dca556 ] IMPALA-9784, IMPALA-9905: Uncorrelated subqueries in HAVING. Support rewriting subqueries in the HAVING clause by nesting the aggregation query and pulling up the subquery predicates into the outer WHERE clause. Testing: * New analyzer tests * New functional subquery tests * Added Q23, Q24 and Q44 to the tpcds workload * Ran subquery rewrite tests Change-Id: I124a58a09a1a47e1222a22d84b54fe7d07844461 Reviewed-on: http://gerrit.cloudera.org:8080/16052 Tested-by: Impala Public Jenkins Reviewed-by: Tim Armstrong > Support uncorrelated scalar subqueries in HAVING > > > Key: IMPALA-9784 > URL: https://issues.apache.org/jira/browse/IMPALA-9784 > Project: IMPALA > Issue Type: Sub-task >Reporter: Shant Hovsepian >Assignee: Shant Hovsepian >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9905) Allow runtime scalar subquery check when group by clause is present
[
https://issues.apache.org/jira/browse/IMPALA-9905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152117#comment-17152117
]
ASF subversion and git services commented on IMPALA-9905:
-
Commit 2dca55695ef3c208ece543ad36bece2a985cf8da in impala's branch
refs/heads/master from Shant Hovsepian
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=2dca556 ]
IMPALA-9784, IMPALA-9905: Uncorrelated subqueries in HAVING.
Support rewriting subqueries in the HAVING clause by nesting the
aggregation query and pulling up the subquery predicates into the outer
WHERE clause.
Testing:
* New analyzer tests
* New functional subquery tests
* Added Q23, Q24 and Q44 to the tpcds workload
* Ran subquery rewrite tests
Change-Id: I124a58a09a1a47e1222a22d84b54fe7d07844461
Reviewed-on: http://gerrit.cloudera.org:8080/16052
Tested-by: Impala Public Jenkins
Reviewed-by: Tim Armstrong
> Allow runtime scalar subquery check when group by clause is present
> ---
>
> Key: IMPALA-9905
> URL: https://issues.apache.org/jira/browse/IMPALA-9905
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
>Reporter: Shant Hovsepian
>Assignee: Shant Hovsepian
>Priority: Minor
> Labels: planner, tpc-ds
>
> We can also use a runtime scalar subquery check for subqueries that have a
> scalar return type and also contain a grouping expression.
>
> For example the following query would pass a runtime scalar check, given the
> predicate on the grouping expression.
> {{select * from functional.alltypes where id < (select count(bool_col) from
> functional.alltypes where int_col=1 group by int_col);}}
>
> Ideally we could detect situation like the above at plan time and avoid the
> runtime scalar check all together with
> [IMPALA-1285|https://issues.apache.org/jira/browse/IMPALA-1285]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-8954) Support uncorrelated subqueries in the select list
[
https://issues.apache.org/jira/browse/IMPALA-8954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152115#comment-17152115
]
ASF subversion and git services commented on IMPALA-8954:
-
Commit 388ad555d7df9e2711ea0ab81dbae4235c54b3cc in impala's branch
refs/heads/master from Shant Hovsepian
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=388ad55 ]
IMPALA-8954: Uncorrelated scalar subqueries in the select list
Extend StmtRewriter with the ability to rewrite scalar subqueries in the
select list into cross joins. Currently the subquery must pass plan-time
checks to determine that it returns a single row which may miss cases
that may be valid at runtime or with more complex evaluation of the
predicate expressions in the planner. Support for correlated subqueries
will be a follow on change.
Testing:
* Added new analyzer tests, updated previous subquery tests
* test_queries.py::TestQueries::test_subquery
* Added test_tpcds_q9 to e2e and planner tests
Change-Id: Ibcf55d26889aa01d69bb85f18c9241dda095fb66
Reviewed-on: http://gerrit.cloudera.org:8080/16007
Reviewed-by: Tim Armstrong
Tested-by: Tim Armstrong
> Support uncorrelated subqueries in the select list
> --
>
> Key: IMPALA-8954
> URL: https://issues.apache.org/jira/browse/IMPALA-8954
> Project: IMPALA
> Issue Type: Sub-task
> Components: Frontend
>Affects Versions: Impala 3.3.0
>Reporter: Tim Armstrong
>Assignee: Shant Hovsepian
>Priority: Critical
> Labels: sql-language, tpc-ds
>
> {noformat}
> [localhost:21000] default> select 'foo', (select 'bar');
> Query: select 'foo', (select 'bar')
> Query submitted at: 2019-09-18 13:44:43 (Coordinator:
> http://tarmstrong-box:25000)
> ERROR: AnalysisException: Subqueries are not supported in the select list.
> {noformat}
> I think we can support these, implemented as a nested loop join with a
> cardinality check node if needed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9918) HdfsOrcScanner crash on resolving columns
[
https://issues.apache.org/jira/browse/IMPALA-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152111#comment-17152111
]
Csaba Ringhofer commented on IMPALA-9918:
-
I don't know yet what could lead to this issue. The following test failed with
the DCHECK:
18:58:30
custom_cluster/test_local_tz_conversion.py::TestLocalTzConversion::test_timestamp_functions[protocol:
beeswax | exec_option: {'batch_size': 0, 'num_nodes': 0,
'disable_codegen_rows_threshold': 0, 'disable_codegen': False,
'abort_on_error': 1, 'exec_single_node_rows_threshold': 0} | table_format:
text/none | enable_expr_rewrites: 1] FAILED
That tests reads a bit of ORC, but I don't know why it could break:
https://github.com/apache/impala/blob/master/testdata/workloads/functional-query/queries/QueryTest/file-formats-with-local-tz-conversion.test#L47
> HdfsOrcScanner crash on resolving columns
> -
>
> Key: IMPALA-9918
> URL: https://issues.apache.org/jira/browse/IMPALA-9918
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 4.0
> Environment: BUILD_TAG
> jenkins-impala-cdpd-master-core-ubsan-111
>Reporter: Wenzhe Zhou
>Assignee: Csaba Ringhofer
>Priority: Major
> Attachments: backtraces.txt
>
>
> Core file generated in impala-cdpd-master-core-ubsan build
> Back traces:
> CORE: ./tests/core.1594000709.13971.impalad
> BINARY: ./be/build/latest/service/impalad
> Core was generated by
> `/data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/build/lat'.
> Program terminated with signal SIGABRT, Aborted.
> #0 0x7f7a481851f7 in raise () from /lib64/libc.so.6
> To enable execution of this file add
> add-auto-load-safe-path
> /data0/jenkins/workspace/impala-cdpd-master-core-ubsan/Impala-Toolchain/gcc-4.9.2/lib64/libstdc++.so.6.0.20-gdb.py
> line to your configuration file "/var/lib/jenkins/.gdbinit".
> To completely disable this security protection add
> set auto-load safe-path /
> line to your configuration file "/var/lib/jenkins/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual. E.g., run from the shell:
> info "(gdb)Auto-loading safe path"
> #0 0x7f7a481851f7 in raise () from /lib64/libc.so.6
> #1 0x7f7a481868e8 in abort () from /lib64/libc.so.6
> #2 0x083401c4 in google::DumpStackTraceAndExit() ()
> #3 0x08336b5d in google::LogMessage::Fail() ()
> #4 0x08338402 in google::LogMessage::SendToLog() ()
> #5 0x08336537 in google::LogMessage::Flush() ()
> #6 0x08339afe in google::LogMessageFatal::~LogMessageFatal() ()
> #7 0x03215662 in impala::PrintPath (tbl_desc=..., path=...) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/util/debug-util.cc:259
> #8 0x0370dfe9 in impala::HdfsOrcScanner::ResolveColumns
> (this=0x14555c00, tuple_desc=..., selected_nodes=0x7f79722730a8,
> pos_slots=0x7f7972273058) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-orc-scanner.cc:436
> #9 0x037099dd in impala::HdfsOrcScanner::SelectColumns
> (this=0x14555c00, tuple_desc=...) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-orc-scanner.cc:456
> #10 0x03707688 in impala::HdfsOrcScanner::Open (this=0x14555c00,
> context=0x7f7972274700) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-orc-scanner.cc:221
> #11 0x035e0a48 in
> impala::HdfsScanNodeBase::CreateAndOpenScannerHelper (this=0x1b1c7100,
> partition=0x142f9d00, context=0x7f7972274700, scanner=0x7f79722746f8) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-scan-node-base.cc:882
> #12 0x039df2e8 in impala::HdfsScanNode::ProcessSplit
> (this=0x1b1c7100, filter_ctxs=..., expr_results_pool=0x7f7972274bd8,
> scan_range=0x12a16c40, scanner_thread_reservation=0x7f7972274e18) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-scan-node.cc:480
> #13 0x039ddd85 in impala::HdfsScanNode::ScannerThread
> (this=0x1b1c7100, first_thread=true, scanner_thread_reservation=8192) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-scan-node.cc:418
> #14 0x039e1980 in
> impala::HdfsScanNode::ThreadTokenAvailableCb(impala::ThreadResourcePool*)::$_0::operator()()
> const (this=0x7f7972275450) at
> /data/jenkins/workspace/impala-cdpd-master-core-ubsan/repos/Impala/be/src/exec/hdfs-scan-node.cc:339
> #15 0x039e13b2 in
> boost::detail::function::void_function_obj_invoker0 void>::invoke(boost::detail::function::function_buffer&)
> (function_obj_ptr=...) at
>
[jira] [Commented] (IMPALA-9919) Bad Impala Performance after a period of time
[ https://issues.apache.org/jira/browse/IMPALA-9919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152112#comment-17152112 ] Tim Armstrong commented on IMPALA-9919: --- IMPALA-6792 actually is probably contributing to the memory leak. > Bad Impala Performance after a period of time > - > > Key: IMPALA-9919 > URL: https://issues.apache.org/jira/browse/IMPALA-9919 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.10.0 > Environment: OS: CentOS 6.9 >Reporter: Vagelis Nomikos >Priority: Major > Labels: performance > > Our cluster is consisting of about 60 Impala nodes. After a period of time > and after executing some "heavy" queries the performance of the cluster > becomes bad and the Impala is not responding after a period of time. We > observed that day after day the Impala Resident memory and the running > threads of the machine keep growing even if we do not run queries. Everytime > we perform an Impala restart everything seems to work fine for a period of > time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-9919) Bad Impala Performance after a period of time
Vagelis Nomikos created IMPALA-9919: --- Summary: Bad Impala Performance after a period of time Key: IMPALA-9919 URL: https://issues.apache.org/jira/browse/IMPALA-9919 Project: IMPALA Issue Type: Bug Components: Backend Affects Versions: Impala 2.10.0 Environment: OS: CentOS 6.9 Reporter: Vagelis Nomikos Our cluster is consisting of about 60 Impala nodes. After a period of time and after executing some "heavy" queries the performance of the cluster becomes bad and the Impala is not responding after a period of time. We observed that day after day the Impala Resident memory and the running threads of the machine keep growing even if we do not run queries. Everytime we perform an Impala restart everything seems to work fine for a period of time. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9900) High rate log spam during FE tests
[
https://issues.apache.org/jira/browse/IMPALA-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152027#comment-17152027
]
Laszlo Gaal commented on IMPALA-9900:
-
Additionally, catalog.ERROR has the same exception barrage during exactly the
same time period.
> High rate log spam during FE tests
> --
>
> Key: IMPALA-9900
> URL: https://issues.apache.org/jira/browse/IMPALA-9900
> Project: IMPALA
> Issue Type: Bug
> Components: Frontend
>Affects Versions: Impala 4.0
>Reporter: Laszlo Gaal
>Priority: Critical
>
> During recent runs of the gerrit-verify-dryrun job FE tests exhibited a
> disturbing tendency: all impalad instances emitted almost 1 GB's worth of
> Java exception traces into their ERROR logfiles in a short, roughly 2 minute
> period. This bloats the archived logs pretty badly, because the contents of
> the ERROR log is replicated in the WARNING and in the INFO log as well,
> resulting in about 6 GB's of wasted space on the build server. This also
> makes it hard to extract meaningful information from those logs.
> The latest example is
> https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/11102/ (the build is
> currently locked to prevent it from being cleaned up); the affected files are
> archive/Impala/logs_static/logs/ee_tests/impalad{,node1,node2}.ERROR. The
> spam runs are present between log timestamps 21:05 to 21:07, the first error
> is
> {code}
> E0624 21:05:28.938853 19419 TransactionKeepalive.java:137] Unexpected
> exception thrown
> Java exception follows:
> java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError:
> org/apache/impala/common/TransactionKeepalive$HeartbeatContext
> at
> org.apache.impala.common.TransactionKeepalive$DaemonThread.run(TransactionKeepalive.java:114)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/impala/common/TransactionKeepalive$HeartbeatContext
> ... 2 more
> Caused by: java.lang.ClassNotFoundException:
> org.apache.impala.common.TransactionKeepalive$HeartbeatContext
> at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
> ... 2 more
> {code} then the repeated pattern is
> {code}
> E0624 21:05:28.939031 19419 TransactionKeepalive.java:137] Unexpected
> exception thrown
> Java exception follows:
> java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError:
> at
> org.apache.impala.common.TransactionKeepalive$DaemonThread.run(TransactionKeepalive.java:114)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: java.lang.NoClassDefFoundError:
> ... 2 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-9900) High rate log spam during FE tests
[
https://issues.apache.org/jira/browse/IMPALA-9900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152025#comment-17152025
]
Laszlo Gaal commented on IMPALA-9900:
-
Hi [~vihangk1], apologies from my side as well...
The only telltale sign I could find so far is that the impacted job is launched
with only FE, BE and JDBC test selected (in other words FE_TEST=true,
BE_TEST=true and JDBC_TEST=true); EE_TEST and CLUSTER_TEST are set to false
(deselected).
The other suspicious detail is that the log spam is constrained to a single
2-minute interval, which suggests that only a single test (or maybe a low
number of subsequent tests) is exhibiting this problem.
The latest occurrence is build #11191. Correlating the log spam timestamps with
the Jenkins console log for the build shows that the spam is happening during
JDBC_TEST:
This is from impalad_node2.ERROR
{code}
Impala/logs_static/logs/ee_tests $ head -50 impalad_node2.ERROR
Log file created at: 2020/07/01 21:45:06
Running on machine: ip-XXX-REDACTED-XXX
Log line format: [IWEF]mmdd hh:mm:ss.uu threadid file:line] msg
E0701 21:45:06.040009 16152 logging.cc:147] stderr will be logged to this file.
20/07/01 21:45:07 INFO util.JvmPauseMonitor: Starting JVM pause monitor
E0701 21:45:28.951961 17355 TransactionKeepalive.java:137] Unexpected exception
thrown
Java exception follows:
java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError:
org/apache/impala/common/TransactionKeepalive$HeartbeatContext
at
org.apache.impala.common.TransactionKeepalive$DaemonThread.run(TransactionKeepalive.java:114)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError:
org/apache/impala/common/TransactionKeepalive$HeartbeatContext
... 2 more
Caused by: java.lang.ClassNotFoundException:
org.apache.impala.common.TransactionKeepalive$HeartbeatContext
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
... 2 more
E0701 21:45:28.952263 17355 TransactionKeepalive.java:137] Unexpected exception
thrown
Java exception follows:
java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError:
at
org.apache.impala.common.TransactionKeepalive$DaemonThread.run(TransactionKeepalive.java:114)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError:
... 2 more
E0701 21:45:28.952461 17355 TransactionKeepalive.java:137] Unexpected exception
thrown
Java exception follows:
java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError:
at
org.apache.impala.common.TransactionKeepalive$DaemonThread.run(TransactionKeepalive.java:114)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError:
... 2 more
[...continues for another 2 minutes..]
E0701 21:47:18.512876 17367 TransactionKeepalive.java:137] Unexpected exception
thrown
Java exception follows:
java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError:
at
org.apache.impala.common.TransactionKeepalive$DaemonThread.run(TransactionKeepalive.java:114)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.NoClassDefFoundError:
... 2 more
{code}
Console log shows at the same time:
{code}
21:45:05 Starting Impala cluster OK (Took: 0 min 9 sec)
21:45:05 ~/Impala
21:45:05 21:45:05 MainThread: Found 0 impalad/0 statestored/0 catalogd
process(es)
21:45:05 21:45:05 MainThread: Starting State Store logging to
/home/ubuntu/Impala/logs/ee_tests/statestored.INFO
21:45:05 21:45:05 MainThread: Starting Catalog Service logging to
/home/ubuntu/Impala/logs/ee_tests/catalogd.INFO
21:45:06 21:45:06 MainThread: Starting Impala Daemon logging to
/home/ubuntu/Impala/logs/ee_tests/impalad.INFO
21:45:06 21:45:06 MainThread: Starting Impala Daemon logging to
/home/ubuntu/Impala/logs/ee_tests/impalad_node1.INFO
21:45:06 21:45:06 MainThread: Starting Impala Daemon logging to
/home/ubuntu/Impala/logs/ee_tests/impalad_node2.INFO
21:45:09 21:45:09 MainThread: Found 3 impalad/1 statestored/1 catalogd
process(es)
21:45:09 21:45:09 MainThread: Found 3 impalad/1 statestored/1 catalogd
process(es)
21:45:09 21:45:09 MainThread: Getting num_known_live_backends from
ip-172-31-62-150:25000
21:45:09 21:45:09 MainThread: Waiting for num_known_live_backends=3. Current
value: 0
21:45:10 21:45:10 MainThread: Found 3 impalad/1 statestored/1 catalogd
process(es)
21:45:10 21:45:10 MainThread: Getting num_known_live_backends from
ip-172-31-62-150:25000
21:45:10 21:45:10 MainThread: Waiting for num_known_live_backends=3. Current
value: 0
21:45:11 21:45:11 MainThread: Found 3 impalad/1 statestored/1 catalogd
process(es)
21:45:11 21:45:11 MainThread: Getting
