[jira] [Commented] (IMPALA-7505) impalad webserver hang in getting a lock of QueryExecStatus
[
https://issues.apache.org/jira/browse/IMPALA-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597045#comment-16597045
]
Chen Wang commented on IMPALA-7505:
---
[~jeszyb] Thanks. we reproduced IMPALA-1972 on our environment, and plan to
apply the patch to our codebase. Thank you very much.
> impalad webserver hang in getting a lock of QueryExecStatus
> ---
>
> Key: IMPALA-7505
> URL: https://issues.apache.org/jira/browse/IMPALA-7505
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.8.0
>Reporter: Chen Wang
>Priority: Major
> Attachments: gdb.out
>
>
> Impalad’s webserver would hang sometimes.
> The following is one of the cases: the webserver threads stuck in getting a
> lock of QueryExecStatus, but I can't find where the lock is acquired in the
> stack. The web requests are sent from the agent of CDH, which is to check the
> activity of impalad.
> Full gdb log is in the attachment.
> {code}
> Thread 116 (Thread 0x7f288f5e1700 (LWP 31062)):
> #0 0x00378780e334 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x0037878095d8 in _L_lock_854 () from /lib64/libpthread.so.0
> #2 0x0037878094a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3 0x008d6eb8 in pthread_mutex_lock (this=0xcab4f50) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:62
> #4 boost::mutex::lock (this=0xcab4f50) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:116
> #5 0x00b7903c in lock_guard (this=0xa7b5800, query_id=) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/lock_guard.hpp:38
> #6 impala::ImpalaServer::GetRuntimeProfileStr (this=0xa7b5800, query_id=) at
> /data/impala/be/src/service/impala-server.cc:573
> #7 0x00ba6a8c in
> impala::ImpalaHttpHandler::QueryProfileEncodedHandler (this=0x3f56be0, args=)
> at /data/impala/be/src/service/impala-http-handler.cc:219
> #8 0x00cafe75 in operator() (this=) at
> /data/impala/toolchain/boost-1.57.0/include/boost/function/function_template.hpp:767
> #9 impala::Webserver::RenderUrlWithTemplate (this=) at
> /data/impala/be/src/util/webserver.cc:443
> #10 0x00cb1295 in impala::Webserver::BeginRequestCallback (this=) at
> /data/impala/be/src/util/webserver.cc:414
> #11 0x00cc4850 in handle_request ()
> #12 0x00cc6fcd in process_new_connection ()
> #13 0x00cc765d in worker_thread ()
> #14 0x003787807aa1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0037874e8bcd in clone () from /lib64/libc.so.6
> {code}
> The hang situation appears on impala 2.8.0, but I found that code of
> be/service part hasn’t changed much from 2.8.0 to 2.11.0. so the problem may
> still exists.
> Hope you experts can give me some guidance of finding the root cause, or
> workaround plans to deal with these hang situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Assigned] (IMPALA-7503) SHOW GRANT USER not showing all privileges
[ https://issues.apache.org/jira/browse/IMPALA-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Holley reassigned IMPALA-7503: --- Assignee: Adam Holley > SHOW GRANT USER not showing all privileges > -- > > Key: IMPALA-7503 > URL: https://issues.apache.org/jira/browse/IMPALA-7503 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Affects Versions: Impala 3.1.0 >Reporter: Adam Holley >Assignee: Adam Holley >Priority: Major > > SHOW GRANT USER will only show the privileges explicitly granted to the user. > It should show all the privileges that are granted to any groups/roles the > user belongs to. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-7502) ALTER TABLE RENAME should require ALL on the source table
[ https://issues.apache.org/jira/browse/IMPALA-7502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredy Wijaya resolved IMPALA-7502. -- Resolution: Fixed Fix Version/s: Impala 3.1.0 > ALTER TABLE RENAME should require ALL on the source table > - > > Key: IMPALA-7502 > URL: https://issues.apache.org/jira/browse/IMPALA-7502 > Project: IMPALA > Issue Type: Bug > Components: Frontend >Affects Versions: Impala 3.0 >Reporter: Fredy Wijaya >Assignee: Fredy Wijaya >Priority: Major > Labels: security > Fix For: Impala 3.1.0 > > > For ALTER TABLE RENAME, currently Impala requires ALTER on the source table > and CRATE on the destination database. This may pose a security risk as > described in: https://issues.apache.org/jira/browse/SENTRY-2264. The solution > is to require ALL at the source table and CREATE at the destination database. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7503) SHOW GRANT USER not showing all privileges
[ https://issues.apache.org/jira/browse/IMPALA-7503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fredy Wijaya updated IMPALA-7503: - Issue Type: Sub-task (was: Bug) Parent: IMPALA-7075 > SHOW GRANT USER not showing all privileges > -- > > Key: IMPALA-7503 > URL: https://issues.apache.org/jira/browse/IMPALA-7503 > Project: IMPALA > Issue Type: Sub-task > Components: Frontend >Affects Versions: Impala 3.1.0 >Reporter: Adam Holley >Priority: Major > > SHOW GRANT USER will only show the privileges explicitly granted to the user. > It should show all the privileges that are granted to any groups/roles the > user belongs to. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7509) Create table after drop can lead to table not found exception
Rituparna Agrawal created IMPALA-7509:
-
Summary: Create table after drop can lead to table not found
exception
Key: IMPALA-7509
URL: https://issues.apache.org/jira/browse/IMPALA-7509
Project: IMPALA
Issue Type: Sub-task
Reporter: Rituparna Agrawal
Attachments: failure_snippet.txt
There are two impalads. One running with old mode and one with fetch from
catalogd mode.
Now create a table and drop it in the impalad running in old mode. Following
this create the same table from the new mode coodinator. It sometimes throws
table not found exception.
Test Create and Drop of a table in V1
Running 1 iterations
Going for : CREATE TABLE PARTS ( PART_ID DOUBLE, CREATE_TIME DOUBLE,
LAST_ACCESS_TIME DOUBLE, PART_NAME STRING, SD_ID DOUBLE, TBL_ID DOUBLE) STORED
AS PARQUETFILE;
Going for : DROP TABLE PARTS;
Test Create and Drop of a table in V2
Running 1 iterations
Going for : CREATE TABLE PARTS ( PART_ID DOUBLE, CREATE_TIME DOUBLE,
LAST_ACCESS_TIME DOUBLE, PART_NAME STRING, SD_ID DOUBLE, TBL_ID DOUBLE) STORED
AS PARQUETFILE;
Traceback (most recent call last):
File "testing.py", line 21, in execute_query
cursor.execute(query)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 302, in execute
configuration=configuration)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 343, in execute_async
self._execute_async(op)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 362, in _execute_async
operation_fn()
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 340, in op
async=True)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 1027, in execute
return self._operation('ExecuteStatement', req)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 957, in _operation
resp = self._rpc(kind, request)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 925, in _rpc
err_if_rpc_not_ok(response)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 704, in err_if_rpc_not_ok
raise HiveServer2Error(resp.status.errorMessage)
HiveServer2Error: LocalCatalogException: Could not load table parnatest.parts
from metastore
CAUSED BY: TException:
TGetPartialCatalogObjectResponse(status:TStatus(status_code:GENERAL,
error_msgs:[CatalogException: Table not found: parts]))
Going for : DROP TABLE PARTS;
Traceback (most recent call last):
File "testing.py", line 21, in execute_query
cursor.execute(query)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 302, in execute
configuration=configuration)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 343, in execute_async
self._execute_async(op)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 362, in _execute_async
operation_fn()
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 340, in op
async=True)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 1027, in execute
return self._operation('ExecuteStatement', req)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 957, in _operation
resp = self._rpc(kind, request)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 925, in _rpc
err_if_rpc_not_ok(response)
File
"/Users/parna/workspace/virtual_envs/metadata/lib/python2.7/site-packages/impala/hiveserver2.py",
line 704, in err_if_rpc_not_ok
raise HiveServer2Error(resp.status.errorMessage)
HiveServer2Error: LocalCatalogException: Could not load table parnatest.parts
from metastore
CAUSED BY: TException:
TGetPartialCatalogObjectResponse(status:TStatus(status_code:GENERAL,
error_msgs:[CatalogException: Table not found: parts]))
Corresponding Impalad log will attached as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7498) impalad should wait for catalogd during start up
[ https://issues.apache.org/jira/browse/IMPALA-7498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596754#comment-16596754 ] Philip Zeyliger commented on IMPALA-7498: - There's a similar issue with the catalog, which fails (in an unpleasant, core-dump-y way) if it can't talk to the Hive metastore. To be consistent, we should wait a certain amount of time in all cases. (No obligation to fix this together; just mentioning it if you end up in the same code.) > impalad should wait for catalogd during start up > > > Key: IMPALA-7498 > URL: https://issues.apache.org/jira/browse/IMPALA-7498 > Project: IMPALA > Issue Type: Sub-task >Reporter: Todd Lipcon >Priority: Major > > If you start all daemons simultaneously, impalad with --use_local_catalog > enabled will retry three times in a tight loop trying to fetch the DB names, > and then exit. Instead it should loop for some amount of time waiting for the > catalog to be ready in the same way that the existing implementation does. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-7453) Intern HdfsStorageDescriptors
[ https://issues.apache.org/jira/browse/IMPALA-7453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon resolved IMPALA-7453. - Resolution: Fixed Fix Version/s: Impala 3.1.0 > Intern HdfsStorageDescriptors > - > > Key: IMPALA-7453 > URL: https://issues.apache.org/jira/browse/IMPALA-7453 > Project: IMPALA > Issue Type: Improvement > Components: Catalog >Reporter: Todd Lipcon >Priority: Major > Fix For: Impala 3.1.0 > > > Every partition currently has an HdfsStorageDescriptor attached. In most > cases, the number of unique storage descriptors in a warehouse is pretty low > (most partitions use the same escaping, file formats, etc). For example, in > the functional test data load, we only have 24 unique SDs across ~10k > partitions. Each object takes 32 bytes (with compressed oops) or 40 > (without). So, we can get some small memory/object-count savings by interning > these. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-7446) Queries can spill earlier than necessary because of accumulation of free buffers and clean pages
[ https://issues.apache.org/jira/browse/IMPALA-7446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-7446 started by Tim Armstrong. - > Queries can spill earlier than necessary because of accumulation of free > buffers and clean pages > > > Key: IMPALA-7446 > URL: https://issues.apache.org/jira/browse/IMPALA-7446 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.10.0, Impala 2.11.0, Impala 3.0, Impala 2.12.0 >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Critical > Labels: resource-management > > See IMPALA-7442 for an example where the query started to spill even when > memory could have been made available by freeing buffers or evicting clean > pages. Usually this would just result in spilling earlier than necessary, but > in the case of IMPALA-7442 it lead to a query failure. > My original intent was that BufferPool::ReleaseMemory() should be called in > situations like this, but that was not done. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7508) Add Impala GDB commands to find fragment instances and queries in a core file
[
https://issues.apache.org/jira/browse/IMPALA-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoram Thanga updated IMPALA-7508:
-
Labels: debugging supportability (was: supportability)
> Add Impala GDB commands to find fragment instances and queries in a core file
> -
>
> Key: IMPALA-7508
> URL: https://issues.apache.org/jira/browse/IMPALA-7508
> Project: IMPALA
> Issue Type: Improvement
> Components: Infrastructure
>Affects Versions: Impala 2.12.0, Impala 3.1.0
>Reporter: Zoram Thanga
>Assignee: Zoram Thanga
>Priority: Minor
> Labels: debugging, supportability
>
> Introduce a Python GDB module, and a couple of commands that helps to find
> queries and fragment instances that are executing in an impalad at the time
> the daemon crashes.
> One hopes that folks will keep enhancing the module by adding new and useful
> GDB commands to aid debugging impalad core dumps.
> The initial patch has these:
> {noformat}
> (gdb) source impala-gdb.py
> (gdb) find-query-ids
> f74c863dff66a34d:1d983cc3
> 364525e12495932b:73f5dd02
> bc4a3eec25481981:edda04b8
> (gdb) find-fragment-instances
> Fragment Instance IdThread IDs
> 364525e12495932b:73f5dd0200a2 [69]
> 364525e12495932b:73f5dd020171 [196, 136]
> bc4a3eec25481981:edda04b801a8 [252, 237, 206]
> f74c863dff66a34d:1d983cc3009b [200, 14, 13, 12, 6, 5, 3, 2]
> f74c863dff66a34d:1d983cc3013a [4]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7488) TestShellCommandLine::test_cancellation hangs occasionally
[ https://issues.apache.org/jira/browse/IMPALA-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596641#comment-16596641 ] Thomas Tauber-Marshall commented on IMPALA-7488: So I can repro this, but the behavior that I'm seeing is strange - it appears the python process is hanging on the 'close' rpc, but I can see on the Impala side that the call to close() returns. Almost seems like a bug in thrift, except that we're not doing anything unusual here so I don't know why we would be hitting it in just one test. Continuing to investigate. > TestShellCommandLine::test_cancellation hangs occasionally > -- > > Key: IMPALA-7488 > URL: https://issues.apache.org/jira/browse/IMPALA-7488 > Project: IMPALA > Issue Type: Bug > Components: Infrastructure >Affects Versions: Impala 3.1.0 >Reporter: Tim Armstrong >Assignee: Thomas Tauber-Marshall >Priority: Major > Labels: broken-build > Attachments: psauxf.txt > > > We've seen a couple of hung builds with no queries running on the cluster. I > got "ps auxf" output and it looks like an impala-shell process is hanging > around. > I'm guessing the IMPALA-7407 fix somehow relates to this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7508) Add Impala GDB commands to find fragment instances and queries in a core file
[
https://issues.apache.org/jira/browse/IMPALA-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Zoram Thanga updated IMPALA-7508:
-
Labels: supportability (was: )
> Add Impala GDB commands to find fragment instances and queries in a core file
> -
>
> Key: IMPALA-7508
> URL: https://issues.apache.org/jira/browse/IMPALA-7508
> Project: IMPALA
> Issue Type: Improvement
> Components: Infrastructure
>Affects Versions: Impala 2.12.0, Impala 3.1.0
>Reporter: Zoram Thanga
>Assignee: Zoram Thanga
>Priority: Minor
> Labels: supportability
>
> Introduce a Python GDB module, and a couple of commands that helps to find
> queries and fragment instances that are executing in an impalad at the time
> the daemon crashes.
> One hopes that folks will keep enhancing the module by adding new and useful
> GDB commands to aid debugging impalad core dumps.
> The initial patch has these:
> {noformat}
> (gdb) source impala-gdb.py
> (gdb) find-query-ids
> f74c863dff66a34d:1d983cc3
> 364525e12495932b:73f5dd02
> bc4a3eec25481981:edda04b8
> (gdb) find-fragment-instances
> Fragment Instance IdThread IDs
> 364525e12495932b:73f5dd0200a2 [69]
> 364525e12495932b:73f5dd020171 [196, 136]
> bc4a3eec25481981:edda04b801a8 [252, 237, 206]
> f74c863dff66a34d:1d983cc3009b [200, 14, 13, 12, 6, 5, 3, 2]
> f74c863dff66a34d:1d983cc3013a [4]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Closed] (IMPALA-6065) Document IMPALA-5743
[ https://issues.apache.org/jira/browse/IMPALA-6065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-6065. --- Resolution: Fixed Fix Version/s: Impala 2.10.0 The flags are already documented in impala_ssl.html. > Document IMPALA-5743 > > > Key: IMPALA-6065 > URL: https://issues.apache.org/jira/browse/IMPALA-6065 > Project: IMPALA > Issue Type: Bug > Components: Docs >Affects Versions: Impala 2.10.0 >Reporter: Tim Armstrong >Assignee: Alex Rodoni >Priority: Major > Fix For: Impala 2.10.0 > > > It looks like --ssl_minimum_version went into Impala 2.10 but didn't have any > accompanying docs. I believe a common use case is to disallow TLS1.0 and 1.1 > with --ssl_minimum_version=tlsv1.2 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7508) Add Impala GDB commands to find fragment instances and queries in a core file
Zoram Thanga created IMPALA-7508:
Summary: Add Impala GDB commands to find fragment instances and
queries in a core file
Key: IMPALA-7508
URL: https://issues.apache.org/jira/browse/IMPALA-7508
Project: IMPALA
Issue Type: Improvement
Components: Infrastructure
Affects Versions: Impala 2.12.0, Impala 3.1.0
Reporter: Zoram Thanga
Assignee: Zoram Thanga
Introduce a Python GDB module, and a couple of commands that helps to find
queries and fragment instances that are executing in an impalad at the time the
daemon crashes.
One hopes that folks will keep enhancing the module by adding new and useful
GDB commands to aid debugging impalad core dumps.
The initial patch has these:
{noformat}
(gdb) source impala-gdb.py
(gdb) find-query-ids
f74c863dff66a34d:1d983cc3
364525e12495932b:73f5dd02
bc4a3eec25481981:edda04b8
(gdb) find-fragment-instances
Fragment Instance IdThread IDs
364525e12495932b:73f5dd0200a2 [69]
364525e12495932b:73f5dd020171 [196, 136]
bc4a3eec25481981:edda04b801a8 [252, 237, 206]
f74c863dff66a34d:1d983cc3009b [200, 14, 13, 12, 6, 5, 3, 2]
f74c863dff66a34d:1d983cc3013a [4]
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Work started] (IMPALA-7508) Add Impala GDB commands to find fragment instances and queries in a core file
[
https://issues.apache.org/jira/browse/IMPALA-7508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on IMPALA-7508 started by Zoram Thanga.
> Add Impala GDB commands to find fragment instances and queries in a core file
> -
>
> Key: IMPALA-7508
> URL: https://issues.apache.org/jira/browse/IMPALA-7508
> Project: IMPALA
> Issue Type: Improvement
> Components: Infrastructure
>Affects Versions: Impala 2.12.0, Impala 3.1.0
>Reporter: Zoram Thanga
>Assignee: Zoram Thanga
>Priority: Minor
>
> Introduce a Python GDB module, and a couple of commands that helps to find
> queries and fragment instances that are executing in an impalad at the time
> the daemon crashes.
> One hopes that folks will keep enhancing the module by adding new and useful
> GDB commands to aid debugging impalad core dumps.
> The initial patch has these:
> {noformat}
> (gdb) source impala-gdb.py
> (gdb) find-query-ids
> f74c863dff66a34d:1d983cc3
> 364525e12495932b:73f5dd02
> bc4a3eec25481981:edda04b8
> (gdb) find-fragment-instances
> Fragment Instance IdThread IDs
> 364525e12495932b:73f5dd0200a2 [69]
> 364525e12495932b:73f5dd020171 [196, 136]
> bc4a3eec25481981:edda04b801a8 [252, 237, 206]
> f74c863dff66a34d:1d983cc3009b [200, 14, 13, 12, 6, 5, 3, 2]
> f74c863dff66a34d:1d983cc3013a [4]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Resolved] (IMPALA-7286) Command "unset" does not work for shell options
[ https://issues.apache.org/jira/browse/IMPALA-7286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Csaba Ringhofer resolved IMPALA-7286. - Resolution: Fixed > Command "unset" does not work for shell options > --- > > Key: IMPALA-7286 > URL: https://issues.apache.org/jira/browse/IMPALA-7286 > Project: IMPALA > Issue Type: Bug > Components: Clients >Reporter: Csaba Ringhofer >Assignee: Nghia Le >Priority: Minor > Labels: shell > > "unset LIVE_PROGRESS;" does not unset LIVE_PROGRESS and leads to the > following error message: > No option called LIVE_PROGRESS is set > I think that unset should work for shell options too for the sake of > consistency. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7496) Schedule query taking in account the mem available on the impalad nodes
[ https://issues.apache.org/jira/browse/IMPALA-7496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596341#comment-16596341 ] Adriano commented on IMPALA-7496: - The Impala version used during the issue haven't -IMPALA-1575- The specific situation appeared once many users connected directly from their workstation to the specific impalad (this caused more use of memory, as you guessed). The query options beside the lack of guarantee are very appreciated. Thank to include the jira in the backlog. > Schedule query taking in account the mem available on the impalad nodes > --- > > Key: IMPALA-7496 > URL: https://issues.apache.org/jira/browse/IMPALA-7496 > Project: IMPALA > Issue Type: New Feature > Components: Backend >Reporter: Adriano >Priority: Major > Labels: admission-control, scheduler > > Environment description: cluster scale (50/100/150 nodes and terabyte of ram > available) - Admission Control enabled. > Issue description: > Despite the coordinator chosen (with data and statistics unchanged) a query > will be planned always in the same way based on the metainfo that the > coordinator have. > The query will be scheduled always on the same nodes if the memory > requirements for the admission are satisfied: > https://github.com/cloudera/Impala/blob/cdh5-2.7.0_5.9.1/be/src/scheduling/admission-controller.cc#L307-L333 > Equal queries are planned/scheduled always in the same way (to hit always the > same nodes). > This often lead to queue the queries that are hitting the same nodes are > queued (not admitted) as on those nodes there's no more memory available > within its process limit despite the pool have lot of free memory and the > overall cluster load is low. > When the plan is finished and the query can be evaluated to be admitted often > happen that the admission is denied because one of the node have not enough > memory to run the query operation (and the query is moved in the pool queue) > despite the cluster have 50/100/150 nodes and terabyte of ram available. > Why the scheduler does not take in consideration the memory available on the > nodes involved in the query before to buid the schedule, (maybe preferring a > remote read/operation on a free memory node instead to include in the plan > always the same nodes that will end to be: > 1- overloaded > 2- the query will be not immediately admitted, risking to be timedout in the > pool queue > Since 2.7 the REPLICA_PREFERENCE can possibly help, but it's not good enough > as it does not prevent the scheduler to choose busy nodes (with the same > potential effect: query queued for lack of resource on specific node despite > there are terabytes of free memory). > Feature Request: > It would be good if Impala had an option to execute queries (even with worse > performance) excluding the nodes overloaded and including different nodes in > order to get the query immediately admitted and executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Commented] (IMPALA-7505) impalad webserver hang in getting a lock of QueryExecStatus
[
https://issues.apache.org/jira/browse/IMPALA-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16596092#comment-16596092
]
Balazs Jeszenszky commented on IMPALA-7505:
---
[~wangchen1ren] FYI, IMPALA-1972 and IMPALA-3882 track some of the issues
around this.
> impalad webserver hang in getting a lock of QueryExecStatus
> ---
>
> Key: IMPALA-7505
> URL: https://issues.apache.org/jira/browse/IMPALA-7505
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.8.0
>Reporter: Chen Wang
>Priority: Major
> Attachments: gdb.out
>
>
> Impalad’s webserver would hang sometimes.
> The following is one of the cases: the webserver threads stuck in getting a
> lock of QueryExecStatus, but I can't find where the lock is acquired in the
> stack. The web requests are sent from the agent of CDH, which is to check the
> activity of impalad.
> Full gdb log is in the attachment.
> {code}
> Thread 116 (Thread 0x7f288f5e1700 (LWP 31062)):
> #0 0x00378780e334 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1 0x0037878095d8 in _L_lock_854 () from /lib64/libpthread.so.0
> #2 0x0037878094a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3 0x008d6eb8 in pthread_mutex_lock (this=0xcab4f50) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:62
> #4 boost::mutex::lock (this=0xcab4f50) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:116
> #5 0x00b7903c in lock_guard (this=0xa7b5800, query_id=) at
> /data/impala/toolchain/boost-1.57.0/include/boost/thread/lock_guard.hpp:38
> #6 impala::ImpalaServer::GetRuntimeProfileStr (this=0xa7b5800, query_id=) at
> /data/impala/be/src/service/impala-server.cc:573
> #7 0x00ba6a8c in
> impala::ImpalaHttpHandler::QueryProfileEncodedHandler (this=0x3f56be0, args=)
> at /data/impala/be/src/service/impala-http-handler.cc:219
> #8 0x00cafe75 in operator() (this=) at
> /data/impala/toolchain/boost-1.57.0/include/boost/function/function_template.hpp:767
> #9 impala::Webserver::RenderUrlWithTemplate (this=) at
> /data/impala/be/src/util/webserver.cc:443
> #10 0x00cb1295 in impala::Webserver::BeginRequestCallback (this=) at
> /data/impala/be/src/util/webserver.cc:414
> #11 0x00cc4850 in handle_request ()
> #12 0x00cc6fcd in process_new_connection ()
> #13 0x00cc765d in worker_thread ()
> #14 0x003787807aa1 in start_thread () from /lib64/libpthread.so.0
> #15 0x0037874e8bcd in clone () from /lib64/libc.so.6
> {code}
> The hang situation appears on impala 2.8.0, but I found that code of
> be/service part hasn’t changed much from 2.8.0 to 2.11.0. so the problem may
> still exists.
> Hope you experts can give me some guidance of finding the root cause, or
> workaround plans to deal with these hang situation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Updated] (IMPALA-7505) impalad webserver hang in getting a lock of QueryExecStatus
[
https://issues.apache.org/jira/browse/IMPALA-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chen Wang updated IMPALA-7505:
--
Affects Version/s: (was: Impala 2.7.1)
Description:
Impalad’s webserver would hang sometimes.
The following is one of the cases: the webserver threads stuck in getting a
lock of QueryExecStatus, but I can't find where the lock is acquired in the
stack. The web requests are sent from the agent of CDH, which is to check the
activity of impalad.
Full gdb log is in the attachment.
{code}
Thread 116 (Thread 0x7f288f5e1700 (LWP 31062)):
#0 0x00378780e334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0037878095d8 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x0037878094a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x008d6eb8 in pthread_mutex_lock (this=0xcab4f50) at
/data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:62
#4 boost::mutex::lock (this=0xcab4f50) at
/data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:116
#5 0x00b7903c in lock_guard (this=0xa7b5800, query_id=) at
/data/impala/toolchain/boost-1.57.0/include/boost/thread/lock_guard.hpp:38
#6 impala::ImpalaServer::GetRuntimeProfileStr (this=0xa7b5800, query_id=) at
/data/impala/be/src/service/impala-server.cc:573
#7 0x00ba6a8c in impala::ImpalaHttpHandler::QueryProfileEncodedHandler
(this=0x3f56be0, args=) at
/data/impala/be/src/service/impala-http-handler.cc:219
#8 0x00cafe75 in operator() (this=) at
/data/impala/toolchain/boost-1.57.0/include/boost/function/function_template.hpp:767
#9 impala::Webserver::RenderUrlWithTemplate (this=) at
/data/impala/be/src/util/webserver.cc:443
#10 0x00cb1295 in impala::Webserver::BeginRequestCallback (this=) at
/data/impala/be/src/util/webserver.cc:414
#11 0x00cc4850 in handle_request ()
#12 0x00cc6fcd in process_new_connection ()
#13 0x00cc765d in worker_thread ()
#14 0x003787807aa1 in start_thread () from /lib64/libpthread.so.0
#15 0x0037874e8bcd in clone () from /lib64/libc.so.6
{code}
The hang situation appears on impala 2.8.0, but I found that code of be/service
part hasn’t changed much from 2.8.0 to 2.11.0. so the problem may still exists.
Hope you experts can give me some guidance of finding the root cause, or
workaround plans to deal with these hang situation.
was:
Impalad’s webserver would hang sometimes.
The following is one of the cases: the webserver threads stuck in getting a
lock of QueryExecStatus, but I can't find where the lock is acquired in the
stack. The web requests are sent from the agent of CDH, which is to check the
activity of impalad.
Full gdb log is in the attachment.
{code}
Thread 116 (Thread 0x7f288f5e1700 (LWP 31062)):
#0 0x00378780e334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x0037878095d8 in _L_lock_854 () from /lib64/libpthread.so.0
#2 0x0037878094a7 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3 0x008d6eb8 in pthread_mutex_lock (this=0xcab4f50) at
/data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:62
#4 boost::mutex::lock (this=0xcab4f50) at
/data/impala/toolchain/boost-1.57.0/include/boost/thread/pthread/mutex.hpp:116
#5 0x00b7903c in lock_guard (this=0xa7b5800, query_id=) at
/data/impala/toolchain/boost-1.57.0/include/boost/thread/lock_guard.hpp:38
#6 impala::ImpalaServer::GetRuntimeProfileStr (this=0xa7b5800, query_id=) at
/data/impala/be/src/service/impala-server.cc:573
#7 0x00ba6a8c in impala::ImpalaHttpHandler::QueryProfileEncodedHandler
(this=0x3f56be0, args=) at
/data/impala/be/src/service/impala-http-handler.cc:219
#8 0x00cafe75 in operator() (this=) at
/data/impala/toolchain/boost-1.57.0/include/boost/function/function_template.hpp:767
#9 impala::Webserver::RenderUrlWithTemplate (this=) at
/data/impala/be/src/util/webserver.cc:443
#10 0x00cb1295 in impala::Webserver::BeginRequestCallback (this=) at
/data/impala/be/src/util/webserver.cc:414
#11 0x00cc4850 in handle_request ()
#12 0x00cc6fcd in process_new_connection ()
#13 0x00cc765d in worker_thread ()
#14 0x003787807aa1 in start_thread () from /lib64/libpthread.so.0
#15 0x0037874e8bcd in clone () from /lib64/libc.so.6
{code}
The hang situation appears on impala 2.7.1 & 2.8.0, but I found that code of
be/service part hasn’t changed much from 2.7.1 to 2.11.0. so the problem may
still exists.
Hope you experts can give me some guidance of finding the root cause, or
workaround plans to deal with these hang situation.
> impalad webserver hang in getting a lock of QueryExecStatus
> ---
>
> Key: IMPALA-7505
> URL: https://issues.apache.org/jira/browse/IMPALA-7505
> Project: IMPALA
>
[jira] [Updated] (IMPALA-7506) Support global INVALIDATE METADATA on fetch-on-demand impalad
[ https://issues.apache.org/jira/browse/IMPALA-7506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Lipcon updated IMPALA-7506: Description: There is some complexity with how this is implemented in the original code: it depends on maintaining the minimum version of any object in the impalad's local cache. We can't determine that in an on-demand impalad, so INVALIDATE METADATA is not supported currently on "fetch-on-demand". (was: There is some complexity with how this is implemented in the original code: it depends on maintaining the minimum version of any object in the impalad's local cache. We can't determine that in an on-demand impalad, so SYNC_DDL + INVALIDATE METADATA is not supported currently on "fetch-on-demand".) Summary: Support global INVALIDATE METADATA on fetch-on-demand impalad (was: Support INVALIDATE METADATA with SYNC_DDL on fetch-on-demand impalad) > Support global INVALIDATE METADATA on fetch-on-demand impalad > - > > Key: IMPALA-7506 > URL: https://issues.apache.org/jira/browse/IMPALA-7506 > Project: IMPALA > Issue Type: Sub-task >Reporter: Todd Lipcon >Priority: Major > > There is some complexity with how this is implemented in the original code: > it depends on maintaining the minimum version of any object in the impalad's > local cache. We can't determine that in an on-demand impalad, so INVALIDATE > METADATA is not supported currently on "fetch-on-demand". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7507) Clean up user-facing error messages in LocalCatalog mode
Todd Lipcon created IMPALA-7507:
---
Summary: Clean up user-facing error messages in LocalCatalog mode
Key: IMPALA-7507
URL: https://issues.apache.org/jira/browse/IMPALA-7507
Project: IMPALA
Issue Type: Sub-task
Reporter: Todd Lipcon
Currently even normal error messages for things like missing databases are
quite ugly when running with LocalCatalog:
{code}
ERROR: LocalCatalogException: Could not load table names for database
'test_minimal_topic_updates_b246004e' from HMS
CAUSED BY: TException:
TGetPartialCatalogObjectResponse(status:TStatus(status_code:GENERAL,
error_msgs:[CatalogException: Database not found:
test_minimal_topic_updates_b246004e]))
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
[jira] [Created] (IMPALA-7506) Support INVALIDATE METADATA with SYNC_DDL on fetch-on-demand impalad
Todd Lipcon created IMPALA-7506: --- Summary: Support INVALIDATE METADATA with SYNC_DDL on fetch-on-demand impalad Key: IMPALA-7506 URL: https://issues.apache.org/jira/browse/IMPALA-7506 Project: IMPALA Issue Type: Sub-task Reporter: Todd Lipcon There is some complexity with how this is implemented in the original code: it depends on maintaining the minimum version of any object in the impalad's local cache. We can't determine that in an on-demand impalad, so SYNC_DDL + INVALIDATE METADATA is not supported currently on "fetch-on-demand". -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org
