[jira] [Assigned] (IMPALA-12754) Update Impala document to cover external jdbc table
[ https://issues.apache.org/jira/browse/IMPALA-12754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-12754: --- Assignee: Jankiram Balakrishnan (was: gaurav singh) > Update Impala document to cover external jdbc table > --- > > Key: IMPALA-12754 > URL: https://issues.apache.org/jira/browse/IMPALA-12754 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Wenzhe Zhou >Assignee: Jankiram Balakrishnan >Priority: Major > > We need to document the SQL syntax to create external JDBC table and alter > external JDBC table, including the table properties to be set for JDBC and > DBCP (Database Connection Pool). > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-13015) Dataload fails due to concurrency issue with test.jceks
[
https://issues.apache.org/jira/browse/IMPALA-13015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat resolved IMPALA-13015.
-
Target Version: Impala 4.4.0
Resolution: Fixed
> Dataload fails due to concurrency issue with test.jceks
> ---
>
> Key: IMPALA-13015
> URL: https://issues.apache.org/jira/browse/IMPALA-13015
> Project: IMPALA
> Issue Type: Bug
> Components: Infrastructure
>Affects Versions: Impala 4.4.0
>Reporter: Joe McDonnell
>Assignee: Abhishek Rawat
>Priority: Major
> Labels: flaky
>
> When doing dataload locally, it fails with this error:
> {noformat}
> Traceback (most recent call last):
> File "/home/joemcdonnell/upstream/Impala/bin/load-data.py", line 523, in
>
> if __name__ == "__main__": main()
> File "/home/joemcdonnell/upstream/Impala/bin/load-data.py", line 322, in
> main
> os.remove(jceks_path)
> OSError: [Errno 2] No such file or directory:
> '/home/joemcdonnell/upstream/Impala/testdata/jceks/test.jceks'
> Background task Loading functional-query data (pid 501094) failed.
> {noformat}
> testdata/bin/create-load-data.sh calls bin/load-data.py for functional,
> TPC-H, and TPC-DS in parallel, so this logic has race conditions:
> {noformat}
> jceks_path = TESTDATA_JCEKS_DIR + "/test.jceks"
> if os.path.exists(jceks_path):
> os.remove(jceks_path){noformat}
> I don't see a specific reason for this to be in bin/load-data.py. It should
> be moved somewhere else that doesn't run in parallel. One possible location
> is to add a step in testdata/bin/create-load-data.sh
> This was introduced in
> [https://github.com/apache/impala/commit/9837637d9342a49288a13a421d4e749818da1432]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-13030) Document ai_generate_text built-in function
[ https://issues.apache.org/jira/browse/IMPALA-13030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-13030: Epic Link: IMPALA-12919 > Document ai_generate_text built-in function > --- > > Key: IMPALA-13030 > URL: https://issues.apache.org/jira/browse/IMPALA-13030 > Project: IMPALA > Issue Type: Documentation >Reporter: Abhishek Rawat >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-13030) Document ai_generate_text built-in function
Abhishek Rawat created IMPALA-13030: --- Summary: Document ai_generate_text built-in function Key: IMPALA-13030 URL: https://issues.apache.org/jira/browse/IMPALA-13030 Project: IMPALA Issue Type: Documentation Reporter: Abhishek Rawat -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-13024) Several tests timeout waiting for admission
[
https://issues.apache.org/jira/browse/IMPALA-13024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17839247#comment-17839247
]
Abhishek Rawat commented on IMPALA-13024:
-
Slot based admission is not enabled when using default groups - IMPALA-8757.
`test_queue_reasons_slots` has executor_groups="default-pool-group1" set so
slots based admission is enabled. I couldn't say the same about the other one.
CC [~rizaon]
> Several tests timeout waiting for admission
> ---
>
> Key: IMPALA-13024
> URL: https://issues.apache.org/jira/browse/IMPALA-13024
> Project: IMPALA
> Issue Type: Bug
>Reporter: Csaba Ringhofer
>Priority: Critical
>
> A bunch of seemingly unrelated tests failed with the following message:
> Example:
> query_test.test_spilling.TestSpillingDebugActionDimensions.test_spilling_aggs[protocol:
> beeswax | exec_option: {'mt_dop': 1, 'debug_action': None,
> 'default_spillable_buffer_size': '256k'} | table_format: parquet/none]
> {code}
> ImpalaBeeswaxException: EQuery aborted:Admission for query exceeded
> timeout 6ms in pool default-pool. Queued reason: Not enough admission
> control slots available on host ... . Needed 1 slots but 18/16 are already in
> use. Additional Details: Not Applicable
> {code}
> This happened in an ASAN build. Another test also failed which may be related
> to the cause:
> custom_cluster.test_admission_controller.TestAdmissionController.test_queue_reasons_slots
>
> {code}
> Timeout: query 'e1410add778cd7b0:c40812b9' did not reach one of the
> expected states [4], last known state 5
> {code}
> test_queue_reasons_slots seems to be know flaky test: IMPALA-10338
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12874) Identify Catalog HA and StateStore HA from the web debug endpoint
[
https://issues.apache.org/jira/browse/IMPALA-12874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat reassigned IMPALA-12874:
---
Assignee: Yida Wu (was: gaurav singh)
> Identify Catalog HA and StateStore HA from the web debug endpoint
> -
>
> Key: IMPALA-12874
> URL: https://issues.apache.org/jira/browse/IMPALA-12874
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: gaurav singh
>Assignee: Yida Wu
>Priority: Major
>
> Identify which Catalog and Statestore instance is active from the web debug
> endpoint.
> For the HA, we should improve the label on catalog and statestore web
> response to indicate "Active" instance.
> On the main page we could indicate "Status: Active" or "Status: Stand-by". We
> could probably add the status at the top of the main page before *"Version"*
> . The current details as output of a curl request on port 25020:
> {code:java}
> Version
> catalogd version 4.0.0.2024.0.18.0-61 RELEASE (build
> 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> ..
> {code}
> Corresponding curl request on statestored on 25010:
> {code:java}
> Version
> statestored version 4.0.0.2024.0.18.0-61 RELEASE
> (build 82901f3f83fa4c25b318ebf825a1505d89209356)
> Built on Fri Mar 1 20:13:09 UTC 2024
> Build Flags: is_ndebug=true cmake_build_type=RELEASE
> library_link_type=STATIC
>
> Process Start Time
> {code}
> Catalogd active status can be figured out using the catalogd metric:
> "catalog-server.active-status"
> Statestored active status we probably don't have a metric so should add a
> similar metric and use that to determine status.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-12920) Support ai_generate_text built-in function for OpenAI's LLMs
[ https://issues.apache.org/jira/browse/IMPALA-12920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat resolved IMPALA-12920. - Fix Version/s: Impala 4.4.0 Resolution: Fixed > Support ai_generate_text built-in function for OpenAI's LLMs > > > Key: IMPALA-12920 > URL: https://issues.apache.org/jira/browse/IMPALA-12920 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > Fix For: Impala 4.4.0 > > > Built in function which can help communicate with [OpenAi's chat completion > API|https://platform.openai.com/docs/api-reference/chat] endpoint through SQL. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12920) Support ai_generate_text built-in function for OpenAI's LLMs
[ https://issues.apache.org/jira/browse/IMPALA-12920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-12920: --- Assignee: Abhishek Rawat > Support ai_generate_text built-in function for OpenAI's LLMs > > > Key: IMPALA-12920 > URL: https://issues.apache.org/jira/browse/IMPALA-12920 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > Built in function which can help communicate with [OpenAi's chat completion > API|https://platform.openai.com/docs/api-reference/chat] endpoint through SQL. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12920) Support ai_generate_text built-in function for OpenAI's LLMs
Abhishek Rawat created IMPALA-12920: --- Summary: Support ai_generate_text built-in function for OpenAI's LLMs Key: IMPALA-12920 URL: https://issues.apache.org/jira/browse/IMPALA-12920 Project: IMPALA Issue Type: Task Reporter: Abhishek Rawat Built in function which can help communicate with [OpenAi's chat completion API|https://platform.openai.com/docs/api-reference/chat] endpoint through SQL. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12919) Support communication with external AI engines
Abhishek Rawat created IMPALA-12919: --- Summary: Support communication with external AI engines Key: IMPALA-12919 URL: https://issues.apache.org/jira/browse/IMPALA-12919 Project: IMPALA Issue Type: Epic Reporter: Abhishek Rawat Add the ability to query LLMs from Impala. Users will be able to create a UDFs or built-in functions that sends a prompt to an LLM and receives a response (assuming they have an API key for the LLM), enabling them to integrate LLM intelligence into their Impala workflow (could be used for data generation, data transformation, text-to-SQL, data editing, data summarization, and much more). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12868) Catalogd's statestore subscriber gets stuck in a loop trying to process UpdateCatalogd RPC
[
https://issues.apache.org/jira/browse/IMPALA-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12868:
Description:
When Impala is running with statestore HA and catalog HA enabled, the below
log statement in both catalogd instances is printed about 9 times each second:
{code:java}
I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
catalogd message from unknown or inactive statestored:
f4439d6fdb0ec572:87102dd6c845dab7{code}
On restarting catalogDs, the log statements are not observed.
STR:
# Create Impala with both catalogD HA and statestoreD HA
# Check catalogD container logs
was:
When Impala is running with statestore HA and catalog HA enabled, the below
log statement in both catalogd instances is printed about 9 times each second:
{code:java}
I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
catalogd message from unknown or inactive statestored:
f4439d6fdb0ec572:87102dd6c845dab7{code}
On restarting catalogD, the log statements are not observed.
STR:
# Create Impala with both catalogD HA and statestoreD HA
# Check catalogD container logs
> Catalogd's statestore subscriber gets stuck in a loop trying to process
> UpdateCatalogd RPC
> --
>
> Key: IMPALA-12868
> URL: https://issues.apache.org/jira/browse/IMPALA-12868
> Project: IMPALA
> Issue Type: Task
>Reporter: Anubhav Jindal
>Priority: Critical
> Attachments: Screenshot 2024-03-04 at 3.21.55 PM.png
>
>
> When Impala is running with statestore HA and catalog HA enabled, the below
> log statement in both catalogd instances is printed about 9 times each second:
> {code:java}
> I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
> catalogd message from unknown or inactive statestored:
> f4439d6fdb0ec572:87102dd6c845dab7{code}
> On restarting catalogDs, the log statements are not observed.
> STR:
> # Create Impala with both catalogD HA and statestoreD HA
> # Check catalogD container logs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12868) Catalogd's statestore subscriber gets stuck in a loop trying to process UpdateCatalogd RPC
[
https://issues.apache.org/jira/browse/IMPALA-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12868:
Description:
When Impala is running with statestore HA and catalog HA enabled, the below
log statement in both catalogd instances is printed about 9 times each second:
{code:java}
I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
catalogd message from unknown or inactive statestored:
f4439d6fdb0ec572:87102dd6c845dab7{code}
On restarting catalogD, the log statements are not observed.
STR:
# Create Impala with both catalogD HA and statestoreD HA
# Check catalogD container logs
was:
When Impala is running with statestore HA enabled, the below log statement in
catalogd is printed about 9 times each second:
{code:java}
I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
catalogd message from unknown or inactive statestored:
f4439d6fdb0ec572:87102dd6c845dab7{code}
On restarting catalogD, the log statements are not observed.
STR:
# Create Impala with both catalogD HA and statestoreD HA
# Check catalogD container logs
> Catalogd's statestore subscriber gets stuck in a loop trying to process
> UpdateCatalogd RPC
> --
>
> Key: IMPALA-12868
> URL: https://issues.apache.org/jira/browse/IMPALA-12868
> Project: IMPALA
> Issue Type: Task
>Reporter: Anubhav Jindal
>Priority: Critical
> Attachments: Screenshot 2024-03-04 at 3.21.55 PM.png
>
>
> When Impala is running with statestore HA and catalog HA enabled, the below
> log statement in both catalogd instances is printed about 9 times each second:
> {code:java}
> I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
> catalogd message from unknown or inactive statestored:
> f4439d6fdb0ec572:87102dd6c845dab7{code}
> On restarting catalogD, the log statements are not observed.
> STR:
> # Create Impala with both catalogD HA and statestoreD HA
> # Check catalogD container logs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12868) Catalogd's statestore subscriber gets stuck in a loop trying to process UpdateCatalogd RPC
[
https://issues.apache.org/jira/browse/IMPALA-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12868:
Description:
When Impala is running with statestore HA enabled, the below log statement in
catalogd is printed about 9 times each second:
{code:java}
I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
catalogd message from unknown or inactive statestored:
f4439d6fdb0ec572:87102dd6c845dab7{code}
On restarting catalogD, the log statements are not observed.
STR:
# Create Impala with both catalogD HA and statestoreD HA
# Check catalogD container logs
was:
When Impala is running with statestore HA enabled, the below log statement in
catalogd is printed about 9 times each second:
{code:java}
I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
catalogd message from unknown or inactive statestored:
f4439d6fdb0ec572:87102dd6c845dab7{code}
The log level should be updated to reduce spamming at the default log level.
On restarting catalogD, the log statements are not observed.
STR:
# Create Impala with both catalogD HA and statestoreD HA
# Check catalogD container logs
> Catalogd's statestore subscriber gets stuck in a loop trying to process
> UpdateCatalogd RPC
> --
>
> Key: IMPALA-12868
> URL: https://issues.apache.org/jira/browse/IMPALA-12868
> Project: IMPALA
> Issue Type: Task
>Reporter: Anubhav Jindal
>Priority: Major
> Attachments: Screenshot 2024-03-04 at 3.21.55 PM.png
>
>
> When Impala is running with statestore HA enabled, the below log statement in
> catalogd is printed about 9 times each second:
> {code:java}
> I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
> catalogd message from unknown or inactive statestored:
> f4439d6fdb0ec572:87102dd6c845dab7{code}
> On restarting catalogD, the log statements are not observed.
> STR:
> # Create Impala with both catalogD HA and statestoreD HA
> # Check catalogD container logs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12868) Catalogd's statestore subscriber gets stuck in a loop trying to process UpdateCatalogd RPC
[
https://issues.apache.org/jira/browse/IMPALA-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12868:
Priority: Critical (was: Major)
> Catalogd's statestore subscriber gets stuck in a loop trying to process
> UpdateCatalogd RPC
> --
>
> Key: IMPALA-12868
> URL: https://issues.apache.org/jira/browse/IMPALA-12868
> Project: IMPALA
> Issue Type: Task
>Reporter: Anubhav Jindal
>Priority: Critical
> Attachments: Screenshot 2024-03-04 at 3.21.55 PM.png
>
>
> When Impala is running with statestore HA enabled, the below log statement in
> catalogd is printed about 9 times each second:
> {code:java}
> I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
> catalogd message from unknown or inactive statestored:
> f4439d6fdb0ec572:87102dd6c845dab7{code}
> On restarting catalogD, the log statements are not observed.
> STR:
> # Create Impala with both catalogD HA and statestoreD HA
> # Check catalogD container logs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12868) Catalogd's statestore subscriber gets stuck in a loop trying to process UpdateCatalogd RPC
[
https://issues.apache.org/jira/browse/IMPALA-12868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12868:
Summary: Catalogd's statestore subscriber gets stuck in a loop trying to
process UpdateCatalogd RPC (was: Change log level for a statement in catalogd
pertaining to statestore HA)
> Catalogd's statestore subscriber gets stuck in a loop trying to process
> UpdateCatalogd RPC
> --
>
> Key: IMPALA-12868
> URL: https://issues.apache.org/jira/browse/IMPALA-12868
> Project: IMPALA
> Issue Type: Task
>Reporter: Anubhav Jindal
>Priority: Major
> Attachments: Screenshot 2024-03-04 at 3.21.55 PM.png
>
>
> When Impala is running with statestore HA enabled, the below log statement in
> catalogd is printed about 9 times each second:
> {code:java}
> I0304 22:27:28.446938 289 statestore-subscriber.cc:421] Skipped updating
> catalogd message from unknown or inactive statestored:
> f4439d6fdb0ec572:87102dd6c845dab7{code}
> The log level should be updated to reduce spamming at the default log level.
> On restarting catalogD, the log statements are not observed.
> STR:
> # Create Impala with both catalogD HA and statestoreD HA
> # Check catalogD container logs
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12418) Include crypto functions supported by Hive
[ https://issues.apache.org/jira/browse/IMPALA-12418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12418: Priority: Critical (was: Major) > Include crypto functions supported by Hive > -- > > Key: IMPALA-12418 > URL: https://issues.apache.org/jira/browse/IMPALA-12418 > Project: IMPALA > Issue Type: New Feature >Reporter: Pranav Yogi Lodha >Assignee: Pranav Yogi Lodha >Priority: Critical > > To be in line with Hive, Impala should support: > aes_encrypt and aes_decrypt > See: > [https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-Misc.Functions] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12559) Support x5c Parameter in JSON Web Keys (JWK)
[ https://issues.apache.org/jira/browse/IMPALA-12559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12559: Priority: Critical (was: Major) > Support x5c Parameter in JSON Web Keys (JWK) > > > Key: IMPALA-12559 > URL: https://issues.apache.org/jira/browse/IMPALA-12559 > Project: IMPALA > Issue Type: New Feature > Components: be, Security >Reporter: Jason Fehr >Priority: Critical > Labels: JWT, jwt, security > > The ["x5c" > parameter|https://datatracker.ietf.org/doc/html/rfc7517#section-4.7] in JWKs > is not supported by Impala. Implement support for this parameter using the > available methods in the [Thalhammer/jwt-cpp > library|https://github.com/Thalhammer/jwt-cpp/blob/ce1f9df3a9f861d136d6f0c93a6f811c364d1d3d/example/jwks-verify.cpp]. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12761) impala-shell: --show_profiles should return the query profile for failed queries also
Abhishek Rawat created IMPALA-12761: --- Summary: impala-shell: --show_profiles should return the query profile for failed queries also Key: IMPALA-12761 URL: https://issues.apache.org/jira/browse/IMPALA-12761 Project: IMPALA Issue Type: Improvement Components: Clients Reporter: Abhishek Rawat The `–show_profiles` option returns query profile at the end of a query execution, but only if the query was successful. It will be useful to also return query profile for the failed query for debugging. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12461) Avoid write lock on the table during self-event detection
[
https://issues.apache.org/jira/browse/IMPALA-12461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12461:
Priority: Critical (was: Major)
> Avoid write lock on the table during self-event detection
> -
>
> Key: IMPALA-12461
> URL: https://issues.apache.org/jira/browse/IMPALA-12461
> Project: IMPALA
> Issue Type: Improvement
> Components: Catalog
>Reporter: Csaba Ringhofer
>Assignee: Csaba Ringhofer
>Priority: Critical
>
> Saw some callstacks like this:
> {code}
> at
> org.apache.impala.catalog.CatalogServiceCatalog.tryLock(CatalogServiceCatalog.java:468)
> at
> org.apache.impala.catalog.CatalogServiceCatalog.tryWriteLock(CatalogServiceCatalog.java:436)
> at
> org.apache.impala.catalog.CatalogServiceCatalog.evaluateSelfEvent(CatalogServiceCatalog.java:1008)
> at
> org.apache.impala.catalog.events.MetastoreEvents$MetastoreEvent.isSelfEvent(MetastoreEvents.java:609)
> at
> org.apache.impala.catalog.events.MetastoreEvents$BatchPartitionEvent.process(MetastoreEvents.java:1942)
> {code}
> At this point it was already checked that the event comes from Impala based
> on service id and now we are checking the table's self event list. Taking the
> table lock can be problematic as other DDL may took write lock at the same
> time.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12108) Add support for writing data with LZ4's high compression mode
[ https://issues.apache.org/jira/browse/IMPALA-12108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12108: Labels: ramp-up (was: ) > Add support for writing data with LZ4's high compression mode > - > > Key: IMPALA-12108 > URL: https://issues.apache.org/jira/browse/IMPALA-12108 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 4.3.0 >Reporter: Joe McDonnell >Priority: Major > Labels: ramp-up > > LZ4 has a high compression mode that gets higher compression ratios than > Snappy while maintaining high decompression speeds. The tradeoff is that > compression is very slow. We should add support for writing data with LZ4 > high compression mode. This would let us get a sense of the performance for > writing and reading. > See this benchmark on the LZ4 page: > https://github.com/lz4/lz4#benchmarks > In my hand tests, Parquet/LZ4 is about 13% smaller than Parquet/Snappy, but > it retains the fast decompression. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12191) Add hardware and OS details to runtime profile
[ https://issues.apache.org/jira/browse/IMPALA-12191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12191: Labels: ramp-up (was: ) > Add hardware and OS details to runtime profile > -- > > Key: IMPALA-12191 > URL: https://issues.apache.org/jira/browse/IMPALA-12191 > Project: IMPALA > Issue Type: Improvement > Components: be >Reporter: David Rorke >Assignee: David Rorke >Priority: Major > Labels: ramp-up > > The runtime profiles are currently lacking any details about the hardware the > query ran on (CPU model and core count, cache sizes, etc) OS versions, etc > which may all be relevant when analyzing performance issues, comparing > performance metrics across different profiles, etc. > We should add relevant hardware and OS details to the profile. The > information currently displayed at the root Impalad web UI page (Hardware > Info, OS Info) would be a good starting point. > IMPALA-12118 is also relevant if we want to cover ARM processors. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12374) Explore optimizing re2 usage for leading / trailing ".*" when generating LIKE regex
[
https://issues.apache.org/jira/browse/IMPALA-12374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12374:
Labels: ramp-up (was: )
> Explore optimizing re2 usage for leading / trailing ".*" when generating LIKE
> regex
> ---
>
> Key: IMPALA-12374
> URL: https://issues.apache.org/jira/browse/IMPALA-12374
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Affects Versions: Impala 4.3.0
>Reporter: Joe McDonnell
>Priority: Major
> Labels: ramp-up
>
> Abseil has some recommendations about efficiently using re2 here:
> [https://abseil.io/fast/21]
> One recommendation it has is to avoid leading / trailing .* for FullMatch():
> {noformat}
> Using RE2::FullMatch() with leading or trailing .* is an antipattern.
> Instead, change it to RE2::PartialMatch() and remove the .*.
> RE2::PartialMatch() performs an unanchored search, so it is also necessary to
> anchor the regular expression (i.e. with ^ or $) to indicate that it must
> match at the start or end of the string.{noformat}
> For our slow path LIKE evaluation, we convert the LIKE to a regular
> expression and use FullMatch(). Our code to generate the regular expression
> will use leading/trailing .* and FullMatch for patterns like '%a%b%'. We
> could try detecting these cases and switching to PartialMatch with anchors.
> See the link for more details about how this works.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-10048) Speed up dumping breadpad symbols in bin/jenkins/finalize.sh
[
https://issues.apache.org/jira/browse/IMPALA-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-10048:
Labels: ramp-up (was: )
> Speed up dumping breadpad symbols in bin/jenkins/finalize.sh
>
>
> Key: IMPALA-10048
> URL: https://issues.apache.org/jira/browse/IMPALA-10048
> Project: IMPALA
> Issue Type: Improvement
> Components: Infrastructure
>Affects Versions: Impala 4.0.0
>Reporter: Joe McDonnell
>Priority: Minor
> Labels: ramp-up
>
> bin/jenkins/finalize.sh has code to find and symbolize breakpad minidumps.
> This process is very slow, because it runs bin/dump_breakpad_symbols.py for
> ${IMPALA_HOME}/be/build/latest, which includes all of the backend tests.
> There are two problems:
> # It is dumping symbols for a large number of binaries that are not useful
> unless the minidump is for that particular binary. (i.e. all the backend
> tests are useless if it is resolving an impalad minidump)
> # bin/dump_breakpad_symbols.py runs serially and could be much faster if it
> went parallel
> We should fix one or both of these problems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12494) Clamp MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS
[
https://issues.apache.org/jira/browse/IMPALA-12494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12494:
Description:
The MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS are not clamped to the
pool's 'min_query_mem_limit' and 'max_query_mem_limit', when
'clamp_mem_limit_query_option' pool setting is set. It would be good to also
clamp these memory limits.
We should also introduce a new 'min-query-mem-limit-coordinator' option for the
pool configs. This is useful for dedicated coordinators which should have
separate minimum memory limit. The maximum query memory limit should probably
still be same for both executors and coordinators ('max-query-mem-limit').
was:
The MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS are not clamped to the
pool's min_query_mem_limit and max_query_mem_limit, when
'clamp_mem_limit_query_option' pool setting is set. It would be good to also
clamp these memory limits.
We should also introduce a new 'min-query-mem-limit-coordinator' option for the
pool configs. This is useful for dedicated coordinators which should have
separate minimum memory limit. The maximum query memory limit should probably
still be same for both executors and coordinators ('max-query-mem-limit').
> Clamp MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS
>
>
> Key: IMPALA-12494
> URL: https://issues.apache.org/jira/browse/IMPALA-12494
> Project: IMPALA
> Issue Type: Task
> Components: Backend
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
>
> The MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS are not clamped to the
> pool's 'min_query_mem_limit' and 'max_query_mem_limit', when
> 'clamp_mem_limit_query_option' pool setting is set. It would be good to also
> clamp these memory limits.
> We should also introduce a new 'min-query-mem-limit-coordinator' option for
> the pool configs. This is useful for dedicated coordinators which should have
> separate minimum memory limit. The maximum query memory limit should probably
> still be same for both executors and coordinators ('max-query-mem-limit').
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12494) Clamp MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS
Abhishek Rawat created IMPALA-12494:
---
Summary: Clamp MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS
Key: IMPALA-12494
URL: https://issues.apache.org/jira/browse/IMPALA-12494
Project: IMPALA
Issue Type: Task
Components: Backend
Reporter: Abhishek Rawat
Assignee: Abhishek Rawat
The MEM_LIMIT_EXECUTORS and MEM_LIMIT_COORDINATORS are not clamped to the
pool's min_query_mem_limit and max_query_mem_limit, when
'clamp_mem_limit_query_option' pool setting is set. It would be good to also
clamp these memory limits.
We should also introduce a new 'min-query-mem-limit-coordinator' option for the
pool configs. This is useful for dedicated coordinators which should have
separate minimum memory limit. The maximum query memory limit should probably
still be same for both executors and coordinators ('max-query-mem-limit').
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-9118) Add debug page for in-flight DDLs in catalogd
[ https://issues.apache.org/jira/browse/IMPALA-9118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-9118: --- Priority: Critical (was: Major) > Add debug page for in-flight DDLs in catalogd > - > > Key: IMPALA-9118 > URL: https://issues.apache.org/jira/browse/IMPALA-9118 > Project: IMPALA > Issue Type: New Feature > Components: Catalog >Reporter: Quanlong Huang >Assignee: Quanlong Huang >Priority: Critical > Labels: observability, supportability > Attachments: Selection_082.png > > > In a busy cluster, it's possible that many DDL/DML queries keep in the > CREATED state for several minutes. Especially when using with sync_ddl=true, > tens of minutes are also possible. They may be waiting for the ExecDdl RPC to > catalogd to finish. > It'd be helpful for debugging DDL/DML hangs if we can show the in-flight DDLs > in catalogd. I think the following fields are important: > * thread id > * coordinator > * db name / table name > * ddl type, e.g. AddPartition, DropTable, CreateTable, etc. More types > [here|https://github.com/apache/impala/blob/3.3.0/common/thrift/JniCatalog.thrift#L31]. > * last event, e.g. waiting for table lock, got table lock, loading file > metadata, waiting for sync ddl version etc. > * start time > * time elapsed > * (optional) params link to show the TDdlExecRequest in json format > It'd be better to also include running REFRESH/INVALIDATE METADATA commands -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12395) Planner overestimates scan cardinality for queries using count star optimization
[
https://issues.apache.org/jira/browse/IMPALA-12395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12395:
Priority: Critical (was: Major)
> Planner overestimates scan cardinality for queries using count star
> optimization
>
>
> Key: IMPALA-12395
> URL: https://issues.apache.org/jira/browse/IMPALA-12395
> Project: IMPALA
> Issue Type: Bug
> Components: fe
>Reporter: David Rorke
>Assignee: Riza Suminto
>Priority: Critical
>
> The scan cardinality estimate for count(*) queries doesn't account for the
> fact that the count(*) optimization only scans metadata and not the actual
> columns.
> Scan for a count(*) query on Parquet store_sales:
>
> {noformat}
> Operator #Hosts #Inst Avg Time Max Time #Rows Est. #Rows Peak Mem Est. Peak
> Mem Detail
> -
> 00:SCAN S3 6 72 8s131ms 8s496ms 2.71K 8.64B 128.00 KB 88.00 MB
> tpcds_3000_string_parquet_managed.store_sales
> {noformat}
>
> This is a problem with all file/table formats that implement count(*)
> optimizations (Parquet and also probably ORC and Iceberg).
> This problem is more serious than it was in the past because with
> IMPALA-12091 we now rely on scan cardinality estimates for executor group
> assignments so count(*) queries are likely to get assigned to a larger
> executor group than needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12326) Impala daemons should only subscribe to statestore once rpc services are ready
[
https://issues.apache.org/jira/browse/IMPALA-12326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12326:
Priority: Critical (was: Major)
> Impala daemons should only subscribe to statestore once rpc services are ready
> --
>
> Key: IMPALA-12326
> URL: https://issues.apache.org/jira/browse/IMPALA-12326
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Abhishek Rawat
>Assignee: Riza Suminto
>Priority: Critical
> Fix For: Impala 4.3.0
>
>
> The Impala daemons start the statestore subscriber service before the
> krpc/rpc services are ready:
> [https://github.com/apache/impala/blob/branch-4.2.0/be/src/service/impala-server.cc#L2934]
> As a result, there is a small window where statestore could try to connect
> with Impala daemons, but the rpc service isn't ready and so statestore logs
> get filled with thrift timeout errors:
> {code:java}
> RPC Error: Client for 10.80.205.184:23000 hit an unexpected exception: No
> more data to read., type: N6apache6thrift9transport19TTransportExceptionE,
> rpc: N6impala18THeartbe
> I0731 19:43:09.05847079 client-cache.cc:174] Broken Connection, destroy
> client for 10.80.205.184:23000
> I0731 19:43:09.07682683 client-cache.h:362] RPC Error: Client for
> 10.80.192.41:23000 hit an unexpected exception: No more data to read., type:
> N6apache6thrift9transport19TTransportExceptionE, rpc: N6impala18THeartbea
> {code}
> It makes sense for statestore subscriber on Impala daemons to only start once
> the rpc/krpc service has started successfully.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12340) custom_cluster.test_catalogd_ha.TestCatalogdHA.test_two_catalogd_with_force_active fails in exhaustive tests
[
https://issues.apache.org/jira/browse/IMPALA-12340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12340:
Priority: Critical (was: Major)
> custom_cluster.test_catalogd_ha.TestCatalogdHA.test_two_catalogd_with_force_active
> fails in exhaustive tests
>
>
> Key: IMPALA-12340
> URL: https://issues.apache.org/jira/browse/IMPALA-12340
> Project: IMPALA
> Issue Type: Bug
> Components: Backend, Catalog
>Affects Versions: Impala 4.3.0
>Reporter: Peter Rozsa
>Assignee: Wenzhe Zhou
>Priority: Critical
> Labels: test-failure
> Fix For: Impala 4.3.0
>
>
> custom_cluster.test_catalogd_ha.TestCatalogdHA.test_two_catalogd_with_force_active
> fails on the assertion that checks that only one catalog is active.
> h3. Error Message
> assert True != True + where True = CatalogdService.get_metric_value of
> 0x7f9b432e8d90>>('catalog-server.active-status') + where CatalogdService.get_metric_value of
> > =
> 0x7f9b432e8d90>.get_metric_value + and True = CatalogdService.get_metric_value of
> 0x7f9b432e8a90>>('catalog-server.active-status') + where CatalogdService.get_metric_value of
> > =
> 0x7f9b432e8a90>.get_metric_value
> h3. Stacktrace
> custom_cluster/test_catalogd_ha.py:372: in
> test_two_catalogd_with_force_active
> assert(catalogd_service_1.get_metric_value("catalog-server.active-status") E
> assert True != True E + where True = CatalogdService.get_metric_value of
> 0x7f9b432e8d90>>('catalog-server.active-status') E + where CatalogdService.get_metric_value of
> > =
> 0x7f9b432e8d90>.get_metric_value E + and True = CatalogdService.get_metric_value of
> 0x7f9b432e8a90>>('catalog-server.active-status') E + where CatalogdService.get_metric_value of
> > =
> 0x7f9b432e8a90>.get_metric_value
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-10860) Allow setting separate mem_limit for coordinators
[
https://issues.apache.org/jira/browse/IMPALA-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-10860:
Priority: Critical (was: Major)
> Allow setting separate mem_limit for coordinators
> -
>
> Key: IMPALA-10860
> URL: https://issues.apache.org/jira/browse/IMPALA-10860
> Project: IMPALA
> Issue Type: Task
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
> Fix For: Impala 4.3.0
>
>
> The mem_limit query option applies to all impala coordinators and executors.
> This may not be ideal for dedicated coordinators, since they generally need
> less memory per query and having same memory limit will reduce system wide
> query concurrency.
> We could add new query options:
>
> {code:java}
> mem_limit_coordinators
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-10860) Allow setting separate mem_limit for coordinators
[
https://issues.apache.org/jira/browse/IMPALA-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat resolved IMPALA-10860.
-
Fix Version/s: Impala 4.3.0
Resolution: Resolved
> Allow setting separate mem_limit for coordinators
> -
>
> Key: IMPALA-10860
> URL: https://issues.apache.org/jira/browse/IMPALA-10860
> Project: IMPALA
> Issue Type: Task
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Major
> Fix For: Impala 4.3.0
>
>
> The mem_limit query option applies to all impala coordinators and executors.
> This may not be ideal for dedicated coordinators, since they generally need
> less memory per query and having same memory limit will reduce system wide
> query concurrency.
> We could add new query options:
>
> {code:java}
> mem_limit_coordinators
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12400) Test expected executors used for planning when no executor groups are healthy
Abhishek Rawat created IMPALA-12400: --- Summary: Test expected executors used for planning when no executor groups are healthy Key: IMPALA-12400 URL: https://issues.apache.org/jira/browse/IMPALA-12400 Project: IMPALA Issue Type: Test Reporter: Abhishek Rawat Planner uses expected executors from 'num_expected_executors' and ' 'expected_executor_group_sets' config when no executor groups are healthy. Would be good to write a test case. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12382) Coordinator could schedule fragments on gracefully shutdown executors
Abhishek Rawat created IMPALA-12382:
---
Summary: Coordinator could schedule fragments on gracefully
shutdown executors
Key: IMPALA-12382
URL: https://issues.apache.org/jira/browse/IMPALA-12382
Project: IMPALA
Issue Type: Improvement
Reporter: Abhishek Rawat
Statestore does failure detection based on consecutive heartbeat failures. This
is by default configured to be 10 (statestore_max_missed_heartbeats) at 1
second intervals (statestore_heartbeat_frequency_ms). This could however take
much longer than 10 seconds overall, especially if statestore is busy and due
to rpc timeout duration.
In the following example it took 50 seconds for failure detection:
{code:java}
I0817 12:32:06.824721 86 statestore.cc:1157] Unable to send heartbeat
message to subscriber
impa...@impala-executor-001-5.impala-executor.impala-1692115218-htqx.svc.cluster.local:27010,
received error: RPC Error: Client for 10.80.199.159:23000 hit an unexpected
exception: No more data to read., type:
N6apache6thrift9transport19TTransportExceptionE, rpc:
N6impala18THeartbeatResponseE, send: done
I0817 12:32:06.824741 86 failure-detector.cc:91] 1 consecutive heartbeats
failed for
'impa...@impala-executor-001-5.impala-executor.impala-1692115218-htqx.svc.cluster.local:27010'.
State is OK
.
.
.
I0817 12:32:56.800251 83 statestore.cc:1157] Unable to send heartbeat
message to subscriber
impa...@impala-executor-001-5.impala-executor.impala-1692115218-htqx.svc.cluster.local:27010,
received error: RPC Error: Client for 10.80.199.159:23000 hit an unexpected
exception: No more data to read., type:
N6apache6thrift9transport19TTransportExceptionE, rpc:
N6impala18THeartbeatResponseE, send: done
I0817 12:32:56.800267 83 failure-detector.cc:91] 10 consecutive heartbeats
failed for
'impa...@impala-executor-001-5.impala-executor.impala-1692115218-htqx.svc.cluster.local:27010'.
State is FAILED
I0817 12:32:56.800276 83 statestore.cc:1168] Subscriber
'impa...@impala-executor-001-5.impala-executor.impala-1692115218-htqx.svc.cluster.local:27010'
has failed, disconnected or re-registered (last known registration ID:
c84bf70f03acda2b:b34a812c5e96e687){code}
As a result there is a window when statestore is determining node failure and
coordinator might schedule fragments on that particular executor(s). The exec
RPC will fail and if transparent query retries is enabled, coordinator will
immediately retry the query and it will fail again.
Ideally in such situations coordinator should be notified sooner about a failed
executor. Statestore could send priority topic update to coordinator when it
enters failure detection logic. This should reduce the chances of coordinator
scheduling query fragment on a failed executor.
The other argument could be to tune the heartbeat frequency and interval
parameters. But, it's hard to find configuration which works for all cases.
And, so while the default values are reasonable, under certain conditions they
could be unreasonable as seen in the above example.
It might make sense to especially handle the case where executors are shutdown
gracefully and in such case statestore shouldn't do failure detection and
instead fail these executor immediately.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-10860) Allow setting separate mem_limit for coordinators
[
https://issues.apache.org/jira/browse/IMPALA-10860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-10860:
Description:
The mem_limit query option applies to all impala coordinators and executors.
This may not be ideal for dedicated coordinators, since they generally need
less memory per query and having same memory limit will reduce system wide
query concurrency.
We could add new query options:
{code:java}
mem_limit_coordinators
{code}
was:
The mem_limit query option applies to all impala coordinators and executors.
This may not be ideal for dedicated coordinators, since they generally need
less memory per query and having same memory limit will reduce system wide
query concurrency.
We could add new query options:
{code:java}
mem_limit_coordinators
mem_limit_executors
{code}
> Allow setting separate mem_limit for coordinators
> -
>
> Key: IMPALA-10860
> URL: https://issues.apache.org/jira/browse/IMPALA-10860
> Project: IMPALA
> Issue Type: Task
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Major
>
> The mem_limit query option applies to all impala coordinators and executors.
> This may not be ideal for dedicated coordinators, since they generally need
> less memory per query and having same memory limit will reduce system wide
> query concurrency.
> We could add new query options:
>
> {code:java}
> mem_limit_coordinators
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12326) Impala daemons should only subscribe to statestore once rpc services are ready
Abhishek Rawat created IMPALA-12326:
---
Summary: Impala daemons should only subscribe to statestore once
rpc services are ready
Key: IMPALA-12326
URL: https://issues.apache.org/jira/browse/IMPALA-12326
Project: IMPALA
Issue Type: Improvement
Components: Backend
Reporter: Abhishek Rawat
The Impala daemons start the statestore subscriber service before the krpc/rpc
services are ready:
[https://github.com/apache/impala/blob/branch-4.2.0/be/src/service/impala-server.cc#L2934]
As a result, there is a small window where statestore could try to connect with
Impala daemons, but the rpc service isn't ready and so statestore logs get
filled with thrift timeout errors:
{code:java}
RPC Error: Client for 10.80.205.184:23000 hit an unexpected exception: No more
data to read., type: N6apache6thrift9transport19TTransportExceptionE, rpc:
N6impala18THeartbe
I0731 19:43:09.05847079 client-cache.cc:174] Broken Connection, destroy
client for 10.80.205.184:23000
I0731 19:43:09.07682683 client-cache.h:362] RPC Error: Client for
10.80.192.41:23000 hit an unexpected exception: No more data to read., type:
N6apache6thrift9transport19TTransportExceptionE, rpc: N6impala18THeartbea {code}
It makes sense for statestore subscriber on Impala daemons to only start once
the rpc/krpc service has started successfully.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12305) Impala server hanging when processing DDL if CatalogD HA is enabled
[ https://issues.apache.org/jira/browse/IMPALA-12305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12305: Priority: Critical (was: Major) > Impala server hanging when processing DDL if CatalogD HA is enabled > > > Key: IMPALA-12305 > URL: https://issues.apache.org/jira/browse/IMPALA-12305 > Project: IMPALA > Issue Type: Bug > Components: Backend, Frontend >Affects Versions: Impala 4.3.0 >Reporter: Wenzhe Zhou >Assignee: Wenzhe Zhou >Priority: Critical > Fix For: Impala 4.3.0 > > > In IMPALA-12286, catalogd re-generate its Catalog Service ID in JniCatalog > when it becomes active. But CatalogServiceCatalog is not updated when new > Catalog Service ID is generated. This causes coordinator hanging when > processing DDLs. > In CatalogServer class, member variable is_active_ is not protected by mutex > catalog_lock_, and pending_topic_updates_ is not cleared when the catalogd > becomes active. It's possible catalog server sends pending catalog topic > updates with old Catalog Service ID then sends catalog topic updates with new > Catalog Service ID. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12155) Support Impala CatalogD HA
[ https://issues.apache.org/jira/browse/IMPALA-12155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12155: Priority: Critical (was: Major) > Support Impala CatalogD HA > -- > > Key: IMPALA-12155 > URL: https://issues.apache.org/jira/browse/IMPALA-12155 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Wenzhe Zhou >Assignee: Wenzhe Zhou >Priority: Critical > > To support catalog HA, we need to have two CatalogD in HA pair, and add the > preemptive behavior for Catalogd. When CatalogD HA is enabled, the preemptive > behavior allows the CatalogD with the higher priority to become active and > the paired CatalogD becomes standby. The active CatalogD acts as the source > of metadata and provides catalog service for the Impala cluster. When active > CatalogD is not healthy, the standby CatalogD will take over catalog service. > Preemption is disabled on the CatalogD when it is not running as HA pair. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Closed] (IMPALA-11858) admissiond incorrectly caps memory limit to its process memory
[ https://issues.apache.org/jira/browse/IMPALA-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat closed IMPALA-11858. --- Target Version: Impala 4.3.0 Resolution: Fixed > admissiond incorrectly caps memory limit to its process memory > -- > > Key: IMPALA-11858 > URL: https://issues.apache.org/jira/browse/IMPALA-11858 > Project: IMPALA > Issue Type: Bug >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Critical > > When admission controller is running as a separate daemon it incorrectly caps > memory limit for the query to its process limit. This is also incorrect > behavior when admission controller is running in coordinator as executors > could have different memory limit compared to coordinator. > https://github.com/apache/impala/blob/master/be/src/scheduling/schedule-state.cc#L312#L313 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-12015) enable healthz endpoint in admissiond webui
[ https://issues.apache.org/jira/browse/IMPALA-12015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat resolved IMPALA-12015. - Target Version: Impala 4.3.0 Resolution: Fixed > enable healthz endpoint in admissiond webui > --- > > Key: IMPALA-12015 > URL: https://issues.apache.org/jira/browse/IMPALA-12015 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > A '/healthz' endpoint indicating admission service's readiness could be > useful for external clients trying to determine readiness of admissiond's > service. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12146) Memory reserved doesn't get updated if an executor backend gets abnormally terminated
Abhishek Rawat created IMPALA-12146: --- Summary: Memory reserved doesn't get updated if an executor backend gets abnormally terminated Key: IMPALA-12146 URL: https://issues.apache.org/jira/browse/IMPALA-12146 Project: IMPALA Issue Type: Bug Reporter: Abhishek Rawat If an executor backend is abnormally terminated its memory reserved accounting doesn't get updated and as a result the admission controller gets an incorrect view of the reserved memory for that particular backend. The side effect is that even if the abnormally terminated executor is restarted and added to the cluster, its reserved memory is still incorrectly set to the value before termination. Repro: * Execute a long running query * Kill one of the Impalads which is an executor only backend while the query is running. * Restart the executor backend which was abnormally terminated above * On the web ui go to the /backends page and the 'Memory Reserved' for the executor backend would be non zero * Even if the session is closed the 'Memory Reserved' for the executor backend remains non zero. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12060) statestore should only allow a single catalog instance to be part of cluster
[ https://issues.apache.org/jira/browse/IMPALA-12060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-12060: --- Assignee: Wenzhe Zhou (was: Abhishek Rawat) > statestore should only allow a single catalog instance to be part of cluster > > > Key: IMPALA-12060 > URL: https://issues.apache.org/jira/browse/IMPALA-12060 > Project: IMPALA > Issue Type: Bug >Reporter: Abhishek Rawat >Assignee: Wenzhe Zhou >Priority: Critical > > Today Impala doesn't support multiple catalogd instances to be part of the > cluster. When using external Active Passive HA mechanisms like leader > election, it may be possible for multiple catalog replicas to be part of the > cluster, in some cases. This is mainly because catalogds have no idea that > there are other catalogd instances. One way to address this issue could be > for statestore to always ensure that there could only be a single instance of > catalogd in the cluster. Coordinator also has a config `catalog_service_host` > - both statestore and coordinator should have a consistent view and consider > the proper catalogd instance to be part of the cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12060) statestore should only allow a single catalog instance to be part of cluster
[ https://issues.apache.org/jira/browse/IMPALA-12060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12060: Description: Today Impala doesn't support multiple catalogd instances to be part of the cluster. When using external Active Passive HA mechanisms like leader election, it may be possible for multiple catalog replicas to be part of the cluster, in some cases. This is mainly because catalogds have no idea that there are other catalogd instances. One way to address this issue could be for statestore to always ensure that there could only be a single instance of catalogd in the cluster. Coordinator also has a config `catalog_service_host` - both statestore and coordinator should have a consistent view and consider the proper catalogd instance to be part of the cluster. (was: Today Impala doesn't support multiple catalogd instances to be part of the cluster. When using external Active Passive HA mechanisms like leader election, it may be possible for multiple catalog replicas to be part of the cluster, in some cases. This is mainly because catalogds have no idea that there are other catalogd instances. One way to address this issue could be for statestore to always ensure that there could only be a single instance of catalogd in the cluster. ) > statestore should only allow a single catalog instance to be part of cluster > > > Key: IMPALA-12060 > URL: https://issues.apache.org/jira/browse/IMPALA-12060 > Project: IMPALA > Issue Type: Bug >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Critical > > Today Impala doesn't support multiple catalogd instances to be part of the > cluster. When using external Active Passive HA mechanisms like leader > election, it may be possible for multiple catalog replicas to be part of the > cluster, in some cases. This is mainly because catalogds have no idea that > there are other catalogd instances. One way to address this issue could be > for statestore to always ensure that there could only be a single instance of > catalogd in the cluster. Coordinator also has a config `catalog_service_host` > - both statestore and coordinator should have a consistent view and consider > the proper catalogd instance to be part of the cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11880) JWT Token based auth support for Impala Shell
[ https://issues.apache.org/jira/browse/IMPALA-11880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11880: Priority: Critical (was: Major) > JWT Token based auth support for Impala Shell > - > > Key: IMPALA-11880 > URL: https://issues.apache.org/jira/browse/IMPALA-11880 > Project: IMPALA > Issue Type: Improvement >Reporter: Manish Maheshwari >Assignee: Jason Fehr >Priority: Critical > > Add JWT Token based auth support for Impala Shell > cc [~jasonmfehr] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12060) statestore should only allow a single catalog instance to be part of cluster
Abhishek Rawat created IMPALA-12060: --- Summary: statestore should only allow a single catalog instance to be part of cluster Key: IMPALA-12060 URL: https://issues.apache.org/jira/browse/IMPALA-12060 Project: IMPALA Issue Type: Bug Reporter: Abhishek Rawat Assignee: Abhishek Rawat Today Impala doesn't support multiple catalogd instances to be part of the cluster. When using external Active Passive HA mechanisms like leader election, it may be possible for multiple catalog replicas to be part of the cluster, in some cases. This is mainly because catalogds have no idea that there are other catalogd instances. One way to address this issue could be for statestore to always ensure that there could only be a single instance of catalogd in the cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12057) admissiond fails to admit queued queries if coordinator's membership id changes
Abhishek Rawat created IMPALA-12057:
---
Summary: admissiond fails to admit queued queries if coordinator's
membership id changes
Key: IMPALA-12057
URL: https://issues.apache.org/jira/browse/IMPALA-12057
Project: IMPALA
Issue Type: Bug
Reporter: Abhishek Rawat
If coordinator's subscription id changes (due to a restart or reconnection with
statestored), admissiond has no way of knowing if the coordinator was briefly
disconnected and is again part of the cluster and has the query state preserved
or coordinator got restarted and doesn't know anything about the queued query.
Ideally in such cases admissiond should learn from coordinator and statestored
that the queued queries are still valid and the subscription id has changed so
that admission controller can submit the queued queries.
Untill we support that we should at least fail these queries immediately. The
current behavior is that admission controller goes into an infinite loop
waiting on these queued queries:
{code:java}
I0411 13:52:22.694419 67 admission-controller.cc:2206] Could not dequeue
query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
with the statestore.
I0411 13:52:22.795398 67 admission-controller.cc:2206] Could not dequeue
query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
with the statestore.
I0411 15:14:11.063143 67 admission-controller.cc:2206] Could not dequeue
query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
with the statestore.
I0411 15:14:11.164698 67 admission-controller.cc:2206] Could not dequeue
query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
with the statestore. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12057) admissiond fails to admit queued queries if coordinator's membership id changes
[
https://issues.apache.org/jira/browse/IMPALA-12057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12057:
Priority: Critical (was: Major)
> admissiond fails to admit queued queries if coordinator's membership id
> changes
> ---
>
> Key: IMPALA-12057
> URL: https://issues.apache.org/jira/browse/IMPALA-12057
> Project: IMPALA
> Issue Type: Bug
>Reporter: Abhishek Rawat
>Priority: Critical
>
> If coordinator's subscription id changes (due to a restart or reconnection
> with statestored), admissiond has no way of knowing if the coordinator was
> briefly disconnected and is again part of the cluster and has the query state
> preserved or coordinator got restarted and doesn't know anything about the
> queued query.
> Ideally in such cases admissiond should learn from coordinator and
> statestored that the queued queries are still valid and the subscription id
> has changed so that admission controller can submit the queued queries.
> Untill we support that we should at least fail these queries immediately. The
> current behavior is that admission controller goes into an infinite loop
> waiting on these queued queries:
> {code:java}
> I0411 13:52:22.694419 67 admission-controller.cc:2206] Could not dequeue
> query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
> with the statestore.
> I0411 13:52:22.795398 67 admission-controller.cc:2206] Could not dequeue
> query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
> with the statestore.
>
> I0411 15:14:11.063143 67 admission-controller.cc:2206] Could not dequeue
> query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
> with the statestore.
> I0411 15:14:11.164698 67 admission-controller.cc:2206] Could not dequeue
> query id=c748095c589ccfb6:38199371 reason: Coordinator not registered
> with the statestore. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12056) Child queries could get scheduled on improper executor group sets
[
https://issues.apache.org/jira/browse/IMPALA-12056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12056:
Description:
'Compute Stats' queries gets scheduled on the smallest executor group set since
these queries don't do any real work. However their child queries also gets
scheduled on the smallest executor group. This may not be ideal for cases where
the child query does NDVs and Counts on a big wide table. We should assign the
executor group set for the children queries based on their planning estimates.
Today we see following message for the parent query, which. makes sense:
{code:java}
Verdict: Assign to first group because query is not auto-scalable {code}
as a side effect we see following message for child queries:
{code:java}
Verdict: query option REQUEST_POOL=root.group-set-small is set. Memory and cpu
limit checking is skipped. {code}
was:
'Compute Stats' queries gets scheduled on the smallest executor group set since
these queries don't do any real work. However their child queries also gets
scheduled on the smallest executor group. This may not be ideal for cases where
the child query does an NDV and Count on a big wide table. We should assign the
executor group set for the children queries based on their planning estimates.
Today we see following message for the parent query, which. makes sense:
{code:java}
Verdict: Assign to first group because query is not auto-scalable {code}
as a side effect we see following message for child queries:
{code:java}
Verdict: query option REQUEST_POOL=root.group-set-small is set. Memory and cpu
limit checking is skipped. {code}
> Child queries could get scheduled on improper executor group sets
> -
>
> Key: IMPALA-12056
> URL: https://issues.apache.org/jira/browse/IMPALA-12056
> Project: IMPALA
> Issue Type: Bug
>Reporter: Abhishek Rawat
>Priority: Critical
>
> 'Compute Stats' queries gets scheduled on the smallest executor group set
> since these queries don't do any real work. However their child queries also
> gets scheduled on the smallest executor group. This may not be ideal for
> cases where the child query does NDVs and Counts on a big wide table. We
> should assign the executor group set for the children queries based on their
> planning estimates.
> Today we see following message for the parent query, which. makes sense:
> {code:java}
> Verdict: Assign to first group because query is not auto-scalable {code}
> as a side effect we see following message for child queries:
> {code:java}
> Verdict: query option REQUEST_POOL=root.group-set-small is set. Memory and
> cpu limit checking is skipped. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12056) Child queries could get scheduled on improper executor group sets
Abhishek Rawat created IMPALA-12056:
---
Summary: Child queries could get scheduled on improper executor
group sets
Key: IMPALA-12056
URL: https://issues.apache.org/jira/browse/IMPALA-12056
Project: IMPALA
Issue Type: Bug
Reporter: Abhishek Rawat
'Compute Stats' queries gets scheduled on the smallest executor group set since
these queries don't do any real work. However their child queries also gets
scheduled on the smallest executor group. This may not be ideal for cases where
the child query does an NDV and Count on a big wide table. We should assign the
executor group set for the children queries based on their planning estimates.
Today we see following message for the parent query, which. makes sense:
{code:java}
Verdict: Assign to first group because query is not auto-scalable {code}
as a side effect we see following message for child queries:
{code:java}
Verdict: query option REQUEST_POOL=root.group-set-small is set. Memory and cpu
limit checking is skipped. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-12039) graceful shutdown doesn't work in redhat docker images
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat resolved IMPALA-12039.
-
Target Version: Impala 4.3.0
Resolution: Fixed
> graceful shutdown doesn't work in redhat docker images
> --
>
> Key: IMPALA-12039
> URL: https://issues.apache.org/jira/browse/IMPALA-12039
> Project: IMPALA
> Issue Type: Improvement
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
>
> There is a race condition between admission controller and
> executors/executor-group deletion. if a query comes in it could be admitted
> to just deleted executor group and the query would fail.
> {code:java}
> I0330 06:05:25.600728 9398 admission-controller.cc:1941]
> 3c4f9069df52951e:0b97d928] Trying to admit
> id=3c4f9069df52951e:0b97d928 in pool_name=root.default
> executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
> dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
> max_mem=48828.12 GB is_trivial_query=false
> I0330 06:05:25.600769 9398 admission-controller.cc:1950]
> 3c4f9069df52951e:0b97d928] Stats: agg_num_running=0,
> agg_num_queued=0, agg_mem_reserved=0, local_host(local_mem_admitted=0,
> local_trivial_running=0, num_admitted_running=0, num_queued=0,
> backend_mem_reserved=0, topN_query_stats:
> queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
> pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
> average_per_query=0)
> I0330 06:05:25.600816 9398 admission-controller.cc:1300]
> 3c4f9069df52951e:0b97d928] Admitting query
> id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.600883 9398 impala-server.cc:2231]
> 3c4f9069df52951e:0b97d928] Registering query locations
> I0330 06:05:25.600898 9398 coordinator.cc:151]
> 3c4f9069df52951e:0b97d928] Exec()
> query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
> test_a9a41a5.t where id + random() < sleep(1)
> I0330 06:05:25.601054 9398 coordinator.cc:476]
> 3c4f9069df52951e:0b97d928] starting execution on 2 backends for
> query_id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.601359 124 control-service.cc:148]
> 3c4f9069df52951e:0b97d928] ExecQueryFInstances():
> query_id=3c4f9069df52951e:0b97d928
> coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
> #instances=1
> I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
> error: Client connection negotiation failed: client connection to
> 192.168.112.16:27010: connect: Connection refused (error 111)
> E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
> ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
> Exec() rpc failed: Network error: Client connection negotiation failed:
> client connection to 192.168.112.16:27010: connect: Connection refused (error
> 111) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-12039) graceful shutdown doesn't work in redhat docker images
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709843#comment-17709843
]
Abhishek Rawat commented on IMPALA-12039:
-
Turns out the issue was that 'pgrep' was missing from the redhat docker images
and as a result graceful shutdown wasn't working.
{code:java}
$ /opt/impala/bin/graceful_shutdown_backends.sh
+ export IMPALA_HOME=/opt/impala
+ IMPALA_HOME=/opt/impala
+ LOG_FILE=/opt/impala/logs/shutdown.log
+ GRACE_TIMEOUT=130
+ [[ 0 -ge 1 ]]
+ LOG 'Initiating graceful shutdown.'
+ echo Initiating graceful shutdown.
+ tee -a /opt/impala/logs/shutdown.log
Initiating graceful shutdown.
++ pgrep impalad
/opt/impala/bin/graceful_shutdown_backends.sh: line 43: pgrep: command not found
+ LOG 'Waiting for daemons to exit, up to 130 s.'
+ echo Waiting for daemons to exit, up to 130 s.
+ tee -a /opt/impala/logs/shutdown.log
Waiting for daemons to exit, up to 130 s.
+ (( i=0 ))
+ (( i<130 ))
++ pgrep impalad
/opt/impala/bin/graceful_shutdown_backends.sh: line 50: pgrep: command not found
++ true
+ pids=
+ [[ -z '' ]]
+ LOG 'All daemons have exited after 0 s.'
+ echo All daemons have exited after 0 s.
+ tee -a /opt/impala/logs/shutdown.log
All daemons have exited after 0 s.
+ break
+ LOG 'Graceful shutdown process complete.'
+ echo Graceful shutdown process complete.
+ tee -a /opt/impala/logs/shutdown.log
Graceful shutdown process complete. {code}
> graceful shutdown doesn't work in redhat docker images
> --
>
> Key: IMPALA-12039
> URL: https://issues.apache.org/jira/browse/IMPALA-12039
> Project: IMPALA
> Issue Type: Improvement
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
>
> There is a race condition between admission controller and
> executors/executor-group deletion. if a query comes in it could be admitted
> to just deleted executor group and the query would fail.
> {code:java}
> I0330 06:05:25.600728 9398 admission-controller.cc:1941]
> 3c4f9069df52951e:0b97d928] Trying to admit
> id=3c4f9069df52951e:0b97d928 in pool_name=root.default
> executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
> dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
> max_mem=48828.12 GB is_trivial_query=false
> I0330 06:05:25.600769 9398 admission-controller.cc:1950]
> 3c4f9069df52951e:0b97d928] Stats: agg_num_running=0,
> agg_num_queued=0, agg_mem_reserved=0, local_host(local_mem_admitted=0,
> local_trivial_running=0, num_admitted_running=0, num_queued=0,
> backend_mem_reserved=0, topN_query_stats:
> queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
> pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
> average_per_query=0)
> I0330 06:05:25.600816 9398 admission-controller.cc:1300]
> 3c4f9069df52951e:0b97d928] Admitting query
> id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.600883 9398 impala-server.cc:2231]
> 3c4f9069df52951e:0b97d928] Registering query locations
> I0330 06:05:25.600898 9398 coordinator.cc:151]
> 3c4f9069df52951e:0b97d928] Exec()
> query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
> test_a9a41a5.t where id + random() < sleep(1)
> I0330 06:05:25.601054 9398 coordinator.cc:476]
> 3c4f9069df52951e:0b97d928] starting execution on 2 backends for
> query_id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.601359 124 control-service.cc:148]
> 3c4f9069df52951e:0b97d928] ExecQueryFInstances():
> query_id=3c4f9069df52951e:0b97d928
> coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
> #instances=1
> I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
> error: Client connection negotiation failed: client connection to
> 192.168.112.16:27010: connect: Connection refused (error 111)
> E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
> ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
> Exec() rpc failed: Network error: Client connection negotiation failed:
> client connection to 192.168.112.16:27010: connect: Connection refused (error
> 111) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12039) graceful shutdown doesn't work in redhat docker images
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12039:
Summary: graceful shutdown doesn't work in redhat docker images (was:
Potential Race condition between executor group deletion and admission
controller)
> graceful shutdown doesn't work in redhat docker images
> --
>
> Key: IMPALA-12039
> URL: https://issues.apache.org/jira/browse/IMPALA-12039
> Project: IMPALA
> Issue Type: Improvement
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
>
> There is a race condition between admission controller and
> executors/executor-group deletion. if a query comes in it could be admitted
> to just deleted executor group and the query would fail.
> {code:java}
> I0330 06:05:25.600728 9398 admission-controller.cc:1941]
> 3c4f9069df52951e:0b97d928] Trying to admit
> id=3c4f9069df52951e:0b97d928 in pool_name=root.default
> executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
> dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
> max_mem=48828.12 GB is_trivial_query=false
> I0330 06:05:25.600769 9398 admission-controller.cc:1950]
> 3c4f9069df52951e:0b97d928] Stats: agg_num_running=0,
> agg_num_queued=0, agg_mem_reserved=0, local_host(local_mem_admitted=0,
> local_trivial_running=0, num_admitted_running=0, num_queued=0,
> backend_mem_reserved=0, topN_query_stats:
> queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
> pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
> average_per_query=0)
> I0330 06:05:25.600816 9398 admission-controller.cc:1300]
> 3c4f9069df52951e:0b97d928] Admitting query
> id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.600883 9398 impala-server.cc:2231]
> 3c4f9069df52951e:0b97d928] Registering query locations
> I0330 06:05:25.600898 9398 coordinator.cc:151]
> 3c4f9069df52951e:0b97d928] Exec()
> query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
> test_a9a41a5.t where id + random() < sleep(1)
> I0330 06:05:25.601054 9398 coordinator.cc:476]
> 3c4f9069df52951e:0b97d928] starting execution on 2 backends for
> query_id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.601359 124 control-service.cc:148]
> 3c4f9069df52951e:0b97d928] ExecQueryFInstances():
> query_id=3c4f9069df52951e:0b97d928
> coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
> #instances=1
> I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
> error: Client connection negotiation failed: client connection to
> 192.168.112.16:27010: connect: Connection refused (error 111)
> E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
> ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
> Exec() rpc failed: Network error: Client connection negotiation failed:
> client connection to 192.168.112.16:27010: connect: Connection refused (error
> 111) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12039) Potential Race condition between executor group deletion and admission controller
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat reassigned IMPALA-12039:
---
Assignee: Abhishek Rawat
> Potential Race condition between executor group deletion and admission
> controller
> -
>
> Key: IMPALA-12039
> URL: https://issues.apache.org/jira/browse/IMPALA-12039
> Project: IMPALA
> Issue Type: Improvement
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
>
> There is a race condition between admission controller and
> executors/executor-group deletion. if a query comes in it could be admitted
> to just deleted executor group and the query would fail.
> {code:java}
> I0330 06:05:25.600728 9398 admission-controller.cc:1941]
> 3c4f9069df52951e:0b97d928] Trying to admit
> id=3c4f9069df52951e:0b97d928 in pool_name=root.default
> executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
> dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
> max_mem=48828.12 GB is_trivial_query=false
> I0330 06:05:25.600769 9398 admission-controller.cc:1950]
> 3c4f9069df52951e:0b97d928] Stats: agg_num_running=0,
> agg_num_queued=0, agg_mem_reserved=0, local_host(local_mem_admitted=0,
> local_trivial_running=0, num_admitted_running=0, num_queued=0,
> backend_mem_reserved=0, topN_query_stats:
> queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
> pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
> average_per_query=0)
> I0330 06:05:25.600816 9398 admission-controller.cc:1300]
> 3c4f9069df52951e:0b97d928] Admitting query
> id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.600883 9398 impala-server.cc:2231]
> 3c4f9069df52951e:0b97d928] Registering query locations
> I0330 06:05:25.600898 9398 coordinator.cc:151]
> 3c4f9069df52951e:0b97d928] Exec()
> query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
> test_a9a41a5.t where id + random() < sleep(1)
> I0330 06:05:25.601054 9398 coordinator.cc:476]
> 3c4f9069df52951e:0b97d928] starting execution on 2 backends for
> query_id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.601359 124 control-service.cc:148]
> 3c4f9069df52951e:0b97d928] ExecQueryFInstances():
> query_id=3c4f9069df52951e:0b97d928
> coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
> #instances=1
> I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
> error: Client connection negotiation failed: client connection to
> 192.168.112.16:27010: connect: Connection refused (error 111)
> E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
> ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
> Exec() rpc failed: Network error: Client connection negotiation failed:
> client connection to 192.168.112.16:27010: connect: Connection refused (error
> 111) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-12039) Potential Race condition between executor group deletion and admission controller
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17709534#comment-17709534
]
Abhishek Rawat commented on IMPALA-12039:
-
While the race condition might be unavoidable since admission and scheduling
logic relies on snapshots which doesn't reflect the live state of the cluster.
But, the query retry path could be improved to not rely on old snapshots.
> Potential Race condition between executor group deletion and admission
> controller
> -
>
> Key: IMPALA-12039
> URL: https://issues.apache.org/jira/browse/IMPALA-12039
> Project: IMPALA
> Issue Type: Improvement
>Reporter: Abhishek Rawat
>Priority: Critical
>
> There is a race condition between admission controller and
> executors/executor-group deletion. if a query comes in it could be admitted
> to just deleted executor group and the query would fail.
> {code:java}
> I0330 06:05:25.600728 9398 admission-controller.cc:1941]
> 3c4f9069df52951e:0b97d928] Trying to admit
> id=3c4f9069df52951e:0b97d928 in pool_name=root.default
> executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
> dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
> max_mem=48828.12 GB is_trivial_query=false
> I0330 06:05:25.600769 9398 admission-controller.cc:1950]
> 3c4f9069df52951e:0b97d928] Stats: agg_num_running=0,
> agg_num_queued=0, agg_mem_reserved=0, local_host(local_mem_admitted=0,
> local_trivial_running=0, num_admitted_running=0, num_queued=0,
> backend_mem_reserved=0, topN_query_stats:
> queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
> pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
> average_per_query=0)
> I0330 06:05:25.600816 9398 admission-controller.cc:1300]
> 3c4f9069df52951e:0b97d928] Admitting query
> id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.600883 9398 impala-server.cc:2231]
> 3c4f9069df52951e:0b97d928] Registering query locations
> I0330 06:05:25.600898 9398 coordinator.cc:151]
> 3c4f9069df52951e:0b97d928] Exec()
> query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
> test_a9a41a5.t where id + random() < sleep(1)
> I0330 06:05:25.601054 9398 coordinator.cc:476]
> 3c4f9069df52951e:0b97d928] starting execution on 2 backends for
> query_id=3c4f9069df52951e:0b97d928
> I0330 06:05:25.601359 124 control-service.cc:148]
> 3c4f9069df52951e:0b97d928] ExecQueryFInstances():
> query_id=3c4f9069df52951e:0b97d928
> coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
> #instances=1
> I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
> error: Client connection negotiation failed: client connection to
> 192.168.112.16:27010: connect: Connection refused (error 111)
> E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
> ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
> Exec() rpc failed: Network error: Client connection negotiation failed:
> client connection to 192.168.112.16:27010: connect: Connection refused (error
> 111) {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-9874) Reduce or avoid I/O for pruned columns
[ https://issues.apache.org/jira/browse/IMPALA-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-9874: -- Assignee: Abhishek Rawat > Reduce or avoid I/O for pruned columns > -- > > Key: IMPALA-9874 > URL: https://issues.apache.org/jira/browse/IMPALA-9874 > Project: IMPALA > Issue Type: Sub-task > Components: Backend >Reporter: Tim Armstrong >Assignee: Abhishek Rawat >Priority: Critical > Labels: parquet > > Skipping decoding of values may not be effective at reducing I/O in some > cases, because we start the I/O in StartScans(). We don't wait for the I/O > until we actually read the first data page from the column reader. So there > is a race to determine whether the I/O happens in some cases. > There are a couple of things we can do here. > * The basic thing is to issue reads for the column readers in the order in > which they are needed. We may be able to get this for free by ordering the > column readers based on materialisation order. > * We also want to avoid issuing I/O for columns that are not needed, if > predicates are highly selective. This is maybe a bit harder and avoids more > trade-offs, since delaying issuing of the reads may impact scan latency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-9874) Reduce or avoid I/O for pruned columns
[ https://issues.apache.org/jira/browse/IMPALA-9874?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-9874: --- Priority: Critical (was: Major) > Reduce or avoid I/O for pruned columns > -- > > Key: IMPALA-9874 > URL: https://issues.apache.org/jira/browse/IMPALA-9874 > Project: IMPALA > Issue Type: Sub-task > Components: Backend >Reporter: Tim Armstrong >Priority: Critical > Labels: parquet > > Skipping decoding of values may not be effective at reducing I/O in some > cases, because we start the I/O in StartScans(). We don't wait for the I/O > until we actually read the first data page from the column reader. So there > is a race to determine whether the I/O happens in some cases. > There are a couple of things we can do here. > * The basic thing is to issue reads for the column readers in the order in > which they are needed. We may be able to get this for free by ordering the > column readers based on materialisation order. > * We also want to avoid issuing I/O for columns that are not needed, if > predicates are highly selective. This is maybe a bit harder and avoids more > trade-offs, since delaying issuing of the reads may impact scan latency. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-9873) Skip decoding of non-materialised columns in Parquet
[ https://issues.apache.org/jira/browse/IMPALA-9873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-9873: --- Priority: Critical (was: Major) > Skip decoding of non-materialised columns in Parquet > > > Key: IMPALA-9873 > URL: https://issues.apache.org/jira/browse/IMPALA-9873 > Project: IMPALA > Issue Type: Sub-task > Components: Backend >Reporter: Tim Armstrong >Assignee: Amogh Margoor >Priority: Critical > Fix For: Impala 4.1.0 > > > This is a first milestone for lazy materialization in parquet, focusing on > avoiding decompression and decoding of columns. > * Identify columns referenced by predicates and runtime row filters and > determine what order the columns need to be materialised in. Probably we want > to evaluate static predicates before runtime filters to match current > behaviour. > * Rework this loop so that it alternates between materialising columns and > evaluating predicates: > https://github.com/apache/impala/blob/052129c/be/src/exec/parquet/hdfs-parquet-scanner.cc#L1110 > * We probably need to keep track of filtered rows using a new data structure, > e.g. bitmap > * We need to then check that bitmap at each step to see if we skip > materialising part or all of the following columns. E.g. if the first N rows > were pruned, we can skip forward the remaining readers N rows. > * This part may be a little tricky - there is the risk of adding overhead > compared to the current code. > * It is probably OK to just materialise the partition columns to start off > with - avoiding materialising those is not going to buy that much. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12039) Potential Race condition between executor group deletion and admission controller
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12039:
Description:
There is a race condition between admission controller and
executors/executor-group deletion. if a query comes in it could be admitted to
just deleted executor group and the query would fail.
{code:java}
I0330 06:05:25.600728 9398 admission-controller.cc:1941]
3c4f9069df52951e:0b97d928] Trying to admit
id=3c4f9069df52951e:0b97d928 in pool_name=root.default
executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
max_mem=48828.12 GB is_trivial_query=false
I0330 06:05:25.600769 9398 admission-controller.cc:1950]
3c4f9069df52951e:0b97d928] Stats: agg_num_running=0, agg_num_queued=0,
agg_mem_reserved=0, local_host(local_mem_admitted=0, local_trivial_running=0,
num_admitted_running=0, num_queued=0, backend_mem_reserved=0, topN_query_stats:
queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
average_per_query=0)
I0330 06:05:25.600816 9398 admission-controller.cc:1300]
3c4f9069df52951e:0b97d928] Admitting query
id=3c4f9069df52951e:0b97d928
I0330 06:05:25.600883 9398 impala-server.cc:2231]
3c4f9069df52951e:0b97d928] Registering query locations
I0330 06:05:25.600898 9398 coordinator.cc:151]
3c4f9069df52951e:0b97d928] Exec()
query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
test_a9a41a5.t where id + random() < sleep(1)
I0330 06:05:25.601054 9398 coordinator.cc:476]
3c4f9069df52951e:0b97d928] starting execution on 2 backends for
query_id=3c4f9069df52951e:0b97d928
I0330 06:05:25.601359 124 control-service.cc:148]
3c4f9069df52951e:0b97d928] ExecQueryFInstances():
query_id=3c4f9069df52951e:0b97d928
coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
#instances=1
I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
error: Client connection negotiation failed: client connection to
192.168.112.16:27010: connect: Connection refused (error 111)
E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
Exec() rpc failed: Network error: Client connection negotiation failed: client
connection to 192.168.112.16:27010: connect: Connection refused (error 111)
{code}
was:
There is a race condition between admission controller and
executors/executor-group deletion. if a query comes in it could be admitted to
just deleted executor group and the query fails.
{code:java}
I0330 06:05:25.600728 9398 admission-controller.cc:1941]
3c4f9069df52951e:0b97d928] Trying to admit
id=3c4f9069df52951e:0b97d928 in pool_name=root.default
executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
max_mem=48828.12 GB is_trivial_query=false
I0330 06:05:25.600769 9398 admission-controller.cc:1950]
3c4f9069df52951e:0b97d928] Stats: agg_num_running=0, agg_num_queued=0,
agg_mem_reserved=0, local_host(local_mem_admitted=0, local_trivial_running=0,
num_admitted_running=0, num_queued=0, backend_mem_reserved=0, topN_query_stats:
queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
average_per_query=0)
I0330 06:05:25.600816 9398 admission-controller.cc:1300]
3c4f9069df52951e:0b97d928] Admitting query
id=3c4f9069df52951e:0b97d928
I0330 06:05:25.600883 9398 impala-server.cc:2231]
3c4f9069df52951e:0b97d928] Registering query locations
I0330 06:05:25.600898 9398 coordinator.cc:151]
3c4f9069df52951e:0b97d928] Exec()
query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
test_a9a41a5.t where id + random() < sleep(1)
I0330 06:05:25.601054 9398 coordinator.cc:476]
3c4f9069df52951e:0b97d928] starting execution on 2 backends for
query_id=3c4f9069df52951e:0b97d928
I0330 06:05:25.601359 124 control-service.cc:148]
3c4f9069df52951e:0b97d928] ExecQueryFInstances():
query_id=3c4f9069df52951e:0b97d928
coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
#instances=1
I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
error: Client connection negotiation failed: client connection to
192.168.112.16:27010: connect: Connection refused (error 111)
E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
Exec() rpc failed: Network error: Client connection
[jira] [Updated] (IMPALA-12039) Potential Race condition between executor group deletion and admission controller
[
https://issues.apache.org/jira/browse/IMPALA-12039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12039:
Description:
There is a race condition between admission controller and
executors/executor-group deletion. if a query comes in it could be admitted to
just deleted executor group and the query fails.
{code:java}
I0330 06:05:25.600728 9398 admission-controller.cc:1941]
3c4f9069df52951e:0b97d928] Trying to admit
id=3c4f9069df52951e:0b97d928 in pool_name=root.default
executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
max_mem=48828.12 GB is_trivial_query=false
I0330 06:05:25.600769 9398 admission-controller.cc:1950]
3c4f9069df52951e:0b97d928] Stats: agg_num_running=0, agg_num_queued=0,
agg_mem_reserved=0, local_host(local_mem_admitted=0, local_trivial_running=0,
num_admitted_running=0, num_queued=0, backend_mem_reserved=0, topN_query_stats:
queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
average_per_query=0)
I0330 06:05:25.600816 9398 admission-controller.cc:1300]
3c4f9069df52951e:0b97d928] Admitting query
id=3c4f9069df52951e:0b97d928
I0330 06:05:25.600883 9398 impala-server.cc:2231]
3c4f9069df52951e:0b97d928] Registering query locations
I0330 06:05:25.600898 9398 coordinator.cc:151]
3c4f9069df52951e:0b97d928] Exec()
query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
test_a9a41a5.t where id + random() < sleep(1)
I0330 06:05:25.601054 9398 coordinator.cc:476]
3c4f9069df52951e:0b97d928] starting execution on 2 backends for
query_id=3c4f9069df52951e:0b97d928
I0330 06:05:25.601359 124 control-service.cc:148]
3c4f9069df52951e:0b97d928] ExecQueryFInstances():
query_id=3c4f9069df52951e:0b97d928
coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
#instances=1
I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
error: Client connection negotiation failed: client connection to
192.168.112.16:27010: connect: Connection refused (error 111)
E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
Exec() rpc failed: Network error: Client connection negotiation failed: client
connection to 192.168.112.16:27010: connect: Connection refused (error 111)
{code}
was:
IMPALA-11891 added support for deleting executor groups if it's empty. However,
there is a race condition here where if a query comes in it could be admitted
to just deleted executor group and the query fails.
{code:java}
I0330 06:05:25.600728 9398 admission-controller.cc:1941]
3c4f9069df52951e:0b97d928] Trying to admit
id=3c4f9069df52951e:0b97d928 in pool_name=root.default
executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
max_mem=48828.12 GB is_trivial_query=false
I0330 06:05:25.600769 9398 admission-controller.cc:1950]
3c4f9069df52951e:0b97d928] Stats: agg_num_running=0, agg_num_queued=0,
agg_mem_reserved=0, local_host(local_mem_admitted=0, local_trivial_running=0,
num_admitted_running=0, num_queued=0, backend_mem_reserved=0, topN_query_stats:
queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
average_per_query=0)
I0330 06:05:25.600816 9398 admission-controller.cc:1300]
3c4f9069df52951e:0b97d928] Admitting query
id=3c4f9069df52951e:0b97d928
I0330 06:05:25.600883 9398 impala-server.cc:2231]
3c4f9069df52951e:0b97d928] Registering query locations
I0330 06:05:25.600898 9398 coordinator.cc:151]
3c4f9069df52951e:0b97d928] Exec()
query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
test_a9a41a5.t where id + random() < sleep(1)
I0330 06:05:25.601054 9398 coordinator.cc:476]
3c4f9069df52951e:0b97d928] starting execution on 2 backends for
query_id=3c4f9069df52951e:0b97d928
I0330 06:05:25.601359 124 control-service.cc:148]
3c4f9069df52951e:0b97d928] ExecQueryFInstances():
query_id=3c4f9069df52951e:0b97d928
coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
#instances=1
I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
error: Client connection negotiation failed: client connection to
192.168.112.16:27010: connect: Connection refused (error 111)
E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
Exec() rpc failed: Network error:
[jira] [Created] (IMPALA-12039) Potential Race condition between executor group deletion and admission controller
Abhishek Rawat created IMPALA-12039:
---
Summary: Potential Race condition between executor group deletion
and admission controller
Key: IMPALA-12039
URL: https://issues.apache.org/jira/browse/IMPALA-12039
Project: IMPALA
Issue Type: Improvement
Reporter: Abhishek Rawat
IMPALA-11891 added support for deleting executor groups if it's empty. However,
there is a race condition here where if a query comes in it could be admitted
to just deleted executor group and the query fails.
{code:java}
I0330 06:05:25.600728 9398 admission-controller.cc:1941]
3c4f9069df52951e:0b97d928] Trying to admit
id=3c4f9069df52951e:0b97d928 in pool_name=root.default
executor_group_name=root.default-group-000 per_host_mem_estimate=192.22 MB
dedicated_coord_mem_estimate=100.03 MB max_requests=-1 max_queued=200
max_mem=48828.12 GB is_trivial_query=false
I0330 06:05:25.600769 9398 admission-controller.cc:1950]
3c4f9069df52951e:0b97d928] Stats: agg_num_running=0, agg_num_queued=0,
agg_mem_reserved=0, local_host(local_mem_admitted=0, local_trivial_running=0,
num_admitted_running=0, num_queued=0, backend_mem_reserved=0, topN_query_stats:
queries=[7345a69a7cf74870:36a8543f], total_mem_consumed=0;
pool_level_stats: num_running=1, min=0, max=0, pool_total_mem=0,
average_per_query=0)
I0330 06:05:25.600816 9398 admission-controller.cc:1300]
3c4f9069df52951e:0b97d928] Admitting query
id=3c4f9069df52951e:0b97d928
I0330 06:05:25.600883 9398 impala-server.cc:2231]
3c4f9069df52951e:0b97d928] Registering query locations
I0330 06:05:25.600898 9398 coordinator.cc:151]
3c4f9069df52951e:0b97d928] Exec()
query_id=3c4f9069df52951e:0b97d928 stmt=select count(*) from
test_a9a41a5.t where id + random() < sleep(1)
I0330 06:05:25.601054 9398 coordinator.cc:476]
3c4f9069df52951e:0b97d928] starting execution on 2 backends for
query_id=3c4f9069df52951e:0b97d928
I0330 06:05:25.601359 124 control-service.cc:148]
3c4f9069df52951e:0b97d928] ExecQueryFInstances():
query_id=3c4f9069df52951e:0b97d928
coord=coordinator-0.coordinator-int.impala-1680155570-trh7.svc.cluster.local:27000
#instances=1
I0330 06:05:25.601604 117 kudu-status-util.h:55] Exec() rpc failed: Network
error: Client connection negotiation failed: client connection to
192.168.112.16:27010: connect: Connection refused (error 111)
E0330 06:05:25.601706 117 coordinator-backend-state.cc:190]
ExecQueryFInstances rpc query_id=3c4f9069df52951e:0b97d928 failed:
Exec() rpc failed: Network error: Client connection negotiation failed: client
connection to 192.168.112.16:27010: connect: Connection refused (error 111)
{code}
In the past the empty executor group would have been unhealthy and admission
controller would've queued the incoming query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12029) Query can be under parallelized in multi executor group set setup
[ https://issues.apache.org/jira/browse/IMPALA-12029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12029: Priority: Critical (was: Major) > Query can be under parallelized in multi executor group set setup > - > > Key: IMPALA-12029 > URL: https://issues.apache.org/jira/browse/IMPALA-12029 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Affects Versions: Impala 4.2.0 >Reporter: Riza Suminto >Assignee: Riza Suminto >Priority: Critical > > In multiple executor group set setup, Frontend will try to match a query with > the smallest executor group set that can fit the memory and cpu requirement > of the compiled query. There are kind of query where the compiled plan will > fit to any executor group set but not necessarily deliver the best > performance. An example for this is Impala's COMPUTE STATS query. It does > full table scan and aggregate the stats, have fairly simple query plan shape, > but can benefit from higher scan parallelism. > Planner needs to give additional feedback to Frontend that the query might be > under parallelized under current executor group. Frontend can then make > judgement whether to assign the compiled plan to current executor group > anyway, or try step up to the next larger executor group and increase > parallelism. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12036) Web UI incorrectly shows root.default resource pool for all queries in /queries page
[ https://issues.apache.org/jira/browse/IMPALA-12036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12036: Priority: Critical (was: Major) > Web UI incorrectly shows root.default resource pool for all queries in > /queries page > > > Key: IMPALA-12036 > URL: https://issues.apache.org/jira/browse/IMPALA-12036 > Project: IMPALA > Issue Type: Improvement >Reporter: Abhishek Rawat >Assignee: Wenzhe Zhou >Priority: Critical > > Web UI seems to be always showing root.default resource pool even if a > different resource pool is used by the query. I also forced a different > resource pool by using `set REQUEST_POOL=root.group-set-00`, but Web UI still > showed `root.default`. This is reflected correctly in the query profiles but > not in the Web UI. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-12036) Web UI incorrectly shows root.default resource pool for all queries in /queries page
[ https://issues.apache.org/jira/browse/IMPALA-12036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-12036: --- Assignee: Wenzhe Zhou (was: Kurt Deschler) > Web UI incorrectly shows root.default resource pool for all queries in > /queries page > > > Key: IMPALA-12036 > URL: https://issues.apache.org/jira/browse/IMPALA-12036 > Project: IMPALA > Issue Type: Improvement >Reporter: Abhishek Rawat >Assignee: Wenzhe Zhou >Priority: Major > > Web UI seems to be always showing root.default resource pool even if a > different resource pool is used by the query. I also forced a different > resource pool by using `set REQUEST_POOL=root.group-set-00`, but Web UI still > showed `root.default`. This is reflected correctly in the query profiles but > not in the Web UI. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12036) Web UI incorrectly shows root.default resource pool for all queries in /queries page
[ https://issues.apache.org/jira/browse/IMPALA-12036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12036: Summary: Web UI incorrectly shows root.default resource pool for all queries in /queries page (was: Web UI incorreclty shows root.default resource pool for all queries in /queries page) > Web UI incorrectly shows root.default resource pool for all queries in > /queries page > > > Key: IMPALA-12036 > URL: https://issues.apache.org/jira/browse/IMPALA-12036 > Project: IMPALA > Issue Type: Improvement >Reporter: Abhishek Rawat >Priority: Major > > Web UI seems to be always showing root.default resource pool even if a > different resource pool is used by the query. I also forced a different > resource pool by using `set REQUEST_POOL=root.group-set-00`, but Web UI still > showed `root.default`. This is reflected correctly in the query profiles but > not in the Web UI. > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12036) Web UI incorreclty shows root.default resource pool for all queries in /queries page
Abhishek Rawat created IMPALA-12036: --- Summary: Web UI incorreclty shows root.default resource pool for all queries in /queries page Key: IMPALA-12036 URL: https://issues.apache.org/jira/browse/IMPALA-12036 Project: IMPALA Issue Type: Improvement Reporter: Abhishek Rawat Web UI seems to be always showing root.default resource pool even if a different resource pool is used by the query. I also forced a different resource pool by using `set REQUEST_POOL=root.group-set-00`, but Web UI still showed `root.default`. This is reflected correctly in the query profiles but not in the Web UI. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-11989) ImpalaRuntimeException if Kudu and Impala use different HMS
[
https://issues.apache.org/jira/browse/IMPALA-11989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat resolved IMPALA-11989.
-
Target Version: Impala 4.3.0
Resolution: Fixed
> ImpalaRuntimeException if Kudu and Impala use different HMS
> ---
>
> Key: IMPALA-11989
> URL: https://issues.apache.org/jira/browse/IMPALA-11989
> Project: IMPALA
> Issue Type: Task
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Major
>
> Kudu and Impala could use different HMS instances such that both these HMS
> instances use a common backend store. Since HMS itself doesn't store any
> state, this should not be a runtime exception.
> {code:java}
> ImpalaRuntimeException: Kudu is integrated with a different Hive Metastore
> than that used by Impala, Kudu is configured to use the HMS:
> thrift://test-kudu-impala-dl-master0.test-kud.xcu2-8y8x.dev.cldr.work:9083,
> while Impala is configured to use the HMS:
> thrift://metastore-service.warehouse-1671643788-qfgt.svc.cluster.local:9083
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12026) admissiond could have unreasonably large allocations
Abhishek Rawat created IMPALA-12026:
---
Summary: admissiond could have unreasonably large allocations
Key: IMPALA-12026
URL: https://issues.apache.org/jira/browse/IMPALA-12026
Project: IMPALA
Issue Type: Bug
Reporter: Abhishek Rawat
Noticed admissiond was getting OOMKilled with following large allocations:
{code:java}
tcmalloc: large alloc 1207959552 bytes == 0x7f9706c1e000 @ 0x398f15c 0x15adaa7
0x15a4241 0x15a9773 0x15a90f0 0x15a90f0 0x15a99b1 0x15aa55e 0x151ea9a 0x151f234
0x152280b 0x1534bf7 0x157c │
│ tcmalloc: large alloc 2415919104 bytes == 0x7f966f41e000 @ 0x398f15c
0x15adaa7 0x15a4241 0x15a9773 0x15a90f0 0x15a90f0 0x15a99b1 0x15aa55e 0x151ea9a
0x151f234 0x152280b 0x1534bf7 0x157c │
│ tcmalloc: large alloc 4831838208 bytes == 0x7f954091e000 @ 0x398f15c
0x15adaa7 0x15a4241 0x15a9773 0x15a90f0 0x15a90f0 0x15a99b1 0x15aa55e 0x151ea9a
0x151f234 0x152280b 0x1534bf7 0x157c │
│ tcmalloc: large alloc 9663676416 bytes == 0x7f92e351e000 @ 0x398f15c
0x15adaa7 0x15a4241 0x15a9773 0x15a90f0 0x15a90f0 0x15a99b1 0x15aa55e 0x151ea9a
0x151f234 0x152280b 0x1534bf7 0x157c │
│ tcmalloc: large alloc 19327352832 bytes == 0x7f8e2831e000 @ 0x398f15c
0x15adaa7 0x15a4241 0x15a9773 0x15a90f0 0x15a90f0 0x15a99b1 0x15aa55e 0x151ea9a
0x151f234 0x152280b 0x1534bf7 0x157 │ {code}
Some of the allocations are 2G, 4G, 8G, ~18G which are all unexpected.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12016) Web UI could crash browser tab when trying to load huge query profiles
[ https://issues.apache.org/jira/browse/IMPALA-12016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12016: Summary: Web UI could crash browser tab when trying to load huge query profiles (was: Web UI could crash when trying to load huge query profiles) > Web UI could crash browser tab when trying to load huge query profiles > -- > > Key: IMPALA-12016 > URL: https://issues.apache.org/jira/browse/IMPALA-12016 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Priority: Critical > > Query profiles could get huge especially for complex queries and if someone > tries to view the profiles from the Web UI, it could result in crashing the > browser tab. It would be good to split bigger profiles into meaningful > chunks, and only load these chunks in the WebUI on demand. Also, would be > useful to be able to download these bigger profiles without having to render > them (which is what causes browser tab to crash when the profiles are much > bigger than what browsers can support). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12016) Web UI could crash when trying to load huge query profiles
Abhishek Rawat created IMPALA-12016: --- Summary: Web UI could crash when trying to load huge query profiles Key: IMPALA-12016 URL: https://issues.apache.org/jira/browse/IMPALA-12016 Project: IMPALA Issue Type: Task Reporter: Abhishek Rawat Query profiles could get huge especially for complex queries and if someone tries to view the profiles from the Web UI, it could result in crashing the browser tab. It would be good to split bigger profiles into meaningful chunks, and only load these chunks in the WebUI on demand. Also, would be useful to be able to download these bigger profiles without having to render them (which is what causes browser tab to crash when the profiles are much bigger than what browsers can support). -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12015) enable healthz endpoint in admissiond webui
[ https://issues.apache.org/jira/browse/IMPALA-12015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-12015: Summary: enable healthz endpoint in admissiond webui (was: enable healthz endpoint for admissiond webui) > enable healthz endpoint in admissiond webui > --- > > Key: IMPALA-12015 > URL: https://issues.apache.org/jira/browse/IMPALA-12015 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > A '/healthz' endpoint indicating admission service's readiness could be > useful for external clients trying to determine readiness of admissiond's > service. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-12015) enable healthz endpoint for admissiond webui
Abhishek Rawat created IMPALA-12015: --- Summary: enable healthz endpoint for admissiond webui Key: IMPALA-12015 URL: https://issues.apache.org/jira/browse/IMPALA-12015 Project: IMPALA Issue Type: Task Reporter: Abhishek Rawat Assignee: Abhishek Rawat A '/healthz' endpoint indicating admission service's readiness could be useful for external clients trying to determine readiness of admissiond's service. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-12005) Explain executor group set selection criteria in query profile
[
https://issues.apache.org/jira/browse/IMPALA-12005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-12005:
Priority: Critical (was: Major)
> Explain executor group set selection criteria in query profile
> --
>
> Key: IMPALA-12005
> URL: https://issues.apache.org/jira/browse/IMPALA-12005
> Project: IMPALA
> Issue Type: Improvement
> Components: Frontend
>Affects Versions: Impala 4.2.0
>Reporter: Riza Suminto
>Assignee: Riza Suminto
>Priority: Critical
>
> [IMPALA-10992|http://issues.cloudera.org/browse/IMPALA-10992] and
> [IMPALA-11604|http://issues.cloudera.org/browse/IMPALA-11604] adds memory
> and cpu constraint criteria for executor group set selection. We should
> explain this selection criteria in query profile. Things that we should
> consider adding to query profile:
> * The effective degree of parallelism (EDoP) value that was used to
> calculate fitness for a given group. Possibly some additional details about
> how we got to that EDoP like the per fragment values.
> * Per host memory estimate for that group.
> * Reason for not choosing a given group (if any) - was it based on memory or
> CPU, what thresholds were we comparing to, etc.
> In the event of none executor group set is fit, the returned
> AnalysisException also need to provide more context. Right now, only these
> are returned:
> {code:java}
> AnalysisException: The query does not fit any executor group sets. {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11604) Planner changes for CPU usage
[ https://issues.apache.org/jira/browse/IMPALA-11604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11604: Priority: Critical (was: Major) > Planner changes for CPU usage > - > > Key: IMPALA-11604 > URL: https://issues.apache.org/jira/browse/IMPALA-11604 > Project: IMPALA > Issue Type: Improvement >Reporter: Qifan Chen >Assignee: Riza Suminto >Priority: Critical > Fix For: Impala 4.3.0 > > > Plan scaling based on estimated peak memory has been enabled in > IMPALA-10992. However, it is sometime desirable to consider CPU-usage (such > as the number of data processed) as a scaling factor. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11997) impala-shell: base64.encodestring has been removed in python3.9
Abhishek Rawat created IMPALA-11997:
---
Summary: impala-shell: base64.encodestring has been removed in
python3.9
Key: IMPALA-11997
URL: https://issues.apache.org/jira/browse/IMPALA-11997
Project: IMPALA
Issue Type: Task
Reporter: Abhishek Rawat
When using impala-shell v4.2 with python 3.10 I get following error:
{code:java}
Starting Impala Shell with LDAP-based authentication using Python 3.10.10
SSL is enabled. Impala server certificates will NOT be verified (set --ca_cert
to change)
LDAP password for csso_arawat:
Warning: --connect_timeout_ms is currently ignored with HTTP transport.
Error connecting: AttributeError, module 'base64' has no attribute
'encodestring'
klist: Cache not found: API:2AC1D3D7-13D7-4DD7-BEA7-DF0F4A32A462
***
Welcome to the Impala shell.
(Impala Shell v4.3.0a1 (cda4114) built on Thu Feb 2 18:18:16 PST 2023)
The HISTORY command lists all shell commands in chronological order. {code}
I only found one hit:
{code:java}
root@impala:~/Impala# git grep -i 'encodestring'
shell/impala_client.py: auth =
base64.encodestring(user_passwd.encode()).decode().strip('\n') {code}
We should probably use 'base64.encodebytes' instead.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-11989) ImpalaRuntimeException if Kudu and Impala use different HMS
[
https://issues.apache.org/jira/browse/IMPALA-11989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat reassigned IMPALA-11989:
---
Assignee: Abhishek Rawat
> ImpalaRuntimeException if Kudu and Impala use different HMS
> ---
>
> Key: IMPALA-11989
> URL: https://issues.apache.org/jira/browse/IMPALA-11989
> Project: IMPALA
> Issue Type: Task
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Major
>
> Kudu and Impala could use different HMS instances such that both these HMS
> instances use a common backend store. Since HMS itself doesn't store any
> state, this should not be a runtime exception.
> {code:java}
> ImpalaRuntimeException: Kudu is integrated with a different Hive Metastore
> than that used by Impala, Kudu is configured to use the HMS:
> thrift://test-kudu-impala-dl-master0.test-kud.xcu2-8y8x.dev.cldr.work:9083,
> while Impala is configured to use the HMS:
> thrift://metastore-service.warehouse-1671643788-qfgt.svc.cluster.local:9083
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11989) ImpalaRuntimeException if Kudu and Impala use different HMS
Abhishek Rawat created IMPALA-11989:
---
Summary: ImpalaRuntimeException if Kudu and Impala use different
HMS
Key: IMPALA-11989
URL: https://issues.apache.org/jira/browse/IMPALA-11989
Project: IMPALA
Issue Type: Task
Reporter: Abhishek Rawat
Kudu and Impala could use different HMS instances such that both these HMS
instances use a common backend store. Since HMS itself doesn't store any
state, this should not be a runtime exception.
{code:java}
ImpalaRuntimeException: Kudu is integrated with a different Hive Metastore than
that used by Impala, Kudu is configured to use the HMS:
thrift://test-kudu-impala-dl-master0.test-kud.xcu2-8y8x.dev.cldr.work:9083,
while Impala is configured to use the HMS:
thrift://metastore-service.warehouse-1671643788-qfgt.svc.cluster.local:9083
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Closed] (IMPALA-11890) Expose 'healthz' endpoint in metrics webserver of statestored and catalogd
[ https://issues.apache.org/jira/browse/IMPALA-11890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat closed IMPALA-11890. --- Target Version: Impala 4.3.0 Assignee: Abhishek Rawat Resolution: Fixed > Expose 'healthz' endpoint in metrics webserver of statestored and catalogd > -- > > Key: IMPALA-11890 > URL: https://issues.apache.org/jira/browse/IMPALA-11890 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Critical > > The healthz endpoint is already enabled in metrics webserver of impalads. It > makes sense to enable these endpoints in metrics webserver of catalogd and > statestored. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11626) Handle COMMIT_COMPACTION_EVENT from HMS
[ https://issues.apache.org/jira/browse/IMPALA-11626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11626: Priority: Critical (was: Major) > Handle COMMIT_COMPACTION_EVENT from HMS > --- > > Key: IMPALA-11626 > URL: https://issues.apache.org/jira/browse/IMPALA-11626 > Project: IMPALA > Issue Type: Improvement > Components: Catalog >Reporter: Csaba Ringhofer >Assignee: Sai Hemanth Gantasala >Priority: Critical > Labels: ACID > > Since HIVE-24329 HMS emits an event when a compaction is committed, but > Impala ignores it. Handling it would allow automatic refreshing after > compactions. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11822) Optimize the Refresh/Invalidate event processing by skipping unnecessary events
[ https://issues.apache.org/jira/browse/IMPALA-11822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11822: Priority: Critical (was: Major) > Optimize the Refresh/Invalidate event processing by skipping unnecessary > events > --- > > Key: IMPALA-11822 > URL: https://issues.apache.org/jira/browse/IMPALA-11822 > Project: IMPALA > Issue Type: Improvement > Components: Catalog >Reporter: Sai Hemanth Gantasala >Assignee: Sai Hemanth Gantasala >Priority: Critical > > Optimize the Refresh/Invalidate event processing by skipping unnecessary > events. > Currently, we process every event as a new event. Consider there are 5 > refresh events of the same table in the event processor queue. We can process > the first refresh event and skip the remaining 4 events by comparing the > timestamp of the refreshed table and event time. This way we can greatly > improve the performance by skipping unnecessary events. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11890) Expose 'healthz' endpoint in metrics webserver of statestored and catalogd
Abhishek Rawat created IMPALA-11890: --- Summary: Expose 'healthz' endpoint in metrics webserver of statestored and catalogd Key: IMPALA-11890 URL: https://issues.apache.org/jira/browse/IMPALA-11890 Project: IMPALA Issue Type: Task Reporter: Abhishek Rawat The healthz endpoint is already enabled in metrics webserver of impalads. It makes sense to enable these endpoints in metrics webserver of catalogd and statestored. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11842) Improve memory estimation for streaming aggregate operator
[
https://issues.apache.org/jira/browse/IMPALA-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-11842:
Priority: Critical (was: Major)
> Improve memory estimation for streaming aggregate operator
> --
>
> Key: IMPALA-11842
> URL: https://issues.apache.org/jira/browse/IMPALA-11842
> Project: IMPALA
> Issue Type: Bug
>Reporter: Abhishek Rawat
>Priority: Critical
>
> Streaming aggregate operator can over estimate the peak memory and as a
> result Impala could request max memory allowed by admission controller. This
> impacts query concurrency and also causes unnecessary scaling.
> Looking at some cases in the following profile snippet, the estimated peak
> memory (8.15 GB) is *20X* from actual peak memory (416.07 MB).
> {code:java}
> Estimated Per-Host Mem: 247067273376
> Request Pool: root.default
> Per Host Min Memory Reservation: impala-executor-003-5:27010(1.34 GB)
> impala-executor-003-4:27010(1.35 GB) impala-executor-003-6:27010(1.34 GB)
> impala-executor-003-0:27010(1.35 GB) impala-executor-003-8:27010(1.35 GB)
> impala-executor-003-2:27010(1.34 GB) impala-executor-003-1:27010(1.35 GB)
> coordinator-0.coordinator-int.impala-dylan-impala.svc.cluster.local:27000(4.00
> MB) impala-executor-003-3:27010(1.34 GB) impala-executor-003-9:27010(1.34
> GB) impala-executor-003-7:27010(1.35 GB)
> Per Host Number of Fragment Instances: impala-executor-003-5:27010(37)
> impala-executor-003-4:27010(38) impala-executor-003-6:27010(37)
> impala-executor-003-0:27010(38) impala-executor-003-8:27010(38)
> impala-executor-003-2:27010(37) impala-executor-003-1:27010(38)
> coordinator-0.coordinator-int.impala-dylan-impala.svc.cluster.local:27000(1)
> impala-executor-003-3:27010(37) impala-executor-003-9:27010(37)
> impala-executor-003-7:27010(38)
> Latest admission queue reason: Not enough memory available on host
> impala-executor-003-5:27010. Needed 50.00 GB but only 33.06 GB out of 83.06
> GB was available.
> Admission result: Admitted (queued)
> Initial admission queue reason: waited 83020 ms, reason: Not enough
> memory available on host impala-executor-003-5:27010. Needed 50.00 GB but
> only 33.06 GB out of 83.06 GB was available.
> Cluster Memory Admitted: 500.10 GB
> Executor Group: root.default-group-002
> ExecSummary:
> Operator #Hosts #Inst Avg Time Max Time#Rows Est.
> #Rows Peak Mem Est. Peak Mem Detail
> -
> F04:ROOT 1 1 146.192us 146.192us
>4.01 MB4.00 MB
> 11:MERGING-EXCHANGE 1 13.297ms3.297ms 100
> 1001.88 MB 234.53 KB UNPARTITIONED
> F03:EXCHANGE SENDER 101204.196ms 374.168ms
>7.52 KB 0
> 05:TOP-N 10120 22.184ms1s028ms 12.00K
> 100 16.00 KB1.56 KB
> 10:AGGREGATE 10120 4m2s 12m14s 499.98K
> 487.66K2.34 MB 10.00 MB FINALIZE
> 09:EXCHANGE 101205s336ms7s799ms 22.11B
> 487.66K 10.40 MB3.09 MB HASH(vendor_id)
> F02:EXCHANGE SENDER 10120 28s199ms 48s974ms
>4.16 MB 0
> 04:AGGREGATE 10120 1m17s 1m34s 22.11B
> 487.66K 21.02 MB 10.00 MB STREAMING
> 08:AGGREGATE 10120 12m29s 22m36s 50.00B
> 50.00B3.85 GB 10.87 GB
> 07:EXCHANGE 10120 10s165ms 12s246ms 50.00B
> 50.00B 11.69 MB 12.34 MB HASH(vendor_id,purchase_id)
> F00:EXCHANGE SENDER 10120 1m28s 1m49s
>4.16 MB 0
> 03:AGGREGATE 10120 2m34s 5m5s 50.00B
> 50.00B 416.07 MB8.15 GB STREAMING
> 02:HASH JOIN 10120 1m17s 1m40s 50.00B
> 50.00B 46.12 KB 0 INNER JOIN, BROADCAST
> |--F05:JOIN BUILD10 10 557.800ms 613.307ms
> 408.02 MB 408.00 MB
> | 06:EXCHANGE 10 10 88.770ms 102.048ms5.00M
> 5.00M 16.11 MB 10.10 MB BROADCAST
> | F01:EXCHANGE
[jira] [Updated] (IMPALA-11858) admissiond incorrectly caps memory limit to its process memory
[ https://issues.apache.org/jira/browse/IMPALA-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11858: Priority: Critical (was: Major) > admissiond incorrectly caps memory limit to its process memory > -- > > Key: IMPALA-11858 > URL: https://issues.apache.org/jira/browse/IMPALA-11858 > Project: IMPALA > Issue Type: Bug >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Critical > > When admission controller is running as a separate daemon it incorrectly caps > memory limit for the query to its process limit. This is also incorrect > behavior when admission controller is running in coordinator as executors > could have different memory limit compared to coordinator. > https://github.com/apache/impala/blob/master/be/src/scheduling/schedule-state.cc#L312#L313 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-9828) Add support for spilling to Remote Storage
[ https://issues.apache.org/jira/browse/IMPALA-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-9828: --- Summary: Add support for spilling to Remote Storage (was: Add support for spilling to S3) > Add support for spilling to Remote Storage > -- > > Key: IMPALA-9828 > URL: https://issues.apache.org/jira/browse/IMPALA-9828 > Project: IMPALA > Issue Type: Epic > Components: Backend >Reporter: Abhishek Rawat >Assignee: Yida Wu >Priority: Major > > Epic for spill to S3 support. > Design doc: > https://docs.google.com/document/d/1j3FtnzIu-t-VSz6ySy-BC-fP9CNf6AiqdkkLxoep6Kg/edit?usp=sharing -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11858) admissiond incorrectly caps memory limit to its process memory
Abhishek Rawat created IMPALA-11858: --- Summary: admissiond incorrectly caps memory limit to its process memory Key: IMPALA-11858 URL: https://issues.apache.org/jira/browse/IMPALA-11858 Project: IMPALA Issue Type: Bug Reporter: Abhishek Rawat When admission controller is running as a separate daemon it incorrectly caps memory limit for the query to its process limit. This is also incorrect behavior when admission controller is running in coordinator as executors could have different memory limit compared to coordinator. https://github.com/apache/impala/blob/master/be/src/scheduling/schedule-state.cc#L312#L313 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-11858) admissiond incorrectly caps memory limit to its process memory
[ https://issues.apache.org/jira/browse/IMPALA-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-11858: --- Assignee: Abhishek Rawat > admissiond incorrectly caps memory limit to its process memory > -- > > Key: IMPALA-11858 > URL: https://issues.apache.org/jira/browse/IMPALA-11858 > Project: IMPALA > Issue Type: Bug >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > When admission controller is running as a separate daemon it incorrectly caps > memory limit for the query to its process limit. This is also incorrect > behavior when admission controller is running in coordinator as executors > could have different memory limit compared to coordinator. > https://github.com/apache/impala/blob/master/be/src/scheduling/schedule-state.cc#L312#L313 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-11804) Use proper capacity for base 10 storage units
[ https://issues.apache.org/jira/browse/IMPALA-11804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-11804: --- Assignee: Jason Fehr > Use proper capacity for base 10 storage units > - > > Key: IMPALA-11804 > URL: https://issues.apache.org/jira/browse/IMPALA-11804 > Project: IMPALA > Issue Type: Task > Components: Backend >Reporter: Abhishek Rawat >Assignee: Jason Fehr >Priority: Major > > Most cloud vendors advertise storage in base 10 units such as KB, MB, GB, TB. > Impala considers these storage units to be base 2. This could cause issue > because when configuring data_cache or scratch_space Impala could try to use > more capacity than what the underlying storage provides. > It's okay for Impala to use base 2 units, but it should support configs using > base 10 units and also use proper units (KiB, MiB, GiB, TiB) internally and > everywhere else such as web UI, query profile, etc. > The logic for parsing memory configs is here: > [https://github.com/apache/impala/blob/master/be/src/util/parse-util.cc#L39] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-11827) do not cache admission control service's IP address in coordinator
[ https://issues.apache.org/jira/browse/IMPALA-11827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat resolved IMPALA-11827. - Fix Version/s: Impala 4.3.0 Resolution: Fixed > do not cache admission control service's IP address in coordinator > -- > > Key: IMPALA-11827 > URL: https://issues.apache.org/jira/browse/IMPALA-11827 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > Fix For: Impala 4.3.0 > > > The Impalad's ExecEnv caches resolved IP address for admission control > service: > [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] > The Impala server runs a heart beat thread for admission control service and > it relies on the cached resolved address in ExecEnv: > [https://github.com/apache/impala/blob/master/be/src/service/impala-server.cc#L584] > This breaks when IP address for admission control services changes and so we > shouldn't cache dynamic addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11842) Improve memory estimation for streaming aggregate operator
[
https://issues.apache.org/jira/browse/IMPALA-11842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat updated IMPALA-11842:
Description:
Streaming aggregate operator can over estimate the peak memory and as a result
Impala could request max memory allowed by admission controller. This impacts
query concurrency and also causes unnecessary scaling.
Looking at some cases in the following profile snippet, the estimated peak
memory (8.15 GB) is *20X* from actual peak memory (416.07 MB).
{code:java}
Estimated Per-Host Mem: 247067273376
Request Pool: root.default
Per Host Min Memory Reservation: impala-executor-003-5:27010(1.34 GB)
impala-executor-003-4:27010(1.35 GB) impala-executor-003-6:27010(1.34 GB)
impala-executor-003-0:27010(1.35 GB) impala-executor-003-8:27010(1.35 GB)
impala-executor-003-2:27010(1.34 GB) impala-executor-003-1:27010(1.35 GB)
coordinator-0.coordinator-int.impala-dylan-impala.svc.cluster.local:27000(4.00
MB) impala-executor-003-3:27010(1.34 GB) impala-executor-003-9:27010(1.34 GB)
impala-executor-003-7:27010(1.35 GB)
Per Host Number of Fragment Instances: impala-executor-003-5:27010(37)
impala-executor-003-4:27010(38) impala-executor-003-6:27010(37)
impala-executor-003-0:27010(38) impala-executor-003-8:27010(38)
impala-executor-003-2:27010(37) impala-executor-003-1:27010(38)
coordinator-0.coordinator-int.impala-dylan-impala.svc.cluster.local:27000(1)
impala-executor-003-3:27010(37) impala-executor-003-9:27010(37)
impala-executor-003-7:27010(38)
Latest admission queue reason: Not enough memory available on host
impala-executor-003-5:27010. Needed 50.00 GB but only 33.06 GB out of 83.06 GB
was available.
Admission result: Admitted (queued)
Initial admission queue reason: waited 83020 ms, reason: Not enough memory
available on host impala-executor-003-5:27010. Needed 50.00 GB but only 33.06
GB out of 83.06 GB was available.
Cluster Memory Admitted: 500.10 GB
Executor Group: root.default-group-002
ExecSummary:
Operator #Hosts #Inst Avg Time Max Time#Rows Est.
#Rows Peak Mem Est. Peak Mem Detail
-
F04:ROOT 1 1 146.192us 146.192us
4.01 MB4.00 MB
11:MERGING-EXCHANGE 1 13.297ms3.297ms 100
1001.88 MB 234.53 KB UNPARTITIONED
F03:EXCHANGE SENDER 101204.196ms 374.168ms
7.52 KB 0
05:TOP-N 10120 22.184ms1s028ms 12.00K
100 16.00 KB1.56 KB
10:AGGREGATE 10120 4m2s 12m14s 499.98K
487.66K2.34 MB 10.00 MB FINALIZE
09:EXCHANGE 101205s336ms7s799ms 22.11B
487.66K 10.40 MB3.09 MB HASH(vendor_id)
F02:EXCHANGE SENDER 10120 28s199ms 48s974ms
4.16 MB 0
04:AGGREGATE 10120 1m17s 1m34s 22.11B
487.66K 21.02 MB 10.00 MB STREAMING
08:AGGREGATE 10120 12m29s 22m36s 50.00B
50.00B3.85 GB 10.87 GB
07:EXCHANGE 10120 10s165ms 12s246ms 50.00B
50.00B 11.69 MB 12.34 MB HASH(vendor_id,purchase_id)
F00:EXCHANGE SENDER 10120 1m28s 1m49s
4.16 MB 0
03:AGGREGATE 10120 2m34s 5m5s 50.00B
50.00B 416.07 MB8.15 GB STREAMING
02:HASH JOIN 10120 1m17s 1m40s 50.00B
50.00B 46.12 KB 0 INNER JOIN, BROADCAST
|--F05:JOIN BUILD10 10 557.800ms 613.307ms
408.02 MB 408.00 MB
| 06:EXCHANGE 10 10 88.770ms 102.048ms5.00M
5.00M 16.11 MB 10.10 MB BROADCAST
| F01:EXCHANGE SENDER5 5 190.673ms 212.904ms
75.23 KB 0
| 00:SCAN HDFS 5 5 774.428ms 965.865ms5.00M
5.00M 12.92 MB 64.00 MB tab.product
01:SCAN HDFS 10120 5m48s 13m14s 50.00B
50.00B 32.92 MB 88.00 MB tab.pli {code}
was:
Streaming aggregate operator can over estimate the peak memory and as a result
Impala could request max memory allowed by
[jira] [Created] (IMPALA-11842) Improve memory estimation for streaming aggregate operator
Abhishek Rawat created IMPALA-11842:
---
Summary: Improve memory estimation for streaming aggregate operator
Key: IMPALA-11842
URL: https://issues.apache.org/jira/browse/IMPALA-11842
Project: IMPALA
Issue Type: Bug
Reporter: Abhishek Rawat
Streaming aggregate operator can over estimate the peak memory and as a result
Impala could request max memory allowed by admission controller. This impacts
query concurrency and also causes unnecessary scaling.
Looking at some cases in the following profile snippet, the estimated peak
memory (8.15 GB) is *20X* from actual peak memory (416.07 MB). I'll file a JIRA.
{code:java}
Estimated Per-Host Mem: 247067273376
Request Pool: root.default
Per Host Min Memory Reservation: impala-executor-003-5:27010(1.34 GB)
impala-executor-003-4:27010(1.35 GB) impala-executor-003-6:27010(1.34 GB)
impala-executor-003-0:27010(1.35 GB) impala-executor-003-8:27010(1.35 GB)
impala-executor-003-2:27010(1.34 GB) impala-executor-003-1:27010(1.35 GB)
coordinator-0.coordinator-int.impala-dylan-impala.svc.cluster.local:27000(4.00
MB) impala-executor-003-3:27010(1.34 GB) impala-executor-003-9:27010(1.34 GB)
impala-executor-003-7:27010(1.35 GB)
Per Host Number of Fragment Instances: impala-executor-003-5:27010(37)
impala-executor-003-4:27010(38) impala-executor-003-6:27010(37)
impala-executor-003-0:27010(38) impala-executor-003-8:27010(38)
impala-executor-003-2:27010(37) impala-executor-003-1:27010(38)
coordinator-0.coordinator-int.impala-dylan-impala.svc.cluster.local:27000(1)
impala-executor-003-3:27010(37) impala-executor-003-9:27010(37)
impala-executor-003-7:27010(38)
Latest admission queue reason: Not enough memory available on host
impala-executor-003-5:27010. Needed 50.00 GB but only 33.06 GB out of 83.06 GB
was available.
Admission result: Admitted (queued)
Initial admission queue reason: waited 83020 ms, reason: Not enough memory
available on host impala-executor-003-5:27010. Needed 50.00 GB but only 33.06
GB out of 83.06 GB was available.
Cluster Memory Admitted: 500.10 GB
Executor Group: root.default-group-002
ExecSummary:
Operator #Hosts #Inst Avg Time Max Time#Rows Est.
#Rows Peak Mem Est. Peak Mem Detail
-
F04:ROOT 1 1 146.192us 146.192us
4.01 MB4.00 MB
11:MERGING-EXCHANGE 1 13.297ms3.297ms 100
1001.88 MB 234.53 KB UNPARTITIONED
F03:EXCHANGE SENDER 101204.196ms 374.168ms
7.52 KB 0
05:TOP-N 10120 22.184ms1s028ms 12.00K
100 16.00 KB1.56 KB
10:AGGREGATE 10120 4m2s 12m14s 499.98K
487.66K2.34 MB 10.00 MB FINALIZE
09:EXCHANGE 101205s336ms7s799ms 22.11B
487.66K 10.40 MB3.09 MB HASH(vendor_id)
F02:EXCHANGE SENDER 10120 28s199ms 48s974ms
4.16 MB 0
04:AGGREGATE 10120 1m17s 1m34s 22.11B
487.66K 21.02 MB 10.00 MB STREAMING
08:AGGREGATE 10120 12m29s 22m36s 50.00B
50.00B3.85 GB 10.87 GB
07:EXCHANGE 10120 10s165ms 12s246ms 50.00B
50.00B 11.69 MB 12.34 MB HASH(vendor_id,purchase_id)
F00:EXCHANGE SENDER 10120 1m28s 1m49s
4.16 MB 0
03:AGGREGATE 10120 2m34s 5m5s 50.00B
50.00B 416.07 MB8.15 GB STREAMING
02:HASH JOIN 10120 1m17s 1m40s 50.00B
50.00B 46.12 KB 0 INNER JOIN, BROADCAST
|--F05:JOIN BUILD10 10 557.800ms 613.307ms
408.02 MB 408.00 MB
| 06:EXCHANGE 10 10 88.770ms 102.048ms5.00M
5.00M 16.11 MB 10.10 MB BROADCAST
| F01:EXCHANGE SENDER5 5 190.673ms 212.904ms
75.23 KB 0
| 00:SCAN HDFS 5 5 774.428ms 965.865ms5.00M
5.00M 12.92 MB 64.00 MB tab.product
01:SCAN HDFS 10120 5m48s 13m14s 50.00B
50.00B 32.92 MB
[jira] [Updated] (IMPALA-11827) do not cache admission control service's IP address in coordinator
[ https://issues.apache.org/jira/browse/IMPALA-11827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11827: Description: The Impalad's ExecEnv caches resolved IP address for admission control service: [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] The Impala server runs a heart beat thread for admission control service and it relies on the cached resolved address in ExecEnv: [https://github.com/apache/impala/blob/master/be/src/service/impala-server.cc#L584] This breaks when IP address for admission control services changes and so we shouldn't cache dynamic addresses. was: The Impalad's ExecEnv caches resolved IP address for admission control service: [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] The Impala server runs a heart beat thread for admission control service and it relies on the cached resolved address in ExecEnv: https://github.com/apache/impala/blob/master/be/src/service/impala-server.cc#L584 This breaks when IP address for admission control services changes (post a restart) and so we shouldn't cache dynamic addresses. > do not cache admission control service's IP address in coordinator > -- > > Key: IMPALA-11827 > URL: https://issues.apache.org/jira/browse/IMPALA-11827 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > The Impalad's ExecEnv caches resolved IP address for admission control > service: > [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] > The Impala server runs a heart beat thread for admission control service and > it relies on the cached resolved address in ExecEnv: > [https://github.com/apache/impala/blob/master/be/src/service/impala-server.cc#L584] > This breaks when IP address for admission control services changes and so we > shouldn't cache dynamic addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11827) do not cache admission control service's IP address in coordinator
[ https://issues.apache.org/jira/browse/IMPALA-11827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11827: Description: The Impalad's ExecEnv caches resolved IP address for admission control service: [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] The Impala server runs a heart beat thread for admission control service and it relies on the cached resolved address in ExecEnv: https://github.com/apache/impala/blob/master/be/src/service/impala-server.cc#L584 This breaks when IP address for admission control services changes (post a restart) and so we shouldn't cache dynamic addresses. was: The Impalad's ExecEnv caches resolved IP address for admission control service: [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] The Impala server run a heart beat thread for admission control service and it relies on the cached resolved address in ExecEnv. This breaks when IP address for admission control services changes (post a restart) and so we shouldn't cache dynamic addresses. > do not cache admission control service's IP address in coordinator > -- > > Key: IMPALA-11827 > URL: https://issues.apache.org/jira/browse/IMPALA-11827 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > The Impalad's ExecEnv caches resolved IP address for admission control > service: > [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] > The Impala server runs a heart beat thread for admission control service and > it relies on the cached resolved address in ExecEnv: > https://github.com/apache/impala/blob/master/be/src/service/impala-server.cc#L584 > This breaks when IP address for admission control services changes (post a > restart) and so we shouldn't cache dynamic addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-11827) do not cache admission control service's IP address in coordinator
[ https://issues.apache.org/jira/browse/IMPALA-11827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat reassigned IMPALA-11827: --- Assignee: Abhishek Rawat > do not cache admission control service's IP address in coordinator > -- > > Key: IMPALA-11827 > URL: https://issues.apache.org/jira/browse/IMPALA-11827 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Assignee: Abhishek Rawat >Priority: Major > > The Impalad's ExecEnv caches resolved IP address for admission control > service: > [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] > The Impala server run a heart beat thread for admission control service and > it relies on the cached resolved address in ExecEnv. This breaks when IP > address for admission control services changes (post a restart) and so we > shouldn't cache dynamic addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11827) do not cache admission control service's IP address in coordinator
Abhishek Rawat created IMPALA-11827: --- Summary: do not cache admission control service's IP address in coordinator Key: IMPALA-11827 URL: https://issues.apache.org/jira/browse/IMPALA-11827 Project: IMPALA Issue Type: Task Reporter: Abhishek Rawat The Impalad's ExecEnv caches resolved IP address for admission control service: [https://github.com/apache/impala/blob/master/be/src/runtime/exec-env.h#L301] The Impala server run a heart beat thread for admission control service and it relies on the cached resolved address in ExecEnv. This breaks when IP address for admission control services changes (post a restart) and so we shouldn't cache dynamic addresses. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11804) Use proper capacity for base 10 storage units
[ https://issues.apache.org/jira/browse/IMPALA-11804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11804: Description: Most cloud vendors advertise storage in base 10 units such as KB, MB, GB, TB. Impala considers these storage units to be base 2. This could cause issue because when configuring data_cache or scratch_space Impala could try to use more capacity than what the underlying storage provides. It's okay for Impala to use base 2 units, but it should support configs using base 10 units and also use proper units (KiB, MiB, GiB, TiB) internally and everywhere else such as web UI, query profile, etc. The logic for parsing memory configs is here: [https://github.com/apache/impala/blob/master/be/src/util/parse-util.cc#L39] was: Most cloud vendors advertise storage in base 10 units such as GB, TB. Impala considers these storage units to be base 2. This could cause issue because when configuring data_cache or scratch_space Impala could try to use more capacity than what the underlying storage provides. It's okay for Impala to use base 2 units, but it should support configs using base 10 units and also use proper units (KiB, GiB, TiB) internally and everywhere else such as web UI, query profile, etc. The logic for parsing memory configs is here: https://github.com/apache/impala/blob/master/be/src/util/parse-util.cc#L39 > Use proper capacity for base 10 storage units > - > > Key: IMPALA-11804 > URL: https://issues.apache.org/jira/browse/IMPALA-11804 > Project: IMPALA > Issue Type: Task > Components: Backend >Reporter: Abhishek Rawat >Priority: Major > > Most cloud vendors advertise storage in base 10 units such as KB, MB, GB, TB. > Impala considers these storage units to be base 2. This could cause issue > because when configuring data_cache or scratch_space Impala could try to use > more capacity than what the underlying storage provides. > It's okay for Impala to use base 2 units, but it should support configs using > base 10 units and also use proper units (KiB, MiB, GiB, TiB) internally and > everywhere else such as web UI, query profile, etc. > The logic for parsing memory configs is here: > [https://github.com/apache/impala/blob/master/be/src/util/parse-util.cc#L39] -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11804) Use proper capacity for base 10 storage units
[ https://issues.apache.org/jira/browse/IMPALA-11804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11804: Summary: Use proper capacity for base 10 storage units (was: Use proper capacity storage units such as KB, GB, TB) > Use proper capacity for base 10 storage units > - > > Key: IMPALA-11804 > URL: https://issues.apache.org/jira/browse/IMPALA-11804 > Project: IMPALA > Issue Type: Task > Components: Backend >Reporter: Abhishek Rawat >Priority: Major > > Most cloud vendors advertise storage in base 10 units such as GB, TB. Impala > considers these storage units to be base 2. This could cause issue because > when configuring data_cache or scratch_space Impala could try to use more > capacity than what the underlying storage provides. > It's okay for Impala to use base 2 units, but it should support configs using > base 10 units and also use proper units (KiB, GiB, TiB) internally and > everywhere else such as web UI, query profile, etc. > The logic for parsing memory configs is here: > https://github.com/apache/impala/blob/master/be/src/util/parse-util.cc#L39 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11804) Use proper capacity storage units such as KB, GB, TB
Abhishek Rawat created IMPALA-11804: --- Summary: Use proper capacity storage units such as KB, GB, TB Key: IMPALA-11804 URL: https://issues.apache.org/jira/browse/IMPALA-11804 Project: IMPALA Issue Type: Task Components: Backend Reporter: Abhishek Rawat Most cloud vendors advertise storage in base 10 units such as GB, TB. Impala considers these storage units to be base 2. This could cause issue because when configuring data_cache or scratch_space Impala could try to use more capacity than what the underlying storage provides. It's okay for Impala to use base 2 units, but it should support configs using base 10 units and also use proper units (KiB, GiB, TiB) internally and everywhere else such as web UI, query profile, etc. The logic for parsing memory configs is here: https://github.com/apache/impala/blob/master/be/src/util/parse-util.cc#L39 -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-11385) Upgrade JAVA thrift components to thrift-0.16.0
[ https://issues.apache.org/jira/browse/IMPALA-11385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat updated IMPALA-11385: Summary: Upgrade JAVA thrift components to thrift-0.16.0 (was: Upgrade JAVA thrift components to thrift-0.14.2) > Upgrade JAVA thrift components to thrift-0.16.0 > --- > > Key: IMPALA-11385 > URL: https://issues.apache.org/jira/browse/IMPALA-11385 > Project: IMPALA > Issue Type: Improvement > Components: Infrastructure >Affects Versions: Impala 4.1.0 >Reporter: Riza Suminto >Assignee: Riza Suminto >Priority: Major > Fix For: Impala 4.2.0 > > > We should upgrade thrift compiler and libthrift for Java component to > thrift-0.14.2. > This is probably the most appropriate version is to maintain compatibility > with hive metastore client that impala use. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-11760) Add a query option to force query scheduling on a given executor group set
[ https://issues.apache.org/jira/browse/IMPALA-11760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Abhishek Rawat resolved IMPALA-11760. - Resolution: Not A Problem request_pool query option can be used for the same purpose. > Add a query option to force query scheduling on a given executor group set > -- > > Key: IMPALA-11760 > URL: https://issues.apache.org/jira/browse/IMPALA-11760 > Project: IMPALA > Issue Type: Task >Reporter: Abhishek Rawat >Priority: Major > > IMPALA-11033 added support for multiple executor group sets. When multiple > executor group sets are present, the executor group selection for a given > query is based on planner's resource estimation. It would be good to have an > option to force executor group set selection for a given query for testing > purpose or even for overriding planner's decision when necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-11760) Add a query option to force query scheduling on a given executor group set
Abhishek Rawat created IMPALA-11760: --- Summary: Add a query option to force query scheduling on a given executor group set Key: IMPALA-11760 URL: https://issues.apache.org/jira/browse/IMPALA-11760 Project: IMPALA Issue Type: Task Reporter: Abhishek Rawat IMPALA-11033 added support for multiple executor group sets. When multiple executor group sets are present, the executor group selection for a given query is based on planner's resource estimation. It would be good to have an option to force executor group set selection for a given query for testing purpose or even for overriding planner's decision when necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-11665) Min/Max filter could crash in fast code path for string data type
[
https://issues.apache.org/jira/browse/IMPALA-11665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Abhishek Rawat reassigned IMPALA-11665:
---
Assignee: Abhishek Rawat
> Min/Max filter could crash in fast code path for string data type
> -
>
> Key: IMPALA-11665
> URL: https://issues.apache.org/jira/browse/IMPALA-11665
> Project: IMPALA
> Issue Type: Bug
>Reporter: Abhishek Rawat
>Assignee: Abhishek Rawat
>Priority: Critical
>
> The impalad logs show that memcmp failed due to a segfault:
> {code:java}
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGSEGV (0xb) at pc=0x7f0396c3ff22, pid=1, tid=0x7f023f365700
> #
> # JRE version: OpenJDK Runtime Environment (8.0_332-b09) (build 1.8.0_332-b09)
> # Java VM: OpenJDK 64-Bit Server VM (25.332-b09 mixed mode linux-amd64
> compressed oops)
> # Problematic frame:
> # C [libc.so.6+0x16af22] __memcmp_sse4_1+0xd42 {code}
> Resolved Stack Trace for the crashed thread:
> {code:java}
> Thread 530 (crashed)
> 0 libc-2.17.so + 0x16af22
> rax = 0x7f61567715f0 rdx = 0x000a
> rcx = 0x7f62ae04cf22 rbx = 0x
> rsi = 0x5d1e900a rdi = 0x000a
> rbp = 0x7f6156771560 rsp = 0x7f6156771548
> r8 = 0x034d40f0 r9 = 0x7f62ae022e90
> r10 = 0x0498ff6c r11 = 0x7f62ae06f590
> r12 = 0x000a r13 = 0x1a9678e8
> r14 = 0x7f6156771730 r15 = 0x01b1f380
> rip = 0x7f62ae04cf22
> Found by: given as instruction pointer in context
> 1
> impalad!impala::HdfsParquetScanner::CollectSkippedPageRangesForSortedColumn(impala::MinMaxFilter
> const*, impala::ColumnType const&,
> std::vector,
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&,
> std::vector,
> std::allocator >, std::allocator std::char_traits, std::allocator > > > const&, int, int,
> std::vector >*)
> [hdfs-parquet-scanner.cc : 1388 + 0x3]
> rbp = 0x7f6156771650 rsp = 0x7f6156771570
> rip = 0x01b10305
> Found by: previous frame's frame pointer
> 2 impalad!impala::HdfsParquetScanner::SkipPagesBatch(parquet::RowGroup&,
> impala::ColumnStatsReader const&, parquet::ColumnIndex const&, int, int,
> impala::ColumnType const&, int, parquet::ColumnChunk const&,
> impala::MinMaxFilter const*, std::vector std::allocator >*, int*) [hdfs-parquet-scanner.cc : 1230 +
> 0x34]
> rbx = 0x7f61567716f0 rbp = 0x7f61567717e0
> rsp = 0x7f6156771660 r12 = 0x7f6156771710
> r13 = 0x7f6156771950 r14 = 0x1a9678e8
> r15 = 0x7f6156771920 rip = 0x01b14838
> Found by: call frame info
> 3
> impalad!impala::HdfsParquetScanner::FindSkipRangesForPagesWithMinMaxFilters(std::vector std::allocator >*) [hdfs-parquet-scanner.cc : 1528 + 0x57]
> rbx = 0x004a rbp = 0x7f6156771b10
> rsp = 0x7f61567717f0 r12 = 0x2c195800
> r13 = 0x2aa115d0 r14 = 0x0001
> r15 = 0x0049 rip = 0x01b1cf1a
> Found by: call frame info
> 4 impalad!impala::HdfsParquetScanner::EvaluatePageIndex()
> [hdfs-parquet-scanner.cc : 1600 + 0x19]
> rbx = 0x7f6156771c30 rbp = 0x7f6156771cf0
> rsp = 0x7f6156771b20 r12 = 0x2c195800
> r13 = 0x7f6156771de8 r14 = 0x104528a0
> r15 = 0x7f6156771df0 rip = 0x01b1d9dd
> Found by: call frame info
> 5 impalad!impala::HdfsParquetScanner::ProcessPageIndex()
> [hdfs-parquet-scanner.cc : 1318 + 0xb]
> rbx = 0x2c195800 rbp = 0x7f6156771d70
> rsp = 0x7f6156771d00 r12 = 0x7f6156771d10
> r13 = 0x7f6156771de8 r14 = 0x104528a0
> r15 = 0x7f6156771df0 rip = 0x01b1dd0b
> Found by: call frame info
> 6 impalad!impala::HdfsParquetScanner::NextRowGroup()
> [hdfs-parquet-scanner.cc : 934 + 0xf]
> rbx = 0x318ce040 rbp = 0x7f6156771e40
> rsp = 0x7f6156771d80 r12 = 0x2c195800
> r13 = 0x7f6156771de8 r14 = 0x104528a0
> r15 = 0x7f6156771df0 rip = 0x01b1e1b4
> Found by: call frame info
> 7 impalad!impala::HdfsParquetScanner::GetNextInternal(impala::RowBatch*)
> [hdfs-parquet-scanner.cc : 504 + 0xb]
> rbx = 0x2c195800 rbp = 0x7f6156771ec0
> rsp = 0x7f6156771e50 r12 = 0xc1ca4d00
> r13 = 0x7f6156771e78 r14 = 0x7f6156771e80
> r15 = 0xaaab rip = 0x01b1ed5b
> Found by: call frame info
> 8 impalad!impala::HdfsScanNodeMt::GetNext(impala::RuntimeState*,
> impala::RowBatch*, bool*) [hdfs-scanner.h : 138 + 0x1d]
> rbx =
[jira] [Created] (IMPALA-11665) Min/Max filter could crash in fast code path for string data type
Abhishek Rawat created IMPALA-11665:
---
Summary: Min/Max filter could crash in fast code path for string
data type
Key: IMPALA-11665
URL: https://issues.apache.org/jira/browse/IMPALA-11665
Project: IMPALA
Issue Type: Bug
Reporter: Abhishek Rawat
The impalad logs show that memcmp failed due to a segfault:
{code:java}
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x7f0396c3ff22, pid=1, tid=0x7f023f365700
#
# JRE version: OpenJDK Runtime Environment (8.0_332-b09) (build 1.8.0_332-b09)
# Java VM: OpenJDK 64-Bit Server VM (25.332-b09 mixed mode linux-amd64
compressed oops)
# Problematic frame:
# C [libc.so.6+0x16af22] __memcmp_sse4_1+0xd42 {code}
Resolved Stack Trace for the crashed thread:
{code:java}
Thread 530 (crashed)
0 libc-2.17.so + 0x16af22
rax = 0x7f61567715f0 rdx = 0x000a
rcx = 0x7f62ae04cf22 rbx = 0x
rsi = 0x5d1e900a rdi = 0x000a
rbp = 0x7f6156771560 rsp = 0x7f6156771548
r8 = 0x034d40f0 r9 = 0x7f62ae022e90
r10 = 0x0498ff6c r11 = 0x7f62ae06f590
r12 = 0x000a r13 = 0x1a9678e8
r14 = 0x7f6156771730 r15 = 0x01b1f380
rip = 0x7f62ae04cf22
Found by: given as instruction pointer in context
1
impalad!impala::HdfsParquetScanner::CollectSkippedPageRangesForSortedColumn(impala::MinMaxFilter
const*, impala::ColumnType const&,
std::vector,
std::allocator >, std::allocator, std::allocator > > > const&,
std::vector,
std::allocator >, std::allocator, std::allocator > > > const&, int, int,
std::vector >*)
[hdfs-parquet-scanner.cc : 1388 + 0x3]
rbp = 0x7f6156771650 rsp = 0x7f6156771570
rip = 0x01b10305
Found by: previous frame's frame pointer
2 impalad!impala::HdfsParquetScanner::SkipPagesBatch(parquet::RowGroup&,
impala::ColumnStatsReader const&, parquet::ColumnIndex const&, int, int,
impala::ColumnType const&, int, parquet::ColumnChunk const&,
impala::MinMaxFilter const*, std::vector >*, int*) [hdfs-parquet-scanner.cc : 1230 +
0x34]
rbx = 0x7f61567716f0 rbp = 0x7f61567717e0
rsp = 0x7f6156771660 r12 = 0x7f6156771710
r13 = 0x7f6156771950 r14 = 0x1a9678e8
r15 = 0x7f6156771920 rip = 0x01b14838
Found by: call frame info
3
impalad!impala::HdfsParquetScanner::FindSkipRangesForPagesWithMinMaxFilters(std::vector >*) [hdfs-parquet-scanner.cc : 1528 + 0x57]
rbx = 0x004a rbp = 0x7f6156771b10
rsp = 0x7f61567717f0 r12 = 0x2c195800
r13 = 0x2aa115d0 r14 = 0x0001
r15 = 0x0049 rip = 0x01b1cf1a
Found by: call frame info
4 impalad!impala::HdfsParquetScanner::EvaluatePageIndex()
[hdfs-parquet-scanner.cc : 1600 + 0x19]
rbx = 0x7f6156771c30 rbp = 0x7f6156771cf0
rsp = 0x7f6156771b20 r12 = 0x2c195800
r13 = 0x7f6156771de8 r14 = 0x104528a0
r15 = 0x7f6156771df0 rip = 0x01b1d9dd
Found by: call frame info
5 impalad!impala::HdfsParquetScanner::ProcessPageIndex()
[hdfs-parquet-scanner.cc : 1318 + 0xb]
rbx = 0x2c195800 rbp = 0x7f6156771d70
rsp = 0x7f6156771d00 r12 = 0x7f6156771d10
r13 = 0x7f6156771de8 r14 = 0x104528a0
r15 = 0x7f6156771df0 rip = 0x01b1dd0b
Found by: call frame info
6 impalad!impala::HdfsParquetScanner::NextRowGroup() [hdfs-parquet-scanner.cc
: 934 + 0xf]
rbx = 0x318ce040 rbp = 0x7f6156771e40
rsp = 0x7f6156771d80 r12 = 0x2c195800
r13 = 0x7f6156771de8 r14 = 0x104528a0
r15 = 0x7f6156771df0 rip = 0x01b1e1b4
Found by: call frame info
7 impalad!impala::HdfsParquetScanner::GetNextInternal(impala::RowBatch*)
[hdfs-parquet-scanner.cc : 504 + 0xb]
rbx = 0x2c195800 rbp = 0x7f6156771ec0
rsp = 0x7f6156771e50 r12 = 0xc1ca4d00
r13 = 0x7f6156771e78 r14 = 0x7f6156771e80
r15 = 0xaaab rip = 0x01b1ed5b
Found by: call frame info
8 impalad!impala::HdfsScanNodeMt::GetNext(impala::RuntimeState*,
impala::RowBatch*, bool*) [hdfs-scanner.h : 138 + 0x1d]
rbx = 0x12272a00 rbp = 0x7f6156772070
rsp = 0x7f6156771ed0 r12 = 0x2c195800
r13 = 0x r14 = 0x7f6156771f70
r15 = 0x7f6156771fd0 rip = 0x017d6235
Found by: call frame info
9 impalad!impala::BlockingJoinNode::GetFirstProbeRow(impala::RuntimeState*)
[blocking-join-node.cc : 316 + 0x6]
rbx = 0x0adba000 rbp = 0x7f61567720c0
rsp = 0x7f6156772080 r12 = 0x7f6156772088
r13 = 0x0adba209 r14 = 0x496b9680
