[jira] [Resolved] (IMPALA-7527) Expose fetch-from-catalogd cache and latency metrics in profiles
[ https://issues.apache.org/jira/browse/IMPALA-7527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vuk Ercegovac resolved IMPALA-7527. --- Resolution: Fixed > Expose fetch-from-catalogd cache and latency metrics in profiles > > > Key: IMPALA-7527 > URL: https://issues.apache.org/jira/browse/IMPALA-7527 > Project: IMPALA > Issue Type: Sub-task >Affects Versions: Impala 3.1.0 >Reporter: Todd Lipcon >Assignee: Vuk Ercegovac >Priority: Major > Fix For: Impala 3.1.0 > > > Since we now have some caching and potential remote calls on the planning > path, it's important to be able to understand how that contributes to the > performance of planning. This JIRA tracks adding such information to the > profile. -- 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-6742) Profiles of running queries should include execution summary
[ https://issues.apache.org/jira/browse/IMPALA-6742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yongjun Zhang reassigned IMPALA-6742: - Assignee: Yongjun Zhang > Profiles of running queries should include execution summary > > > Key: IMPALA-6742 > URL: https://issues.apache.org/jira/browse/IMPALA-6742 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Balazs Jeszenszky >Assignee: Yongjun Zhang >Priority: Minor > > The profile omits the execution summary when taken off of a running query. It > would be helpful to have it there 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] [Updated] (IMPALA-7651) Add Kudu support to scheduler-related query hints and options
[ https://issues.apache.org/jira/browse/IMPALA-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-7651: Issue Type: Bug (was: Documentation) > Add Kudu support to scheduler-related query hints and options > - > > Key: IMPALA-7651 > URL: https://issues.apache.org/jira/browse/IMPALA-7651 > Project: IMPALA > Issue Type: Bug > Components: Docs >Affects Versions: Impala 3.1.0 >Reporter: Lars Volker >Assignee: Alex Rodoni >Priority: Major > > Scheduling for Kudu works the same way for HDFS and Kudu, however our docs > pages don't mention the latter: > https://impala.apache.org/docs/build/html/topics/impala_schedule_random_replica.html > We should add Kudu to the docs for the SCHEDULE_RANDOM_REPLICA query option > and the RANDOM_REPLICA hint. -- 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-7651) Add Kudu support to scheduler-related query hints and options
[ https://issues.apache.org/jira/browse/IMPALA-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni reassigned IMPALA-7651: --- Assignee: Alex Rodoni > Add Kudu support to scheduler-related query hints and options > - > > Key: IMPALA-7651 > URL: https://issues.apache.org/jira/browse/IMPALA-7651 > Project: IMPALA > Issue Type: Documentation > Components: Docs >Affects Versions: Impala 3.1.0 >Reporter: Lars Volker >Assignee: Alex Rodoni >Priority: Major > > Scheduling for Kudu works the same way for HDFS and Kudu, however our docs > pages don't mention the latter: > https://impala.apache.org/docs/build/html/topics/impala_schedule_random_replica.html > We should add Kudu to the docs for the SCHEDULE_RANDOM_REPLICA query option > and the RANDOM_REPLICA hint. -- 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-7652) Fix BytesRead for Kudu scans
Thomas Tauber-Marshall created IMPALA-7652: -- Summary: Fix BytesRead for Kudu scans Key: IMPALA-7652 URL: https://issues.apache.org/jira/browse/IMPALA-7652 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 3.1.0 Reporter: Thomas Tauber-Marshall In the runtime profile, all scan nodes have a BytesRead counter. Kudu scan nodes do not actually set this counter, which creates confusion when Kudu scans report 0 bytes read even though they did in fact read data. We should either fill in this counter for Kudu scans, or if its difficult to get the count of bytes read from Kudu then we should eliminate the counter for Kudu scan node profiles. -- 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-7561) Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or something else)
[
https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7561:
--
Description:
ClientRequestState treats "eos" as a terminal state and won't transition to
EXCEPTION or CANCELLED out of it. See the below code snippet from
ClientRequestState::Cancel():
{code}
bool already_done = eos_ || operation_state_ ==
TOperationState::ERROR_STATE;
if (!already_done && cause != NULL) {
DCHECK(!cause->ok());
discard_result(UpdateQueryStatus(*cause));
query_events_->MarkEvent("Cancelled");
DCHECK_EQ(operation_state_, TOperationState::ERROR_STATE);
}
{code}
If the cancellation is initiated by the server (e.g. because of query_timeout_s
or exec_time_limit_s) then we should arguably treat that as an exception and
put the query into the EXCEPTION state (because it is not a user-initiated
cancellation) if it is not already in an EXCEPTION or CANCELLED state. That way
the client can see that the expiry happened and access the cause of expiry.
One argument against using the EXCEPTION state is that admins or users might
think that something went wrong and needs to be investigated, see IMPALA-471.
A separate issue is that user-initiated cancellation should use the CANCELLED
state: IMPALA-1262
was:
ClientRequestState treats "eos" as a terminal state and won't transition to
EXCEPTION or CANCELLED out of it. See the below code snippet from
ClientRequestState::Cancel():
{code}
bool already_done = eos_ || operation_state_ ==
TOperationState::ERROR_STATE;
if (!already_done && cause != NULL) {
DCHECK(!cause->ok());
discard_result(UpdateQueryStatus(*cause));
query_events_->MarkEvent("Cancelled");
DCHECK_EQ(operation_state_, TOperationState::ERROR_STATE);
}
{code}
I think that if the cancellation is initiated by the server (e.g. because of
query_timeout_s or exec_time_limit_s) then we should treat that as an exception
and put the query into the EXCEPTION state (because it is not a user-initiated
cancellation) if it is not already in an EXCEPTION or CANCELLED state. That way
the client can see that the expiry happened and access the cause of expiry.
A separate issue is that user-initiated cancellation should use the CANCELLED
state: IMPALA-1262
> Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or
> something else)
> -
>
> Key: IMPALA-7561
> URL: https://issues.apache.org/jira/browse/IMPALA-7561
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Tim Armstrong
>Priority: Major
> Labels: query-lifecycle
>
> ClientRequestState treats "eos" as a terminal state and won't transition to
> EXCEPTION or CANCELLED out of it. See the below code snippet from
> ClientRequestState::Cancel():
> {code}
> bool already_done = eos_ || operation_state_ ==
> TOperationState::ERROR_STATE;
> if (!already_done && cause != NULL) {
> DCHECK(!cause->ok());
> discard_result(UpdateQueryStatus(*cause));
> query_events_->MarkEvent("Cancelled");
> DCHECK_EQ(operation_state_, TOperationState::ERROR_STATE);
> }
> {code}
> If the cancellation is initiated by the server (e.g. because of
> query_timeout_s or exec_time_limit_s) then we should arguably treat that as
> an exception and put the query into the EXCEPTION state (because it is not a
> user-initiated cancellation) if it is not already in an EXCEPTION or
> CANCELLED state. That way the client can see that the expiry happened and
> access the cause of expiry.
> One argument against using the EXCEPTION state is that admins or users might
> think that something went wrong and needs to be investigated, see IMPALA-471.
> A separate issue is that user-initiated cancellation should use the CANCELLED
> state: IMPALA-1262
--
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-7561) Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or something else)
[
https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Armstrong updated IMPALA-7561:
--
Summary: Expired queries should end up in a consistent state (EXCEPTION,
CANCELLED, or something else) (was: Expired queries should not stay in
FINISHED state when at eos)
> Expired queries should end up in a consistent state (EXCEPTION, CANCELLED, or
> something else)
> -
>
> Key: IMPALA-7561
> URL: https://issues.apache.org/jira/browse/IMPALA-7561
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Tim Armstrong
>Priority: Major
> Labels: query-lifecycle
>
> ClientRequestState treats "eos" as a terminal state and won't transition to
> EXCEPTION or CANCELLED out of it. See the below code snippet from
> ClientRequestState::Cancel():
> {code}
> bool already_done = eos_ || operation_state_ ==
> TOperationState::ERROR_STATE;
> if (!already_done && cause != NULL) {
> DCHECK(!cause->ok());
> discard_result(UpdateQueryStatus(*cause));
> query_events_->MarkEvent("Cancelled");
> DCHECK_EQ(operation_state_, TOperationState::ERROR_STATE);
> }
> {code}
> I think that if the cancellation is initiated by the server (e.g. because of
> query_timeout_s or exec_time_limit_s) then we should treat that as an
> exception and put the query into the EXCEPTION state (because it is not a
> user-initiated cancellation) if it is not already in an EXCEPTION or
> CANCELLED state. That way the client can see that the expiry happened and
> access the cause of expiry.
> A separate issue is that user-initiated cancellation should use the CANCELLED
> state: IMPALA-1262
--
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-4714) Idle session expired query goes in to exception state - And this is confusing
[
https://issues.apache.org/jira/browse/IMPALA-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637112#comment-16637112
]
Balazs Jeszenszky commented on IMPALA-4714:
---
SGTM
> Idle session expired query goes in to exception state - And this is confusing
> -
>
> Key: IMPALA-4714
> URL: https://issues.apache.org/jira/browse/IMPALA-4714
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.6.0
>Reporter: Mala Chikka Kempanna
>Priority: Major
> Labels: query-lifecycle
>
> After setting idle_session_timeout , impala server, after completing
> execution of query, moves it into exception state , if there is no client
> activity.
> Example profile excerpt showing this behavior:
> {code}
> Query Timeline
> Start execution: 0ns (0ns)
> Planning finished: 9ms (9ms)
> Child queries finished: 8.3m (8.3m)
> Metastore update finished: 8.3m (661ms)
> Rows available: 8.3m (0ns)
> Cancelled: 11.3m (3.0m)
> Unregister query: 12.0m (42.55s)
> {code}
> Query status and query state-
> {code}
> Query Type: DDL
> Query State: EXCEPTION
> Start Time: Dec 22, 2016 11:45:01 AM
> End Time: Dec 22, 2016 11:57:01 AM
> Duration: 11m, 59s
> Admission Result: Unknown
> Client Fetch Wait Time: 3.7m
> Client Fetch Wait Time Percentage: 31
> Connected User: admin
> DDL Type: COMPUTE_STATS
> File Formats:
> Impala Version: impalad version 2.5.0-cdh5.7.2 RELEASE (build
> 1140f8289dc0d2b1517bcf70454bb4575eb8cc70)
> Network Address: 10.17.100.123:44618
> Out of Memory: false
> Planning Wait Time: 9ms
> Planning Wait Time Percentage: 0
> Query Status: Query d141e0d996c91e72:bb8726fb917537bb expired due to client
> inactivity (timeout is 3m)
> Session ID: 3043ff5042860968:8f92bc3bd2a0ca83
> Session Type: HIVESERVER2
> {code}
> Though query status string is very clear saying "expired due to client
> inactivity (timeout is 3m)", the problem is with "Query State: EXCEPTION"
> This makes user, think something went wrong with query execution.
> So I recommend that queries completed, but expired due to client-inactivity
> be marked as
> "Query State: FINISHED"
--
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-4714) Idle session expired query goes in to exception state - And this is confusing
[
https://issues.apache.org/jira/browse/IMPALA-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637111#comment-16637111
]
Tim Armstrong commented on IMPALA-4714:
---
Yeah that's a valid point, maybe an argument for using CANCELED. I think
FINISHED has problems in terms of confusing clients - I recently saw an example
of a client that kept the session containing the query alive indefinitely
because it thought the query in a FINISHED state was still active and kept
pinging the query for its state. How about I use IMPALA-7561 to track the
general issue of rethinking what state these queries should go into?
> Idle session expired query goes in to exception state - And this is confusing
> -
>
> Key: IMPALA-4714
> URL: https://issues.apache.org/jira/browse/IMPALA-4714
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.6.0
>Reporter: Mala Chikka Kempanna
>Priority: Major
> Labels: query-lifecycle
>
> After setting idle_session_timeout , impala server, after completing
> execution of query, moves it into exception state , if there is no client
> activity.
> Example profile excerpt showing this behavior:
> {code}
> Query Timeline
> Start execution: 0ns (0ns)
> Planning finished: 9ms (9ms)
> Child queries finished: 8.3m (8.3m)
> Metastore update finished: 8.3m (661ms)
> Rows available: 8.3m (0ns)
> Cancelled: 11.3m (3.0m)
> Unregister query: 12.0m (42.55s)
> {code}
> Query status and query state-
> {code}
> Query Type: DDL
> Query State: EXCEPTION
> Start Time: Dec 22, 2016 11:45:01 AM
> End Time: Dec 22, 2016 11:57:01 AM
> Duration: 11m, 59s
> Admission Result: Unknown
> Client Fetch Wait Time: 3.7m
> Client Fetch Wait Time Percentage: 31
> Connected User: admin
> DDL Type: COMPUTE_STATS
> File Formats:
> Impala Version: impalad version 2.5.0-cdh5.7.2 RELEASE (build
> 1140f8289dc0d2b1517bcf70454bb4575eb8cc70)
> Network Address: 10.17.100.123:44618
> Out of Memory: false
> Planning Wait Time: 9ms
> Planning Wait Time Percentage: 0
> Query Status: Query d141e0d996c91e72:bb8726fb917537bb expired due to client
> inactivity (timeout is 3m)
> Session ID: 3043ff5042860968:8f92bc3bd2a0ca83
> Session Type: HIVESERVER2
> {code}
> Though query status string is very clear saying "expired due to client
> inactivity (timeout is 3m)", the problem is with "Query State: EXCEPTION"
> This makes user, think something went wrong with query execution.
> So I recommend that queries completed, but expired due to client-inactivity
> be marked as
> "Query State: FINISHED"
--
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-1262) user initiated query cancellation should return operation_state = CANCELED_STATE
[
https://issues.apache.org/jira/browse/IMPALA-1262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637110#comment-16637110
]
Tim Armstrong commented on IMPALA-1262:
---
[~jeszyb] mentioned on IMPALA-4714 that EXCEPTION might cause confusion because
admins look at queries in the EXCEPTION state to understand errors.
> user initiated query cancellation should return operation_state =
> CANCELED_STATE
>
>
> Key: IMPALA-1262
> URL: https://issues.apache.org/jira/browse/IMPALA-1262
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 1.4
>Reporter: Dan Hecht
>Assignee: Bikramjeet Vig
>Priority: Minor
> Labels: query-lifecycle
>
> I've been told that if the user cancels the query, our intention is to not
> set query_state to EXCEPTION. (Is that the desired behavior?) Adding a test
> case to test_cancellation.py as follows, shows that this is not the current
> behavior (at least not in all circumstances).
> {code}
> --- a/tests/query_test/test_cancellation.py
> +++ b/tests/query_test/test_cancellation.py
> @@ -102,6 +102,7 @@ class TestCancellation(ImpalaTestSuite):
>sleep(vector.get_value('cancel_delay'))
>assert self.client.get_state(handle) !=
> self.client.QUERY_STATES['EXCEPTION']
>cancel_result = self.client.cancel(handle)
> + assert self.client.get_state(handle) !=
> self.client.QUERY_STATES['EXCEPTION']
>assert cancel_result.status_code == 0,\
>'Unexpected status code from cancel request: %s' % cancel_result
>thread.join()
> {code}
> One example of how this can happen is if the cancel happens while the wait
> thread is still in WaitInternal, then WaitInternal will return
> Status::CANCELLED, and UpdateQueryStatus indiscriminately sets query_state_
> to EXCEPTION if !ok(). But, I don't think that side of the execution can
> distinguish between user initiated cancel and error initiated cancel.
> Probably, QueryExecState::Cancel needs to remember which kind of cancellation
> it was so that the cancelled side can do the right thing.
> We don't have a general workaround.
--
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-7561) Expired queries should not stay in FINISHED state when at eos
[
https://issues.apache.org/jira/browse/IMPALA-7561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637107#comment-16637107
]
Tim Armstrong commented on IMPALA-7561:
---
See [~jeszyb]'s comment on IMPALA-4714 for a reason why we shouldn't use
EXCEPTION as the state here - it makes users/admins think something went wrong.
> Expired queries should not stay in FINISHED state when at eos
> -
>
> Key: IMPALA-7561
> URL: https://issues.apache.org/jira/browse/IMPALA-7561
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Tim Armstrong
>Priority: Major
> Labels: query-lifecycle
>
> ClientRequestState treats "eos" as a terminal state and won't transition to
> EXCEPTION or CANCELLED out of it. See the below code snippet from
> ClientRequestState::Cancel():
> {code}
> bool already_done = eos_ || operation_state_ ==
> TOperationState::ERROR_STATE;
> if (!already_done && cause != NULL) {
> DCHECK(!cause->ok());
> discard_result(UpdateQueryStatus(*cause));
> query_events_->MarkEvent("Cancelled");
> DCHECK_EQ(operation_state_, TOperationState::ERROR_STATE);
> }
> {code}
> I think that if the cancellation is initiated by the server (e.g. because of
> query_timeout_s or exec_time_limit_s) then we should treat that as an
> exception and put the query into the EXCEPTION state (because it is not a
> user-initiated cancellation) if it is not already in an EXCEPTION or
> CANCELLED state. That way the client can see that the expiry happened and
> access the cause of expiry.
> A separate issue is that user-initiated cancellation should use the CANCELLED
> state: IMPALA-1262
--
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-7651) Add Kudu support to scheduler-related query hints and options
[ https://issues.apache.org/jira/browse/IMPALA-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16637092#comment-16637092 ] Lars Volker commented on IMPALA-7651: - CC [~arodoni_cloudera], [~twmarshall] > Add Kudu support to scheduler-related query hints and options > - > > Key: IMPALA-7651 > URL: https://issues.apache.org/jira/browse/IMPALA-7651 > Project: IMPALA > Issue Type: Documentation > Components: Docs >Affects Versions: Impala 3.1.0 >Reporter: Lars Volker >Priority: Major > > Scheduling for Kudu works the same way for HDFS and Kudu, however our docs > pages don't mention the latter: > https://impala.apache.org/docs/build/html/topics/impala_schedule_random_replica.html > We should add Kudu to the docs for the SCHEDULE_RANDOM_REPLICA query option > and the RANDOM_REPLICA hint. -- 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-7651) Add Kudu support to scheduler-related query hints and options
Lars Volker created IMPALA-7651: --- Summary: Add Kudu support to scheduler-related query hints and options Key: IMPALA-7651 URL: https://issues.apache.org/jira/browse/IMPALA-7651 Project: IMPALA Issue Type: Documentation Components: Docs Affects Versions: Impala 3.1.0 Reporter: Lars Volker Scheduling for Kudu works the same way for HDFS and Kudu, however our docs pages don't mention the latter: https://impala.apache.org/docs/build/html/topics/impala_schedule_random_replica.html We should add Kudu to the docs for the SCHEDULE_RANDOM_REPLICA query option and the RANDOM_REPLICA hint. -- 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-7595) Check failed: IsValidTime(time_) at timestamp-value.h:322
[
https://issues.apache.org/jira/browse/IMPALA-7595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Csaba Ringhofer resolved IMPALA-7595.
-
Resolution: Fixed
Fix Version/s: Impala 3.1.0
> Check failed: IsValidTime(time_) at timestamp-value.h:322
> --
>
> Key: IMPALA-7595
> URL: https://issues.apache.org/jira/browse/IMPALA-7595
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Assignee: Csaba Ringhofer
>Priority: Blocker
> Labels: broken-build, crash
> Fix For: Impala 3.1.0
>
>
> See https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/3197/. hash is
> 23c7d7e57b7868eedbf5a9a4bc4aafd6066a04fb
> Some of the fuzz tests stand out amongst the tests that were running at the
> same time as the crash, particularly:
> 19:12:17 [gw4] PASSED
> query_test/test_scanners_fuzz.py::TestScannersFuzzing::test_fuzz_alltypes[exec_option:
> {'debug_action': '-1:OPEN:SET_DENY_RESERVATION_PROBABILITY@1.0',
> 'abort_on_error': False, 'mem_limit': '512m', 'num_nodes': 0} | table_format:
> parquet/none]
--
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-4714) Idle session expired query goes in to exception state - And this is confusing
[
https://issues.apache.org/jira/browse/IMPALA-4714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16636601#comment-16636601
]
Balazs Jeszenszky commented on IMPALA-4714:
---
[~tarmstrong], hmm. From a user POV, this is really a problem. There's a reason
these clients don't close their queries and timeouts are our recommended
solution, making a timed out query completely expected. This way EXCEPTION
state represents both normal and non-normal termination paths.
There are probably more complete (and more involved) solutions than just
turning these queries into FINISHED ones (e.g. TIMEDOUT state or similar). For
users, EXCEPTION means there's something to look into, not simply that it was
closed by the server. Until we come up with a more complete solution,
considering these queries normal (ie. FINISHED) would ease the pain.
> Idle session expired query goes in to exception state - And this is confusing
> -
>
> Key: IMPALA-4714
> URL: https://issues.apache.org/jira/browse/IMPALA-4714
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.6.0
>Reporter: Mala Chikka Kempanna
>Priority: Major
> Labels: query-lifecycle
>
> After setting idle_session_timeout , impala server, after completing
> execution of query, moves it into exception state , if there is no client
> activity.
> Example profile excerpt showing this behavior:
> {code}
> Query Timeline
> Start execution: 0ns (0ns)
> Planning finished: 9ms (9ms)
> Child queries finished: 8.3m (8.3m)
> Metastore update finished: 8.3m (661ms)
> Rows available: 8.3m (0ns)
> Cancelled: 11.3m (3.0m)
> Unregister query: 12.0m (42.55s)
> {code}
> Query status and query state-
> {code}
> Query Type: DDL
> Query State: EXCEPTION
> Start Time: Dec 22, 2016 11:45:01 AM
> End Time: Dec 22, 2016 11:57:01 AM
> Duration: 11m, 59s
> Admission Result: Unknown
> Client Fetch Wait Time: 3.7m
> Client Fetch Wait Time Percentage: 31
> Connected User: admin
> DDL Type: COMPUTE_STATS
> File Formats:
> Impala Version: impalad version 2.5.0-cdh5.7.2 RELEASE (build
> 1140f8289dc0d2b1517bcf70454bb4575eb8cc70)
> Network Address: 10.17.100.123:44618
> Out of Memory: false
> Planning Wait Time: 9ms
> Planning Wait Time Percentage: 0
> Query Status: Query d141e0d996c91e72:bb8726fb917537bb expired due to client
> inactivity (timeout is 3m)
> Session ID: 3043ff5042860968:8f92bc3bd2a0ca83
> Session Type: HIVESERVER2
> {code}
> Though query status string is very clear saying "expired due to client
> inactivity (timeout is 3m)", the problem is with "Query State: EXCEPTION"
> This makes user, think something went wrong with query execution.
> So I recommend that queries completed, but expired due to client-inactivity
> be marked as
> "Query State: FINISHED"
--
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
