[jira] [Commented] (IMPALA-8584) Add support for cookie-based authentication
[ https://issues.apache.org/jira/browse/IMPALA-8584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939808#comment-16939808 ] Alexandra Rodoni commented on IMPALA-8584: -- [~twmarshall] Is this an user-facing feature that should be documented, for example, --max_cookie_lifetime_s? > Add support for cookie-based authentication > --- > > Key: IMPALA-8584 > URL: https://issues.apache.org/jira/browse/IMPALA-8584 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 3.3.0 >Reporter: Thomas Tauber-Marshall >Assignee: Thomas Tauber-Marshall >Priority: Critical > Fix For: Impala 3.4.0 > > > When IMPALA-8538 goes in, we'll have support for LDAP authentication over > http. The initial design will pass the credentials to LDAP for authentication > on every rpc. This has the potential to create a significant load on the LDAP > server. We can avoid hitting LDAP on every request by adding support for > cookie auth. -- 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-8913) Add query option for disabling HBase row estimation
[ https://issues.apache.org/jira/browse/IMPALA-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939790#comment-16939790 ] Alexandra Rodoni commented on IMPALA-8913: -- [~stiga-huang] Is this a user-facing query option that should be documented? > Add query option for disabling HBase row estimation > --- > > Key: IMPALA-8913 > URL: https://issues.apache.org/jira/browse/IMPALA-8913 > Project: IMPALA > Issue Type: New Feature >Reporter: Quanlong Huang >Assignee: Quanlong Huang >Priority: Major > Fix For: Impala 3.4.0 > > > IMPALA-8058 added a flag, disable_hbase_row_est, in the QueryCtx for tests to > bypass the codes of estimating HBase row stats from HBase RPCs and fall back > to HMS row count stats. > It's useful for point queries on high loaded HBase clusters, where we should > reduce the #RPCs to HBase. -- 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-8983) TestExecutorGroups.test_max_concurrent_queries seems flaky
Michael Ho created IMPALA-8983:
--
Summary: TestExecutorGroups.test_max_concurrent_queries seems flaky
Key: IMPALA-8983
URL: https://issues.apache.org/jira/browse/IMPALA-8983
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 3.4.0
Reporter: Michael Ho
Assignee: Lars Volker
It appears the test failed because an expected query admission failure didn't
happen. Happened once only so far.
{noformat}
Error Message
assert 'Initial admission queue reason: No query slot available on host' in
'Query (id=4a4773e2f93eff7f:754a96ed):\n DEBUG MODE WARNING: Query
profile created while running a DEBUG buil...0)\n -
NumRowsFetchedFromCache: 0 (0)\n - RowMaterializationRate: 0\n -
RowMaterializationTimer: 0.000ns\n'
Stacktrace
custom_cluster/test_executor_groups.py:212: in test_max_concurrent_queries
assert "Initial admission queue reason: No query slot available on host" in
profile
E assert 'Initial admission queue reason: No query slot available on host' in
'Query (id=4a4773e2f93eff7f:754a96ed):\n DEBUG MODE WARNING: Query
profile created while running a DEBUG buil...0)\n -
NumRowsFetchedFromCache: 0 (0)\n - RowMaterializationRate: 0\n -
RowMaterializationTimer: 0.000ns\n'
Standard Error
-- 2019-09-26 13:41:15,462 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/bin/start-impala-cluster.py
'--state_store_args=--statestore_update_frequency_ms=50
--statestore_priority_update_frequency_ms=50
--statestore_heartbeat_frequency_ms=50' --cluster_size=1 --num_coordinators=1
--log_dir=/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests
--log_level=1 --use_exclusive_coordinators '--impalad_args=
-executor_groups=coordinator ' --impalad_args=--default_query_options=
13:41:15 MainThread: Starting impala cluster without executors
13:41:16 MainThread: Found 0 impalad/0 statestored/0 catalogd process(es)
13:41:16 MainThread: Starting State Store logging to
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests/statestored.INFO
13:41:16 MainThread: Starting Catalog Service logging to
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
13:41:16 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests/impalad.INFO
13:41:19 MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
13:41:19 MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
13:41:19 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25000
13:41:19 MainThread: Debug webpage not yet available: ('Connection aborted.',
error(111, 'Connection refused'))
13:41:21 MainThread: Debug webpage did not become available in expected time.
13:41:21 MainThread: Waiting for num_known_live_backends=1. Current value: None
13:41:22 MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
13:41:22 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25000
13:41:22 MainThread: num_known_live_backends has reached value: 1
13:41:22 MainThread: Impala Cluster Running with 1 nodes (1 coordinators, 0
executors).
-- 2019-09-26 13:41:22,976 DEBUGMainThread: Found 1 impalad/1 statestored/1
catalogd process(es)
-- 2019-09-26 13:41:22,976 INFO MainThread: Getting metric:
statestore.live-backends from
impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25010
-- 2019-09-26 13:41:22,977 INFO MainThread: Starting new HTTP connection
(1): impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com
-- 2019-09-26 13:41:22,979 INFO MainThread: Metric
'statestore.live-backends' has reached desired value: 2
-- 2019-09-26 13:41:22,980 DEBUGMainThread: Getting num_known_live_backends
from impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25000
-- 2019-09-26 13:41:22,980 INFO MainThread: Starting new HTTP connection
(1): impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com
-- 2019-09-26 13:41:22,982 INFO MainThread: num_known_live_backends has
reached value: 1
SET
client_identifier=custom_cluster/test_executor_groups.py::TestExecutorGroups::()::test_max_concurrent_queries;
-- connecting to: localhost:21000
-- connecting to localhost:21050 with impyla
-- 2019-09-26 13:41:23,170 INFO MainThread: Closing active operation
-- 2019-09-26 13:41:23,172 INFO MainThread: Adding 2 executors to group
default-pool-group1 with minimum size 2
-- 2019-09-26 13:41:23,172 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/bin/start-impala-cluster.py
[jira] [Created] (IMPALA-8983) TestExecutorGroups.test_max_concurrent_queries seems flaky
Michael Ho created IMPALA-8983:
--
Summary: TestExecutorGroups.test_max_concurrent_queries seems flaky
Key: IMPALA-8983
URL: https://issues.apache.org/jira/browse/IMPALA-8983
Project: IMPALA
Issue Type: Bug
Components: Backend
Affects Versions: Impala 3.4.0
Reporter: Michael Ho
Assignee: Lars Volker
It appears the test failed because an expected query admission failure didn't
happen. Happened once only so far.
{noformat}
Error Message
assert 'Initial admission queue reason: No query slot available on host' in
'Query (id=4a4773e2f93eff7f:754a96ed):\n DEBUG MODE WARNING: Query
profile created while running a DEBUG buil...0)\n -
NumRowsFetchedFromCache: 0 (0)\n - RowMaterializationRate: 0\n -
RowMaterializationTimer: 0.000ns\n'
Stacktrace
custom_cluster/test_executor_groups.py:212: in test_max_concurrent_queries
assert "Initial admission queue reason: No query slot available on host" in
profile
E assert 'Initial admission queue reason: No query slot available on host' in
'Query (id=4a4773e2f93eff7f:754a96ed):\n DEBUG MODE WARNING: Query
profile created while running a DEBUG buil...0)\n -
NumRowsFetchedFromCache: 0 (0)\n - RowMaterializationRate: 0\n -
RowMaterializationTimer: 0.000ns\n'
Standard Error
-- 2019-09-26 13:41:15,462 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/bin/start-impala-cluster.py
'--state_store_args=--statestore_update_frequency_ms=50
--statestore_priority_update_frequency_ms=50
--statestore_heartbeat_frequency_ms=50' --cluster_size=1 --num_coordinators=1
--log_dir=/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests
--log_level=1 --use_exclusive_coordinators '--impalad_args=
-executor_groups=coordinator ' --impalad_args=--default_query_options=
13:41:15 MainThread: Starting impala cluster without executors
13:41:16 MainThread: Found 0 impalad/0 statestored/0 catalogd process(es)
13:41:16 MainThread: Starting State Store logging to
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests/statestored.INFO
13:41:16 MainThread: Starting Catalog Service logging to
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests/catalogd.INFO
13:41:16 MainThread: Starting Impala Daemon logging to
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/logs/custom_cluster_tests/impalad.INFO
13:41:19 MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
13:41:19 MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
13:41:19 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25000
13:41:19 MainThread: Debug webpage not yet available: ('Connection aborted.',
error(111, 'Connection refused'))
13:41:21 MainThread: Debug webpage did not become available in expected time.
13:41:21 MainThread: Waiting for num_known_live_backends=1. Current value: None
13:41:22 MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
13:41:22 MainThread: Getting num_known_live_backends from
impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25000
13:41:22 MainThread: num_known_live_backends has reached value: 1
13:41:22 MainThread: Impala Cluster Running with 1 nodes (1 coordinators, 0
executors).
-- 2019-09-26 13:41:22,976 DEBUGMainThread: Found 1 impalad/1 statestored/1
catalogd process(es)
-- 2019-09-26 13:41:22,976 INFO MainThread: Getting metric:
statestore.live-backends from
impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25010
-- 2019-09-26 13:41:22,977 INFO MainThread: Starting new HTTP connection
(1): impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com
-- 2019-09-26 13:41:22,979 INFO MainThread: Metric
'statestore.live-backends' has reached desired value: 2
-- 2019-09-26 13:41:22,980 DEBUGMainThread: Getting num_known_live_backends
from impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com:25000
-- 2019-09-26 13:41:22,980 INFO MainThread: Starting new HTTP connection
(1): impala-ec2-centos74-r4-4xlarge-ondemand-0593.vpc.cloudera.com
-- 2019-09-26 13:41:22,982 INFO MainThread: num_known_live_backends has
reached value: 1
SET
client_identifier=custom_cluster/test_executor_groups.py::TestExecutorGroups::()::test_max_concurrent_queries;
-- connecting to: localhost:21000
-- connecting to localhost:21050 with impyla
-- 2019-09-26 13:41:23,170 INFO MainThread: Closing active operation
-- 2019-09-26 13:41:23,172 INFO MainThread: Adding 2 executors to group
default-pool-group1 with minimum size 2
-- 2019-09-26 13:41:23,172 INFO MainThread: Starting cluster with command:
/data/jenkins/workspace/impala-cdh6.x-core-asan/repos/Impala/bin/start-impala-cluster.py
[jira] [Created] (IMPALA-8982) Fix webserver handling of OPTIONS
Thomas Tauber-Marshall created IMPALA-8982: -- Summary: Fix webserver handling of OPTIONS Key: IMPALA-8982 URL: https://issues.apache.org/jira/browse/IMPALA-8982 Project: IMPALA Issue Type: Bug Components: Clients Affects Versions: Impala 3.4.0 Reporter: Thomas Tauber-Marshall Assignee: Thomas Tauber-Marshall Currently, Impala's webserver always returns 500 errors to OPTIONS requests. This has already been fixed in squeasel: https://github.com/cloudera/squeasel/commit/5a6af3cdccc58bd0365eae96477c853143829449 We should pull in that commit -- 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-8982) Fix webserver handling of OPTIONS
Thomas Tauber-Marshall created IMPALA-8982: -- Summary: Fix webserver handling of OPTIONS Key: IMPALA-8982 URL: https://issues.apache.org/jira/browse/IMPALA-8982 Project: IMPALA Issue Type: Bug Components: Clients Affects Versions: Impala 3.4.0 Reporter: Thomas Tauber-Marshall Assignee: Thomas Tauber-Marshall Currently, Impala's webserver always returns 500 errors to OPTIONS requests. This has already been fixed in squeasel: https://github.com/cloudera/squeasel/commit/5a6af3cdccc58bd0365eae96477c853143829449 We should pull in that commit -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMPALA-8928) Add query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939764#comment-16939764 ] Bikramjeet Vig commented on IMPALA-8928: [~arodoni] there currently is not way to hide query options. These kind of options are usually added as "Development Query Options" which ideally should not be used by users > Add query option to only set the mem limit on executors > --- > > Key: IMPALA-8928 > URL: https://issues.apache.org/jira/browse/IMPALA-8928 > Project: IMPALA > Issue Type: Improvement >Affects Versions: Product Backlog >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Fix For: Impala 3.4.0 > > -- 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] [Closed] (IMPALA-8929) Impala Doc: Document the query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandra Rodoni closed IMPALA-8929. Resolution: Won't Do > Impala Doc: Document the query option to only set the mem limit on executors > > > Key: IMPALA-8929 > URL: https://issues.apache.org/jira/browse/IMPALA-8929 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alexandra Rodoni >Assignee: Alexandra Rodoni >Priority: Major > Labels: future_release_doc, in_34 > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IMPALA-8928) Add query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939750#comment-16939750 ] Alexandra Rodoni edited comment on IMPALA-8928 at 9/27/19 9:13 PM: --- [~bikramjeet.vig] Is there a way to completely hide this option when user runs "SET ALL;"? was (Author: arodoni_cloudera): Is there a way to completely hide this option when user runs "SET ALL;"? > Add query option to only set the mem limit on executors > --- > > Key: IMPALA-8928 > URL: https://issues.apache.org/jira/browse/IMPALA-8928 > Project: IMPALA > Issue Type: Improvement >Affects Versions: Product Backlog >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Fix For: Impala 3.4.0 > > -- 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] [Closed] (IMPALA-8929) Impala Doc: Document the query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexandra Rodoni closed IMPALA-8929. Resolution: Won't Do > Impala Doc: Document the query option to only set the mem limit on executors > > > Key: IMPALA-8929 > URL: https://issues.apache.org/jira/browse/IMPALA-8929 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alexandra Rodoni >Assignee: Alexandra Rodoni >Priority: Major > Labels: future_release_doc, in_34 > -- 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-8928) Add query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939750#comment-16939750 ] Alexandra Rodoni commented on IMPALA-8928: -- Is there a way to completely hide this option when user runs "SET ALL;"? > Add query option to only set the mem limit on executors > --- > > Key: IMPALA-8928 > URL: https://issues.apache.org/jira/browse/IMPALA-8928 > Project: IMPALA > Issue Type: Improvement >Affects Versions: Product Backlog >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Fix For: Impala 3.4.0 > > -- 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-8928) Add query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939743#comment-16939743 ] Bikramjeet Vig commented on IMPALA-8928: [~arodoni] its strictly for testing so we can skip documenting it. > Add query option to only set the mem limit on executors > --- > > Key: IMPALA-8928 > URL: https://issues.apache.org/jira/browse/IMPALA-8928 > Project: IMPALA > Issue Type: Improvement >Affects Versions: Product Backlog >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Fix For: Impala 3.4.0 > > -- 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-8981) Support column masking in Impala
[ https://issues.apache.org/jira/browse/IMPALA-8981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kurt Deschler reassigned IMPALA-8981: - Assignee: Kurt Deschler > Support column masking in Impala > > > Key: IMPALA-8981 > URL: https://issues.apache.org/jira/browse/IMPALA-8981 > Project: IMPALA > Issue Type: Bug >Affects Versions: Impala 3.4.0 >Reporter: Kurt Deschler >Assignee: Kurt Deschler >Priority: Major > > Related Hive Jira https://issues.apache.org/jira/browse/HIVE-13125 -- 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-8981) Support column masking in Impala
Kurt Deschler created IMPALA-8981: - Summary: Support column masking in Impala Key: IMPALA-8981 URL: https://issues.apache.org/jira/browse/IMPALA-8981 Project: IMPALA Issue Type: Bug Affects Versions: Impala 3.4.0 Reporter: Kurt Deschler Related Hive Jira https://issues.apache.org/jira/browse/HIVE-13125 -- 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-8981) Support column masking in Impala
Kurt Deschler created IMPALA-8981: - Summary: Support column masking in Impala Key: IMPALA-8981 URL: https://issues.apache.org/jira/browse/IMPALA-8981 Project: IMPALA Issue Type: Bug Affects Versions: Impala 3.4.0 Reporter: Kurt Deschler Related Hive Jira https://issues.apache.org/jira/browse/HIVE-13125 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IMPALA-8928) Add query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939731#comment-16939731 ] Alexandra Rodoni commented on IMPALA-8928: -- [~bikramjeet.vig] Is this option strictly for testing? Or can it be user-facing and should be documented? > Add query option to only set the mem limit on executors > --- > > Key: IMPALA-8928 > URL: https://issues.apache.org/jira/browse/IMPALA-8928 > Project: IMPALA > Issue Type: Improvement >Affects Versions: Product Backlog >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Fix For: Impala 3.4.0 > > -- 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-8979) Fail to obtain kudu toolchain
[ https://issues.apache.org/jira/browse/IMPALA-8979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939632#comment-16939632 ] Thomas Tauber-Marshall commented on IMPALA-8979: Looks like the value of IMPALA_KUDU_VERSION checked in to impala-config.sh got out of sync with the version in native-toolchain. Unfortunately this isn't a code path that gets tested very often as most people develop on ubuntu16, which doesn't use the toolchain Kudu. The version of Kudu that actually corresponds to toolchain id "51-03506fd053" is "84086fe", so you should be able to get around this by editing impala-config.sh and changing from "988296d" to "84086fe" I'll see about getting a new toolchain build to fix this > Fail to obtain kudu toolchain > - > > Key: IMPALA-8979 > URL: https://issues.apache.org/jira/browse/IMPALA-8979 > Project: IMPALA > Issue Type: Bug > Components: Infrastructure >Affects Versions: Impala 3.3.0 >Reporter: Donghui Xu >Priority: Major > > When I downloaded the tool chain using bootstrap_toolchain.py, the > acquisition of the kudu tool chain failed. The information is as follows: > https://native-toolchain.s3.amazonaws.com/build/51-03506fd053/kudu/988296d-gcc-4.9.2/kudu-988296d-gcc-4.9.2-ec2-package-centos-6.tar.gz > to > /media/B/impala/apache/Impala_compile/toolchain/kudu-988296d-gcc-4.9.2-ec2-package-centos-6.tar.gz) > Traceback (most recent call last): > File "bootstrap_toolchain.py", line 568, in > bootstrap(toolchain_root, packages) > File "bootstrap_toolchain.py", line 230, in bootstrap > execute_many(handle_package, packages) > File "bootstrap_toolchain.py", line 406, in execute_many > return pool.map(f, args, 1) > File "/usr/lib64/python2.7/multiprocessing/pool.py", line 251, in map > return self.map_async(func, iterable, chunksize).get() > File "/usr/lib64/python2.7/multiprocessing/pool.py", line 558, in get > raise self._value > Exception: Unable to find Kudu client lib under > '/media/B/impala/apache/Impala_compile/toolchain/kudu-988296d' -- 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-4057) Start webserver with interface"127.0.0.1" failed.
[
https://issues.apache.org/jira/browse/IMPALA-4057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16939618#comment-16939618
]
ASF subversion and git services commented on IMPALA-4057:
-
Commit 5645c4682a5efb8b7f9af32a46084af602e2e928 in impala's branch
refs/heads/master from Thomas Tauber-Marshall
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=5645c46 ]
Fix --webserver_interface for remote cluster tests
IMPALA-4057 updated our test infrastructure to allow setting the flag
--webserver_interface. In some cases, that patch used a default value
of '127.0.0.1', which works for running the tests against the local
minicluster but fails when the tests are run against a remote cluster.
This patch fixes this by removing the use of '127.0.0.1' and replacing
it with the specified hostname.
Change-Id: Ic5b8adefe4e2bb8f7013d9af70fd3e5dfd7ee18f
Reviewed-on: http://gerrit.cloudera.org:8080/14313
Tested-by: Impala Public Jenkins
Reviewed-by: Joe McDonnell
> Start webserver with interface"127.0.0.1" failed.
> -
>
> Key: IMPALA-4057
> URL: https://issues.apache.org/jira/browse/IMPALA-4057
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 2.7.0
> Environment: bash-4.1$ lsb_release -a
> LSB Version:
> :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
> Distributor ID: CentOS
> Description: CentOS release 6.7 (Final)
> Release: 6.7
> Codename: Final
> bash-4.1$
>Reporter: hewenting
>Assignee: Thomas Tauber-Marshall
>Priority: Trivial
> Labels: impala, webserver
> Fix For: Impala 3.4.0
>
>
> Start impala with option -websever_interface=127.0.0.1 failed.
> log displayed on terminal:
> {noformat}
> bash-4.1$ ./bin/start-impala-cluster.py -s 1 --impalad_args
> "-webserver_interface=127.0.0.1"
> Starting State Store logging to
> /home/impala/incubator-impala/logs/cluster/statestored.INFO
> Starting Catalog Service logging to
> /home/impala/incubator-impala/logs/cluster/catalogd.INFO
> Starting Impala Daemon logging to
> /home/impala/incubator-impala/logs/cluster/impalad.INFO
> MainThread: Found 1 impalad/1 statestored/1 catalogd process(es)
> MainThread: Getting num_known_live_backends from nobida141:25000
> MainThread: Debug webpage not yet available.
> ...
> MainThread: Debug webpage not yet available.
> MainThread: Debug webpage did not become available in expected time.
> MainThread: Waiting for num_known_live_backends=1. Current value: None
> Error starting cluster: num_known_live_backends did not reach expected value
> in time
> {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] [Resolved] (IMPALA-8928) Add query option to only set the mem limit on executors
[ https://issues.apache.org/jira/browse/IMPALA-8928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikramjeet Vig resolved IMPALA-8928. Fix Version/s: Impala 3.4.0 Resolution: Fixed > Add query option to only set the mem limit on executors > --- > > Key: IMPALA-8928 > URL: https://issues.apache.org/jira/browse/IMPALA-8928 > Project: IMPALA > Issue Type: Improvement >Affects Versions: Product Backlog >Reporter: Bikramjeet Vig >Assignee: Bikramjeet Vig >Priority: Major > Fix For: Impala 3.4.0 > > -- 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-8533) Impala daemon crash on sort
[ https://issues.apache.org/jira/browse/IMPALA-8533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kurt Deschler reassigned IMPALA-8533: - Assignee: Kurt Deschler (was: Todd Lipcon) > Impala daemon crash on sort > --- > > Key: IMPALA-8533 > URL: https://issues.apache.org/jira/browse/IMPALA-8533 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 3.2.0 >Reporter: Jacob Evan Beard >Assignee: Kurt Deschler >Priority: Blocker > Labels: crash > Attachments: fatal_error.txt, hs_err_pid8552.log, query.txt > > > Running the attached data generation query crashes the Impala coordinator > daemon. -- 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-8980) Remove functional*.alltypesinsert from EE tests
[ https://issues.apache.org/jira/browse/IMPALA-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Csaba Ringhofer updated IMPALA-8980: Description: Table alltypesinsert is/was used to test insert queries. In EE tests this means that such tests have to cleanup the table to avoid side effects + has to be marked as serial. Using the newer approach of unique_database would allow these tests to be ran in parallel. The FE tests that use alltypesinsert do not seem problematic to me, as those do not have side effects, so I wouldn't remove alltypesinsert from data load to avoid the need to update FE tests too. was: Table alltypesinsert is/was used to test insert queries. In EE tests this meant that such tests have to cleanup the table to avoid side effects + has to be marked as serial. Using the newer approach of unique_database would allow these tests to be ran in parallel. The FE tests that use alltypesinsert do not seem problematic to me, as those do not have side effects, so I wouldn't remove alltypesinsert from data load to avoid the need to update FE tests too. > Remove functional*.alltypesinsert from EE tests > --- > > Key: IMPALA-8980 > URL: https://issues.apache.org/jira/browse/IMPALA-8980 > Project: IMPALA > Issue Type: Improvement > Components: Infrastructure >Reporter: Csaba Ringhofer >Priority: Minor > Labels: ramp-up > > Table alltypesinsert is/was used to test insert queries. In EE tests this > means that such tests have to cleanup the table to avoid side effects + has > to be marked as serial. Using the newer approach of unique_database would > allow these tests to be ran in parallel. > The FE tests that use alltypesinsert do not seem problematic to me, as those > do not have side effects, so I wouldn't remove alltypesinsert from data load > to avoid the need to update FE tests too. -- 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-8980) Remove functional*.alltypesinsert from EE tests
[ https://issues.apache.org/jira/browse/IMPALA-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Csaba Ringhofer updated IMPALA-8980: Labels: ramp-up (was: ) > Remove functional*.alltypesinsert from EE tests > --- > > Key: IMPALA-8980 > URL: https://issues.apache.org/jira/browse/IMPALA-8980 > Project: IMPALA > Issue Type: Improvement > Components: Infrastructure >Reporter: Csaba Ringhofer >Priority: Minor > Labels: ramp-up > > Table alltypesinsert is/was used to test insert queries. In EE tests this > meant that such tests have to cleanup the table to avoid side effects + has > to be marked as serial. Using the newer approach of unique_database would > allow these tests to be ran in parallel. > The FE tests that use alltypesinsert do not seem problematic to me, as those > do not have side effects, so I wouldn't remove alltypesinsert from data load > to avoid the need to update FE tests too. -- 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-8980) Remove functional*.alltypesinsert from EE tests
Csaba Ringhofer created IMPALA-8980: --- Summary: Remove functional*.alltypesinsert from EE tests Key: IMPALA-8980 URL: https://issues.apache.org/jira/browse/IMPALA-8980 Project: IMPALA Issue Type: Improvement Components: Infrastructure Reporter: Csaba Ringhofer Table alltypesinsert is/was used to test insert queries. In EE tests this meant that such tests have to cleanup the table to avoid side effects + has to be marked as serial. Using the newer approach of unique_database would allow these tests to be ran in parallel. The FE tests that use alltypesinsert do not seem problematic to me, as those do not have side effects, so I wouldn't remove alltypesinsert from data load to avoid the need to update FE tests too. -- 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-7087) Impala is unable to read Parquet decimal columns with lower precision/scale than table metadata
[
https://issues.apache.org/jira/browse/IMPALA-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yongzhi Chen reassigned IMPALA-7087:
Assignee: Yongzhi Chen (was: Sahil Takiar)
> Impala is unable to read Parquet decimal columns with lower precision/scale
> than table metadata
> ---
>
> Key: IMPALA-7087
> URL: https://issues.apache.org/jira/browse/IMPALA-7087
> Project: IMPALA
> Issue Type: Sub-task
> Components: Backend
>Reporter: Tim Armstrong
>Assignee: Yongzhi Chen
>Priority: Major
> Labels: decimal, parquet
>
> This is similar to IMPALA-2515, except relates to a different precision/scale
> in the file metadata rather than just a mismatch in the bytes used to store
> the data. In a lot of cases we should be able to convert the decimal type on
> the fly to the higher-precision type.
> {noformat}
> ERROR: File '/hdfs/path/00_0_x_2' column 'alterd_decimal' has an invalid
> type length. Expecting: 11 len in file: 8
> {noformat}
> It would be convenient to allow reading parquet files where the
> precision/scale in the file can be converted to the precision/scale in the
> table metadata without loss of precision.
--
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-8979) Fail to obtain kudu toolchain
Donghui Xu created IMPALA-8979: -- Summary: Fail to obtain kudu toolchain Key: IMPALA-8979 URL: https://issues.apache.org/jira/browse/IMPALA-8979 Project: IMPALA Issue Type: Bug Components: Infrastructure Affects Versions: Impala 3.3.0 Reporter: Donghui Xu When I downloaded the tool chain using bootstrap_toolchain.py, the acquisition of the kudu tool chain failed. The information is as follows: https://native-toolchain.s3.amazonaws.com/build/51-03506fd053/kudu/988296d-gcc-4.9.2/kudu-988296d-gcc-4.9.2-ec2-package-centos-6.tar.gz to /media/B/impala/apache/Impala_compile/toolchain/kudu-988296d-gcc-4.9.2-ec2-package-centos-6.tar.gz) Traceback (most recent call last): File "bootstrap_toolchain.py", line 568, in bootstrap(toolchain_root, packages) File "bootstrap_toolchain.py", line 230, in bootstrap execute_many(handle_package, packages) File "bootstrap_toolchain.py", line 406, in execute_many return pool.map(f, args, 1) File "/usr/lib64/python2.7/multiprocessing/pool.py", line 251, in map return self.map_async(func, iterable, chunksize).get() File "/usr/lib64/python2.7/multiprocessing/pool.py", line 558, in get raise self._value Exception: Unable to find Kudu client lib under '/media/B/impala/apache/Impala_compile/toolchain/kudu-988296d' -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IMPALA-8979) Fail to obtain kudu toolchain
Donghui Xu created IMPALA-8979: -- Summary: Fail to obtain kudu toolchain Key: IMPALA-8979 URL: https://issues.apache.org/jira/browse/IMPALA-8979 Project: IMPALA Issue Type: Bug Components: Infrastructure Affects Versions: Impala 3.3.0 Reporter: Donghui Xu When I downloaded the tool chain using bootstrap_toolchain.py, the acquisition of the kudu tool chain failed. The information is as follows: https://native-toolchain.s3.amazonaws.com/build/51-03506fd053/kudu/988296d-gcc-4.9.2/kudu-988296d-gcc-4.9.2-ec2-package-centos-6.tar.gz to /media/B/impala/apache/Impala_compile/toolchain/kudu-988296d-gcc-4.9.2-ec2-package-centos-6.tar.gz) Traceback (most recent call last): File "bootstrap_toolchain.py", line 568, in bootstrap(toolchain_root, packages) File "bootstrap_toolchain.py", line 230, in bootstrap execute_many(handle_package, packages) File "bootstrap_toolchain.py", line 406, in execute_many return pool.map(f, args, 1) File "/usr/lib64/python2.7/multiprocessing/pool.py", line 251, in map return self.map_async(func, iterable, chunksize).get() File "/usr/lib64/python2.7/multiprocessing/pool.py", line 558, in get raise self._value Exception: Unable to find Kudu client lib under '/media/B/impala/apache/Impala_compile/toolchain/kudu-988296d' -- 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
