[jira] [Commented] (IMPALA-2746) Backend tests should pass with leak sanitizer enabled
[ https://issues.apache.org/jira/browse/IMPALA-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516492#comment-16516492 ] Tim Armstrong commented on IMPALA-2746: --- IMPALA-2746: part 1: enable LSAN for many backend tests This turns on leak sanitizer for backend tests that required relatively small modifications to pass. We suppress a few leaks, mainly related to the embedded JVM. Testing: Ran core tests under ASAN. Change-Id: Ibdda092a4eb4bc827c75a8c121e5428ec746b7f4 Reviewed-on: http://gerrit.cloudera.org:8080/10668 Reviewed-by: Impala Public Jenkins Tested-by: Impala Public Jenkins > Backend tests should pass with leak sanitizer enabled > - > > Key: IMPALA-2746 > URL: https://issues.apache.org/jira/browse/IMPALA-2746 > Project: IMPALA > Issue Type: Bug > Components: Backend >Affects Versions: Impala 2.3.0 >Reporter: Martin Grund >Priority: Minor > Labels: resource-management, test-infra > > Currently, when running the backend tests with ASAN, the build will fail if > memory leak detection is enabled. We should investigate where leaks occur and > fix them to make sure we can benefit from the leak detection 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] [Closed] (IMPALA-7182) Impala does not allow the use of insecure clusters with public IPs by default
[ https://issues.apache.org/jira/browse/IMPALA-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-7182. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Impala does not allow the use of insecure clusters with public IPs by default > - > > Key: IMPALA-7182 > URL: https://issues.apache.org/jira/browse/IMPALA-7182 > Project: IMPALA > Issue Type: Task > Components: Security >Affects Versions: Impala 2.12.0 >Reporter: Sailesh Mukil >Assignee: Alex Rodoni >Priority: Critical > Labels: docs, security > Fix For: Impala 3.1.0 > > > We made Impala more secure by using KRPC which doesn't allow the usage of > insecure clusters (no auth or no encryption) with public IPs by default. > We have a workaround which is to add the subnet to this flag > 'trusted_subnets': > https://github.com/apache/impala/blob/master/be/src/kudu/rpc/server_negotiation.cc#L70-L80 > Although we don't expect users to run production environments with this > configuration, we need to document this as it's a slight behavioral change > from Impala 2.11 to Impala 2.12. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IMPALA-7182) Impala does not allow the use of insecure clusters with public IPs by default
[ https://issues.apache.org/jira/browse/IMPALA-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-7182. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Impala does not allow the use of insecure clusters with public IPs by default > - > > Key: IMPALA-7182 > URL: https://issues.apache.org/jira/browse/IMPALA-7182 > Project: IMPALA > Issue Type: Task > Components: Security >Affects Versions: Impala 2.12.0 >Reporter: Sailesh Mukil >Assignee: Alex Rodoni >Priority: Critical > Labels: docs, security > Fix For: Impala 3.1.0 > > > We made Impala more secure by using KRPC which doesn't allow the usage of > insecure clusters (no auth or no encryption) with public IPs by default. > We have a workaround which is to add the subnet to this flag > 'trusted_subnets': > https://github.com/apache/impala/blob/master/be/src/kudu/rpc/server_negotiation.cc#L70-L80 > Although we don't expect users to run production environments with this > configuration, we need to document this as it's a slight behavioral change > from Impala 2.11 to Impala 2.12. -- 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-7171) Add docs for Kudu insert partitioning/sorting
[ https://issues.apache.org/jira/browse/IMPALA-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-7171. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Add docs for Kudu insert partitioning/sorting > - > > Key: IMPALA-7171 > URL: https://issues.apache.org/jira/browse/IMPALA-7171 > Project: IMPALA > Issue Type: Improvement > Components: Docs >Reporter: Thomas Tauber-Marshall >Assignee: Alex Rodoni >Priority: Major > Labels: docs > Fix For: Impala 2.13.0, Impala 3.1.0 > > > On the page: > http://impala.apache.org/docs/build3x/html/topics/impala_kudu.html, at the > end of the section: "Impala DML Support for Kudu Tables (INSERT, UPDATE, > DELETE, UPSERT)", we should add text like: > Starting from Impala 2.9, Impala will automatically add a partition and sort > step to INSERTs before sending the rows to Kudu. Since Kudu partitions and > sorts rows on write, pre-partitioning and sorting takes some of the load off > of Kudu, and helps ensure that large INSERTs complete without timing out, but > it may slow down the end-to-end performance of the INSERT. Starting from > Impala 2.10, the hints "/* +noshuffle,noclustered */" may be used to turn > this pre-partitioning and sorting off. Additionally, since sorting may > consume a lot of memory, users should consider setting a "mem_limit" for > these queries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IMPALA-7171) Add docs for Kudu insert partitioning/sorting
[ https://issues.apache.org/jira/browse/IMPALA-7171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-7171. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Add docs for Kudu insert partitioning/sorting > - > > Key: IMPALA-7171 > URL: https://issues.apache.org/jira/browse/IMPALA-7171 > Project: IMPALA > Issue Type: Improvement > Components: Docs >Reporter: Thomas Tauber-Marshall >Assignee: Alex Rodoni >Priority: Major > Labels: docs > Fix For: Impala 2.13.0, Impala 3.1.0 > > > On the page: > http://impala.apache.org/docs/build3x/html/topics/impala_kudu.html, at the > end of the section: "Impala DML Support for Kudu Tables (INSERT, UPDATE, > DELETE, UPSERT)", we should add text like: > Starting from Impala 2.9, Impala will automatically add a partition and sort > step to INSERTs before sending the rows to Kudu. Since Kudu partitions and > sorts rows on write, pre-partitioning and sorting takes some of the load off > of Kudu, and helps ensure that large INSERTs complete without timing out, but > it may slow down the end-to-end performance of the INSERT. Starting from > Impala 2.10, the hints "/* +noshuffle,noclustered */" may be used to turn > this pre-partitioning and sorting off. Additionally, since sorting may > consume a lot of memory, users should consider setting a "mem_limit" for > these queries. -- 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-7183) We should print the sender name when logging a report for an unknown status report on the coordinatior
[ https://issues.apache.org/jira/browse/IMPALA-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516460#comment-16516460 ] Dan Hecht commented on IMPALA-7183: --- Is there an easy way to determine which host was the sender at this point? I think that's only known by the coordinator object, but that's gone. I think it's possible once we switch the RPC to KRPC however since the KRPC layer can tell us. > We should print the sender name when logging a report for an unknown status > report on the coordinatior > -- > > Key: IMPALA-7183 > URL: https://issues.apache.org/jira/browse/IMPALA-7183 > Project: IMPALA > Issue Type: Improvement > Components: Backend, Distributed Exec >Affects Versions: Impala 2.13.0, Impala 3.1.0 >Reporter: Lars Volker >Priority: Critical > Labels: ramp-up > > We should print the sender name when logging a report for an unknown status > report on the coordinatior in > [impala-server.cc:1229|https://github.com/apache/impala/blob/e7d5a25a4516337ef651983b1d945abf06c3a831/be/src/service/impala-server.cc#L1229]. > That will help identify backends with stuck fragment instances who fail to > get cancelled. -- 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-7182) Impala does not allow the use of insecure clusters with public IPs by default
[ https://issues.apache.org/jira/browse/IMPALA-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516406#comment-16516406 ] Alex Rodoni commented on IMPALA-7182: - https://gerrit.cloudera.org/#/c/10751/ > Impala does not allow the use of insecure clusters with public IPs by default > - > > Key: IMPALA-7182 > URL: https://issues.apache.org/jira/browse/IMPALA-7182 > Project: IMPALA > Issue Type: Documentation > Components: Security >Affects Versions: Impala 2.12.0 >Reporter: Sailesh Mukil >Assignee: Alex Rodoni >Priority: Critical > Labels: docs, security > > We made Impala more secure by using KRPC which doesn't allow the usage of > insecure clusters (no auth or no encryption) with public IPs by default. > We have a workaround which is to add the subnet to this flag > 'trusted_subnets': > https://github.com/apache/impala/blob/master/be/src/kudu/rpc/server_negotiation.cc#L70-L80 > Although we don't expect users to run production environments with this > configuration, we need to document this as it's a slight behavioral change > from Impala 2.11 to Impala 2.12. -- 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-7185) Reduce statestore frequency for custom cluster tests by default
Tim Armstrong created IMPALA-7185: - Summary: Reduce statestore frequency for custom cluster tests by default Key: IMPALA-7185 URL: https://issues.apache.org/jira/browse/IMPALA-7185 Project: IMPALA Issue Type: Bug Components: Infrastructure Reporter: Tim Armstrong Assignee: Tim Armstrong It takes several seconds to run the first query after cluster startup because of the statestore propagation delay for the catalog, which adds some real time to custom cluster tests. We should think about lowering the default update interval for those tests to make them start up faster. We could just prefix the statestored_args with lower values, allowing individual tests to override if needed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7185) Reduce statestore frequency for custom cluster tests by default
Tim Armstrong created IMPALA-7185: - Summary: Reduce statestore frequency for custom cluster tests by default Key: IMPALA-7185 URL: https://issues.apache.org/jira/browse/IMPALA-7185 Project: IMPALA Issue Type: Bug Components: Infrastructure Reporter: Tim Armstrong Assignee: Tim Armstrong It takes several seconds to run the first query after cluster startup because of the statestore propagation delay for the catalog, which adds some real time to custom cluster tests. We should think about lowering the default update interval for those tests to make them start up faster. We could just prefix the statestored_args with lower values, allowing individual tests to override if needed. -- 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-7184) Support Kudu's READ_YOUR_WRITES scan mode
Thomas Tauber-Marshall created IMPALA-7184: -- Summary: Support Kudu's READ_YOUR_WRITES scan mode Key: IMPALA-7184 URL: https://issues.apache.org/jira/browse/IMPALA-7184 Project: IMPALA Issue Type: Improvement Reporter: Thomas Tauber-Marshall Assignee: Thomas Tauber-Marshall Kudu recently added a new scan mode called READ_YOUR_WRITES which provides better consistency guarantees than READ_LATEST or READ_AT_SNAPSHOT, the options currently supported by Impala. Unfortunately, READ_YOUR_WRITES is currently affected by a bug that makes it unusable by Impala (KUDU-2233). Once this is fixed, we should add support for it, and consider either setting it as the default, or at least using it in tests, see the discussion in https://gerrit.cloudera.org/#/c/10503/ -- 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-7184) Support Kudu's READ_YOUR_WRITES scan mode
Thomas Tauber-Marshall created IMPALA-7184: -- Summary: Support Kudu's READ_YOUR_WRITES scan mode Key: IMPALA-7184 URL: https://issues.apache.org/jira/browse/IMPALA-7184 Project: IMPALA Issue Type: Improvement Reporter: Thomas Tauber-Marshall Assignee: Thomas Tauber-Marshall Kudu recently added a new scan mode called READ_YOUR_WRITES which provides better consistency guarantees than READ_LATEST or READ_AT_SNAPSHOT, the options currently supported by Impala. Unfortunately, READ_YOUR_WRITES is currently affected by a bug that makes it unusable by Impala (KUDU-2233). Once this is fixed, we should add support for it, and consider either setting it as the default, or at least using it in tests, see the discussion in https://gerrit.cloudera.org/#/c/10503/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IMPALA-6036) Queries in admission control pool queue stay in the queue even after end client had already disconnected.
[ https://issues.apache.org/jira/browse/IMPALA-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikramjeet Vig resolved IMPALA-6036. Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Queries in admission control pool queue stay in the queue even after end > client had already disconnected. > - > > Key: IMPALA-6036 > URL: https://issues.apache.org/jira/browse/IMPALA-6036 > Project: IMPALA > Issue Type: Bug > Components: Frontend >Reporter: Sudarshan >Assignee: Bikramjeet Vig >Priority: Major > Labels: admission-control, resource-management > Fix For: Impala 2.13.0, Impala 3.1.0 > > Attachments: ScreenShotSessions_ImpalaDebugWebPage.png, impala.log, > profile_submitted_in_step_2.txt, profile_submitted_in_step_3.txt > > > Steps to reproduce :- > -- > 1) Set Impala admission control queue concurrency to 1. > 2) Submitting a long running query. Anything submitted after this query will > be queued. > 3) Submit another query. This query will get queued due to admission control > queue concurrency of 1. > 4) Disconnect the client that submitted the query in step 3, above. > Expected observation :- > -- > Ideally you would want that the query submitted in step 3 to get canceled as > soon as the client disconnects. > What happens :- > > Query submitted in step 3 stays in the queue until it gets a chance to > execute. This causes the coordinator to start the fragments and then realize > that the client had already disconnected. > Attachments :- > > 1. impala.log > 2. profile_submitted_in_step_2.txt ==> query profile > 3. profile_submitted_in_step_3.txt ==> query profile > 4. ScreenShotSessions_ImpalaDebugWebPage.png ==> Screen shot of sessions as > seen from Impala debug web page. > -- 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-6036) Queries in admission control pool queue stay in the queue even after end client had already disconnected.
[ https://issues.apache.org/jira/browse/IMPALA-6036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bikramjeet Vig resolved IMPALA-6036. Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Queries in admission control pool queue stay in the queue even after end > client had already disconnected. > - > > Key: IMPALA-6036 > URL: https://issues.apache.org/jira/browse/IMPALA-6036 > Project: IMPALA > Issue Type: Bug > Components: Frontend >Reporter: Sudarshan >Assignee: Bikramjeet Vig >Priority: Major > Labels: admission-control, resource-management > Fix For: Impala 2.13.0, Impala 3.1.0 > > Attachments: ScreenShotSessions_ImpalaDebugWebPage.png, impala.log, > profile_submitted_in_step_2.txt, profile_submitted_in_step_3.txt > > > Steps to reproduce :- > -- > 1) Set Impala admission control queue concurrency to 1. > 2) Submitting a long running query. Anything submitted after this query will > be queued. > 3) Submit another query. This query will get queued due to admission control > queue concurrency of 1. > 4) Disconnect the client that submitted the query in step 3, above. > Expected observation :- > -- > Ideally you would want that the query submitted in step 3 to get canceled as > soon as the client disconnects. > What happens :- > > Query submitted in step 3 stays in the queue until it gets a chance to > execute. This causes the coordinator to start the fragments and then realize > that the client had already disconnected. > Attachments :- > > 1. impala.log > 2. profile_submitted_in_step_2.txt ==> query profile > 3. profile_submitted_in_step_3.txt ==> query profile > 4. ScreenShotSessions_ImpalaDebugWebPage.png ==> Screen shot of sessions as > seen from Impala debug web page. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (IMPALA-7182) Impala does not allow the use of insecure clusters with public IPs by default
[ https://issues.apache.org/jira/browse/IMPALA-7182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-7182 started by Alex Rodoni. --- > Impala does not allow the use of insecure clusters with public IPs by default > - > > Key: IMPALA-7182 > URL: https://issues.apache.org/jira/browse/IMPALA-7182 > Project: IMPALA > Issue Type: Documentation > Components: Security >Affects Versions: Impala 2.12.0 >Reporter: Sailesh Mukil >Assignee: Alex Rodoni >Priority: Critical > Labels: docs, security > > We made Impala more secure by using KRPC which doesn't allow the usage of > insecure clusters (no auth or no encryption) with public IPs by default. > We have a workaround which is to add the subnet to this flag > 'trusted_subnets': > https://github.com/apache/impala/blob/master/be/src/kudu/rpc/server_negotiation.cc#L70-L80 > Although we don't expect users to run production environments with this > configuration, we need to document this as it's a slight behavioral change > from Impala 2.11 to Impala 2.12. -- 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] [Comment Edited] (IMPALA-6194) Ensure all fragment instances notice cancellation
[
https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516115#comment-16516115
]
Michael Ho edited comment on IMPALA-6194 at 6/18/18 6:46 PM:
-
For the record, adding some major offenders which may ignore cancellation.
Usually, this occurs when something goes wrong with the IO subsystem and IO
threads are stuck in some HDFS calls. The system will eventually grind to a
halt as all IO scan ranges will be stuck.
All scanner threads will be stuck waiting for scan ranges to be available. When
the system is in this state, the queries cannot be cancelled cleanly as the
scanner threads are stuck in a condition variable without a timeout. Similarly,
the fragment instance thread will also be stuck in {{HdfsScanNode::GetNext()}}
until some scanner threads get unstuck.
Ideally, we should *enforce timeout in the HDFS calls* to avoid this situation
from occurring.
{noformat}
Status HdfsScanNode::GetNextInternal(
RuntimeState* state, RowBatch* row_batch, bool* eos) {
.
.
unique_ptr materialized_batch =
materialized_row_batches_->GetBatch(); <<- can be stuck forever if the
queue is empty
.
.
{noformat}
{{DiskIoMgr::GetNextUnstartedRange(}} is called by the scanner threads to pick
up the next scan range. A scanner thread can be stuck in it if the IO manager
threads are stuck in some HDFS calls.
{noformat}
Status DiskIoMgr::GetNextUnstartedRange(RequestContext* reader, ScanRange**
range,
bool* needs_buffers) {
.
.
if (reader->ready_to_start_ranges_.empty()) {
reader->ready_to_start_ranges_cv_.Wait(reader_lock); << can be stuck
forever if the IO thread is stuck somehow
} else {
{noformat}
The cascading effect is that {{HdfsScanNode::Close()}} can get stuck waiting
for the stuck scanner threads:
{noformat}
void HdfsScanNode::Close(RuntimeState* state) {
if (is_closed()) return;
SetDone();
if (thread_avail_cb_id_ != -1) {
state->resource_pool()->RemoveThreadAvailableCb(thread_avail_cb_id_);
}
scanner_threads_.JoinAll(); <<- stuck waiting for scanner threads to exit
materialized_row_batches_->Cleanup();
HdfsScanNodeBase::Close(state);
}
{noformat}
was (Author: kwho):
For the record, adding some major offenders which may ignore cancellation:
{noformat}
Status HdfsScanNode::GetNextInternal(
RuntimeState* state, RowBatch* row_batch, bool* eos) {
.
.
unique_ptr materialized_batch =
materialized_row_batches_->GetBatch(); <<- can be stuck forever if the
queue is empty
.
.
{noformat}
{{DiskIoMgr::GetNextUnstartedRange(}} is called by the scanner threads to pick
up the next scan range. A scanner thread can be stuck in it if the IO manager
threads are stuck in some HDFS calls.
{noformat}
Status DiskIoMgr::GetNextUnstartedRange(RequestContext* reader, ScanRange**
range,
bool* needs_buffers) {
.
.
if (reader->ready_to_start_ranges_.empty()) {
reader->ready_to_start_ranges_cv_.Wait(reader_lock); << can be stuck
forever if the IO thread is stuck somehow
} else {
{noformat}
The cascading effect is that {{HdfsScanNode::Close()}} can get stuck waiting
for the stuck scanner threads:
{noformat}
void HdfsScanNode::Close(RuntimeState* state) {
if (is_closed()) return;
SetDone();
if (thread_avail_cb_id_ != -1) {
state->resource_pool()->RemoveThreadAvailableCb(thread_avail_cb_id_);
}
scanner_threads_.JoinAll(); <<- stuck waiting for scanner threads to exit
materialized_row_batches_->Cleanup();
HdfsScanNodeBase::Close(state);
}
{noformat}
> Ensure all fragment instances notice cancellation
> -
>
> Key: IMPALA-6194
> URL: https://issues.apache.org/jira/browse/IMPALA-6194
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Lars Volker
>Priority: Critical
> Labels: observability, supportability
>
> Currently queries can get stuck in an uncancellable state, e.g. when blocking
> on function calls or condition variables without periodically checking for
> cancellation. We should eliminate all those calls and make sure we don't
> re-introduce such issues. One option would be a watchdog to check that each
> fragment instance regularly calls RETURN_IF_CANCEL.
--
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-7050) Impala Doc: Document inc_stats_size_limit_bytes command line option for Impalad
[ https://issues.apache.org/jira/browse/IMPALA-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-7050. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Impala Doc: Document inc_stats_size_limit_bytes command line option for > Impalad > --- > > Key: IMPALA-7050 > URL: https://issues.apache.org/jira/browse/IMPALA-7050 > Project: IMPALA > Issue Type: Task > Components: Docs >Affects Versions: Impala 2.8.0 >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Fix For: Impala 2.13.0, Impala 3.1.0 > > > nformation - > == > -inc_stats_size_limit_bytes (Maximum size of incremental stats the catalog > is allowed to serialize per table. This limit is set as a safety check, > to prevent the JVM from hitting a maximum array limit of 1GB (or OOM) > while building the thrift objects to send to impalads. By default, it's > set to 200MB) type: int64 default: 209715200 > == > Way to modify: > > You can change inc_stats_size_limit_bytes value using the below steps: > 1. CM > Impala Service > Configuration > Search Impala Command Line Argument > Advanced Configuration Snippet (Safety Valve) > 2. Please input -inc_stats_size_limit_bytes= > Please note that: you have to input the integer value in > For example, if you want to set 1GB, please input 1048576000(1024*1024*1024). > 3. Please save it and restart the impala service -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IMPALA-7050) Impala Doc: Document inc_stats_size_limit_bytes command line option for Impalad
[ https://issues.apache.org/jira/browse/IMPALA-7050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni closed IMPALA-7050. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Impala Doc: Document inc_stats_size_limit_bytes command line option for > Impalad > --- > > Key: IMPALA-7050 > URL: https://issues.apache.org/jira/browse/IMPALA-7050 > Project: IMPALA > Issue Type: Task > Components: Docs >Affects Versions: Impala 2.8.0 >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Fix For: Impala 2.13.0, Impala 3.1.0 > > > nformation - > == > -inc_stats_size_limit_bytes (Maximum size of incremental stats the catalog > is allowed to serialize per table. This limit is set as a safety check, > to prevent the JVM from hitting a maximum array limit of 1GB (or OOM) > while building the thrift objects to send to impalads. By default, it's > set to 200MB) type: int64 default: 209715200 > == > Way to modify: > > You can change inc_stats_size_limit_bytes value using the below steps: > 1. CM > Impala Service > Configuration > Search Impala Command Line Argument > Advanced Configuration Snippet (Safety Valve) > 2. Please input -inc_stats_size_limit_bytes= > Please note that: you have to input the integer value in > For example, if you want to set 1GB, please input 1048576000(1024*1024*1024). > 3. Please save it and restart the impala service -- 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-6194) Ensure all fragment instances notice cancellation
[
https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516133#comment-16516133
]
Michael Ho commented on IMPALA-6194:
{{HdfsScanNode::GetNext()}} will get unstuck once there are row batches
available or if some threads call {{HdfsScanNode::SetDoneInternal()}} which
calls {{Shutdown()}}. However, we have seen cases in which the IO threads are
stuck and cancelling the query is ineffective as some fragment instances are
stuck at places above. That said, a better thing to do is to prevent IO from
being stuck to begin with.
> Ensure all fragment instances notice cancellation
> -
>
> Key: IMPALA-6194
> URL: https://issues.apache.org/jira/browse/IMPALA-6194
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Lars Volker
>Priority: Critical
> Labels: observability, supportability
>
> Currently queries can get stuck in an uncancellable state, e.g. when blocking
> on function calls or condition variables without periodically checking for
> cancellation. We should eliminate all those calls and make sure we don't
> re-introduce such issues. One option would be a watchdog to check that each
> fragment instance regularly calls RETURN_IF_CANCEL.
--
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-6194) Ensure all fragment instances notice cancellation
[ https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516127#comment-16516127 ] Tim Armstrong commented on IMPALA-6194: --- I agree that the whole scheme depends on I/O threads not getting stuck, though, just afaik the scanner threads will notice cancellation and exit so long as they don't get blocked on I/O. > Ensure all fragment instances notice cancellation > - > > Key: IMPALA-6194 > URL: https://issues.apache.org/jira/browse/IMPALA-6194 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Lars Volker >Priority: Critical > Labels: observability, supportability > > Currently queries can get stuck in an uncancellable state, e.g. when blocking > on function calls or condition variables without periodically checking for > cancellation. We should eliminate all those calls and make sure we don't > re-introduce such issues. One option would be a watchdog to check that each > fragment instance regularly calls RETURN_IF_CANCEL. -- 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-6194) Ensure all fragment instances notice cancellation
[ https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Ho updated IMPALA-6194: --- Priority: Critical (was: Major) > Ensure all fragment instances notice cancellation > - > > Key: IMPALA-6194 > URL: https://issues.apache.org/jira/browse/IMPALA-6194 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Lars Volker >Priority: Critical > Labels: observability, supportability > > Currently queries can get stuck in an uncancellable state, e.g. when blocking > on function calls or condition variables without periodically checking for > cancellation. We should eliminate all those calls and make sure we don't > re-introduce such issues. One option would be a watchdog to check that each > fragment instance regularly calls RETURN_IF_CANCEL. -- 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-6194) Ensure all fragment instances notice cancellation
[ https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516123#comment-16516123 ] Tim Armstrong commented on IMPALA-6194: --- [~kwho] I think materialized_row_batches_ should get unblocked by the Shutdown() call when the scanner threads exit. If that doesn't work then there's a new bug there. > Ensure all fragment instances notice cancellation > - > > Key: IMPALA-6194 > URL: https://issues.apache.org/jira/browse/IMPALA-6194 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Lars Volker >Priority: Major > Labels: observability, supportability > > Currently queries can get stuck in an uncancellable state, e.g. when blocking > on function calls or condition variables without periodically checking for > cancellation. We should eliminate all those calls and make sure we don't > re-introduce such issues. One option would be a watchdog to check that each > fragment instance regularly calls RETURN_IF_CANCEL. -- 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-4908) NULL floats don't compare equal to other NULL floats
[
https://issues.apache.org/jira/browse/IMPALA-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nilangekar resolved IMPALA-4908.
--
Resolution: Fixed
Fix Version/s: Impala 3.1.0
IMPALA-4908: NULL floats don't compare equal to other NULL floats
This change ensures that comparing two NULL floats with different
val fields returns true. Although this is undefined behavior, it
is now consistent with other types.
Along with the change, a unit test was added to ensure that
equality checking of floats returns results as expected.
Change-Id: Ie7310645e5752d8203be5abc22a6562a59b6e975
Reviewed-on: http://gerrit.cloudera.org:8080/10707
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> NULL floats don't compare equal to other NULL floats
>
>
> Key: IMPALA-4908
> URL: https://issues.apache.org/jira/browse/IMPALA-4908
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.9.0
>Reporter: Zachary
>Assignee: Pooja Nilangekar
>Priority: Trivial
> Fix For: Impala 3.1.0
>
>
> FloatVals which are NULL only compare equal to other FloatVals if the float
> val also matches?
> It's already undefined behavior, but it would be nice to be consistent with
> other types. From the code:
>
>bool operator==(const FloatVal& other) const {
> return is_null == other.is_null && val == other.val;
>}
--
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] [Comment Edited] (IMPALA-6194) Ensure all fragment instances notice cancellation
[
https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516115#comment-16516115
]
Michael Ho edited comment on IMPALA-6194 at 6/18/18 6:21 PM:
-
For the record, adding some major offenders which may ignore cancellation:
{noformat}
Status HdfsScanNode::GetNextInternal(
RuntimeState* state, RowBatch* row_batch, bool* eos) {
.
.
unique_ptr materialized_batch =
materialized_row_batches_->GetBatch(); <<- can be stuck forever if the
queue is empty
.
.
{noformat}
{{DiskIoMgr::GetNextUnstartedRange(}} is called by the scanner threads to pick
up the next scan range. A scanner thread can be stuck in it if the IO manager
threads are stuck in some HDFS calls.
{noformat}
Status DiskIoMgr::GetNextUnstartedRange(RequestContext* reader, ScanRange**
range,
bool* needs_buffers) {
.
.
if (reader->ready_to_start_ranges_.empty()) {
reader->ready_to_start_ranges_cv_.Wait(reader_lock); << can be stuck
forever if the IO thread is stuck somehow
} else {
{noformat}
The cascading effect is that {{HdfsScanNode::Close()}} can get stuck waiting
for the stuck scanner threads:
{noformat}
void HdfsScanNode::Close(RuntimeState* state) {
if (is_closed()) return;
SetDone();
if (thread_avail_cb_id_ != -1) {
state->resource_pool()->RemoveThreadAvailableCb(thread_avail_cb_id_);
}
scanner_threads_.JoinAll(); <<- stuck waiting for scanner threads to exit
materialized_row_batches_->Cleanup();
HdfsScanNodeBase::Close(state);
}
{noformat}
was (Author: kwho):
For the record, adding some major offenders which may ignore cancellation:
{noformat}
Status HdfsScanNode::GetNextInternal(
RuntimeState* state, RowBatch* row_batch, bool* eos) {
.
.
unique_ptr materialized_batch =
materialized_row_batches_->GetBatch(); <<- can be stuck forever if the
queue is empty
.
.
{noformat}
{noformat}
Status DiskIoMgr::GetNextUnstartedRange(RequestContext* reader, ScanRange**
range,
bool* needs_buffers) {
.
.
if (reader->ready_to_start_ranges_.empty()) {
reader->ready_to_start_ranges_cv_.Wait(reader_lock); << can be stuck
forever if the IO thread is stuck somehow
} else {
{noformat}
> Ensure all fragment instances notice cancellation
> -
>
> Key: IMPALA-6194
> URL: https://issues.apache.org/jira/browse/IMPALA-6194
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Lars Volker
>Priority: Major
> Labels: observability, supportability
>
> Currently queries can get stuck in an uncancellable state, e.g. when blocking
> on function calls or condition variables without periodically checking for
> cancellation. We should eliminate all those calls and make sure we don't
> re-introduce such issues. One option would be a watchdog to check that each
> fragment instance regularly calls RETURN_IF_CANCEL.
--
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-4908) NULL floats don't compare equal to other NULL floats
[
https://issues.apache.org/jira/browse/IMPALA-4908?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pooja Nilangekar resolved IMPALA-4908.
--
Resolution: Fixed
Fix Version/s: Impala 3.1.0
IMPALA-4908: NULL floats don't compare equal to other NULL floats
This change ensures that comparing two NULL floats with different
val fields returns true. Although this is undefined behavior, it
is now consistent with other types.
Along with the change, a unit test was added to ensure that
equality checking of floats returns results as expected.
Change-Id: Ie7310645e5752d8203be5abc22a6562a59b6e975
Reviewed-on: http://gerrit.cloudera.org:8080/10707
Reviewed-by: Impala Public Jenkins
Tested-by: Impala Public Jenkins
> NULL floats don't compare equal to other NULL floats
>
>
> Key: IMPALA-4908
> URL: https://issues.apache.org/jira/browse/IMPALA-4908
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 2.9.0
>Reporter: Zachary
>Assignee: Pooja Nilangekar
>Priority: Trivial
> Fix For: Impala 3.1.0
>
>
> FloatVals which are NULL only compare equal to other FloatVals if the float
> val also matches?
> It's already undefined behavior, but it would be nice to be consistent with
> other types. From the code:
>
>bool operator==(const FloatVal& other) const {
> return is_null == other.is_null && val == other.val;
>}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IMPALA-6194) Ensure all fragment instances notice cancellation
[
https://issues.apache.org/jira/browse/IMPALA-6194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516115#comment-16516115
]
Michael Ho commented on IMPALA-6194:
For the record, adding some major offenders which may ignore cancellation:
{noformat}
Status HdfsScanNode::GetNextInternal(
RuntimeState* state, RowBatch* row_batch, bool* eos) {
.
.
unique_ptr materialized_batch =
materialized_row_batches_->GetBatch(); <<- can be stuck forever if the
queue is empty
.
.
{noformat}
{noformat}
Status DiskIoMgr::GetNextUnstartedRange(RequestContext* reader, ScanRange**
range,
bool* needs_buffers) {
.
.
if (reader->ready_to_start_ranges_.empty()) {
reader->ready_to_start_ranges_cv_.Wait(reader_lock); << can be stuck
forever if the IO thread is stuck somehow
} else {
{noformat}
> Ensure all fragment instances notice cancellation
> -
>
> Key: IMPALA-6194
> URL: https://issues.apache.org/jira/browse/IMPALA-6194
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
>Reporter: Lars Volker
>Priority: Major
> Labels: observability, supportability
>
> Currently queries can get stuck in an uncancellable state, e.g. when blocking
> on function calls or condition variables without periodically checking for
> cancellation. We should eliminate all those calls and make sure we don't
> re-introduce such issues. One option would be a watchdog to check that each
> fragment instance regularly calls RETURN_IF_CANCEL.
--
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-6835) Improve Kudu scanner error messages to include the table name and the plan node id
[ https://issues.apache.org/jira/browse/IMPALA-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16516114#comment-16516114 ] Pooja Nilangekar commented on IMPALA-6835: -- IMPALA-6835: Add table name and node id to Kudu scanner errors Previously, the error messages in KuduScanner only contained the reason for failure. They did not contain the KuduTable name or the TPlanNode id which made it inconveient to debug. This change adds the TPlanNode id to all error messages and the KuduTable name whenever applicable. This change was manually tested by explicitly returning failure while scanning kudu tables. Change-Id: I0377fc8591738dc45092d228fcf292ddbb367825 Reviewed-on: [http://gerrit.cloudera.org:8080/10671] Reviewed-by: Impala Public Jenkins Tested-by: Impala Public Jenkins > Improve Kudu scanner error messages to include the table name and the plan > node id > -- > > Key: IMPALA-6835 > URL: https://issues.apache.org/jira/browse/IMPALA-6835 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 2.11.0, Impala 3.0, Impala 2.12.0 >Reporter: yyzzjj >Assignee: Pooja Nilangekar >Priority: Major > Labels: kudu, observability, supportability > Fix For: Impala 3.1.0 > > > E.g: > [https://github.com/apache/impala/blob/830e3346f186aebc879e4ef2927e08db97143100/be/src/exec/kudu-scanner.cc#L338] > big sql usually contains dozens of tables， when query fail kudu tserver or > master response error info which not contain table name > Inconvenient positioning problem which table -- 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-6835) Improve Kudu scanner error messages to include the table name and the plan node id
[ https://issues.apache.org/jira/browse/IMPALA-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Nilangekar updated IMPALA-6835: - Fix Version/s: Impala 3.1.0 > Improve Kudu scanner error messages to include the table name and the plan > node id > -- > > Key: IMPALA-6835 > URL: https://issues.apache.org/jira/browse/IMPALA-6835 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 2.11.0, Impala 3.0, Impala 2.12.0 >Reporter: yyzzjj >Assignee: Pooja Nilangekar >Priority: Major > Labels: kudu, observability, supportability > Fix For: Impala 3.1.0 > > > E.g: > [https://github.com/apache/impala/blob/830e3346f186aebc879e4ef2927e08db97143100/be/src/exec/kudu-scanner.cc#L338] > big sql usually contains dozens of tables， when query fail kudu tserver or > master response error info which not contain table name > Inconvenient positioning problem which table -- 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-6835) Improve Kudu scanner error messages to include the table name and the plan node id
[ https://issues.apache.org/jira/browse/IMPALA-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Nilangekar resolved IMPALA-6835. -- Resolution: Fixed > Improve Kudu scanner error messages to include the table name and the plan > node id > -- > > Key: IMPALA-6835 > URL: https://issues.apache.org/jira/browse/IMPALA-6835 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 2.11.0, Impala 3.0, Impala 2.12.0 >Reporter: yyzzjj >Assignee: Pooja Nilangekar >Priority: Major > Labels: kudu, observability, supportability > Fix For: Impala 3.1.0 > > > E.g: > [https://github.com/apache/impala/blob/830e3346f186aebc879e4ef2927e08db97143100/be/src/exec/kudu-scanner.cc#L338] > big sql usually contains dozens of tables， when query fail kudu tserver or > master response error info which not contain table name > Inconvenient positioning problem which table -- 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-6835) Improve Kudu scanner error messages to include the table name and the plan node id
[ https://issues.apache.org/jira/browse/IMPALA-6835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pooja Nilangekar resolved IMPALA-6835. -- Resolution: Fixed > Improve Kudu scanner error messages to include the table name and the plan > node id > -- > > Key: IMPALA-6835 > URL: https://issues.apache.org/jira/browse/IMPALA-6835 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Affects Versions: Impala 2.11.0, Impala 3.0, Impala 2.12.0 >Reporter: yyzzjj >Assignee: Pooja Nilangekar >Priority: Major > Labels: kudu, observability, supportability > Fix For: Impala 3.1.0 > > > E.g: > [https://github.com/apache/impala/blob/830e3346f186aebc879e4ef2927e08db97143100/be/src/exec/kudu-scanner.cc#L338] > big sql usually contains dozens of tables， when query fail kudu tserver or > master response error info which not contain table name > Inconvenient positioning problem which table -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IMPALA-7157) Avoid unnecessarily pretty printing profiles per fragment instance
[ https://issues.apache.org/jira/browse/IMPALA-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailesh Mukil resolved IMPALA-7157. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Avoid unnecessarily pretty printing profiles per fragment instance > -- > > Key: IMPALA-7157 > URL: https://issues.apache.org/jira/browse/IMPALA-7157 > Project: IMPALA > Issue Type: Improvement > Components: Distributed Exec >Reporter: Sailesh Mukil >Assignee: Sailesh Mukil >Priority: Minor > Labels: logs > Fix For: Impala 3.1.0 > > > In SendReport(), if VLOG_FILE_IS_ON is 'true' (which is not the most verbose > logging level, but is higher than default), we pretty print the profile for > every fragment instance, which is a very expensive operation, as serializing > the profile is non-trivial (look at RuntimeProfile::PrettyPrint()), and > printing large amounts of information to the logs isn't cheap as well. > Lastly, it is very noisy. > This seems unnecessary since this will not benefit us, as all the profiles > are merged at the coordinator side. We could argue that this might be > necessary when an executor fails to send the profile to the coordinator, but > that signifies a network issue which will not be reflected in the profile of > any fragment instance. > This will help reduce noise in the logs when the log level is bumped up to > find other real issues that VLOG_FILE can help with. -- 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-7157) Avoid unnecessarily pretty printing profiles per fragment instance
[ https://issues.apache.org/jira/browse/IMPALA-7157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sailesh Mukil resolved IMPALA-7157. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Avoid unnecessarily pretty printing profiles per fragment instance > -- > > Key: IMPALA-7157 > URL: https://issues.apache.org/jira/browse/IMPALA-7157 > Project: IMPALA > Issue Type: Improvement > Components: Distributed Exec >Reporter: Sailesh Mukil >Assignee: Sailesh Mukil >Priority: Minor > Labels: logs > Fix For: Impala 3.1.0 > > > In SendReport(), if VLOG_FILE_IS_ON is 'true' (which is not the most verbose > logging level, but is higher than default), we pretty print the profile for > every fragment instance, which is a very expensive operation, as serializing > the profile is non-trivial (look at RuntimeProfile::PrettyPrint()), and > printing large amounts of information to the logs isn't cheap as well. > Lastly, it is very noisy. > This seems unnecessary since this will not benefit us, as all the profiles > are merged at the coordinator side. We could argue that this might be > necessary when an executor fails to send the profile to the coordinator, but > that signifies a network issue which will not be reflected in the profile of > any fragment instance. > This will help reduce noise in the logs when the log level is bumped up to > find other real issues that VLOG_FILE can help with. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IMPALA-7183) We should print the sender name when logging a report for an unknown status report on the coordinatior
[ https://issues.apache.org/jira/browse/IMPALA-7183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Ho updated IMPALA-7183: --- Component/s: Distributed Exec > We should print the sender name when logging a report for an unknown status > report on the coordinatior > -- > > Key: IMPALA-7183 > URL: https://issues.apache.org/jira/browse/IMPALA-7183 > Project: IMPALA > Issue Type: Improvement > Components: Backend, Distributed Exec >Affects Versions: Impala 2.13.0, Impala 3.1.0 >Reporter: Lars Volker >Priority: Critical > Labels: ramp-up > > We should print the sender name when logging a report for an unknown status > report on the coordinatior in > [impala-server.cc:1229|https://github.com/apache/impala/blob/e7d5a25a4516337ef651983b1d945abf06c3a831/be/src/service/impala-server.cc#L1229]. > That will help identify backends with stuck fragment instances who fail to > get cancelled. -- 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-7183) We should print the sender name when logging a report for an unknown status report on the coordinatior
Lars Volker created IMPALA-7183: --- Summary: We should print the sender name when logging a report for an unknown status report on the coordinatior Key: IMPALA-7183 URL: https://issues.apache.org/jira/browse/IMPALA-7183 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 2.13.0, Impala 3.1.0 Reporter: Lars Volker We should print the sender name when logging a report for an unknown status report on the coordinatior in [impala-server.cc:1229|https://github.com/apache/impala/blob/e7d5a25a4516337ef651983b1d945abf06c3a831/be/src/service/impala-server.cc#L1229]. That will help identify backends with stuck fragment instances who fail to get cancelled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7183) We should print the sender name when logging a report for an unknown status report on the coordinatior
Lars Volker created IMPALA-7183: --- Summary: We should print the sender name when logging a report for an unknown status report on the coordinatior Key: IMPALA-7183 URL: https://issues.apache.org/jira/browse/IMPALA-7183 Project: IMPALA Issue Type: Improvement Components: Backend Affects Versions: Impala 2.13.0, Impala 3.1.0 Reporter: Lars Volker We should print the sender name when logging a report for an unknown status report on the coordinatior in [impala-server.cc:1229|https://github.com/apache/impala/blob/e7d5a25a4516337ef651983b1d945abf06c3a831/be/src/service/impala-server.cc#L1229]. That will help identify backends with stuck fragment instances who fail to get cancelled. -- 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-7182) Impala does not allow the use of insecure clusters with public IPs by default
Sailesh Mukil created IMPALA-7182: - Summary: Impala does not allow the use of insecure clusters with public IPs by default Key: IMPALA-7182 URL: https://issues.apache.org/jira/browse/IMPALA-7182 Project: IMPALA Issue Type: Documentation Components: Security Affects Versions: Impala 2.12.0 Reporter: Sailesh Mukil Assignee: Alex Rodoni We made Impala more secure by using KRPC which doesn't allow the usage of insecure clusters (no auth or no encryption) with public IPs by default. We have a workaround which is to add the subnet to this flag 'trusted_subnets': https://github.com/apache/impala/blob/master/be/src/kudu/rpc/server_negotiation.cc#L70-L80 Although we don't expect users to run production environments with this configuration, we need to document this as it's a slight behavioral change from Impala 2.11 to Impala 2.12. -- 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-7182) Impala does not allow the use of insecure clusters with public IPs by default
Sailesh Mukil created IMPALA-7182: - Summary: Impala does not allow the use of insecure clusters with public IPs by default Key: IMPALA-7182 URL: https://issues.apache.org/jira/browse/IMPALA-7182 Project: IMPALA Issue Type: Documentation Components: Security Affects Versions: Impala 2.12.0 Reporter: Sailesh Mukil Assignee: Alex Rodoni We made Impala more secure by using KRPC which doesn't allow the usage of insecure clusters (no auth or no encryption) with public IPs by default. We have a workaround which is to add the subnet to this flag 'trusted_subnets': https://github.com/apache/impala/blob/master/be/src/kudu/rpc/server_negotiation.cc#L70-L80 Although we don't expect users to run production environments with this configuration, we need to document this as it's a slight behavioral change from Impala 2.11 to Impala 2.12. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7181) Fix flaky test shell/test_shell_commandline.py::TestImpalaShell::test_socket_opening
Vincent Tran created IMPALA-7181: Summary: Fix flaky test shell/test_shell_commandline.py::TestImpalaShell::test_socket_opening Key: IMPALA-7181 URL: https://issues.apache.org/jira/browse/IMPALA-7181 Project: IMPALA Issue Type: Test Affects Versions: Impala 2.13.0, Impala 3.1.0 Reporter: Vincent Tran Assignee: Vincent Tran shell/test_shell_commandline.py::TestImpalaShell::test_socket_opening uses netcat to listen to an ephemeral port to verify impala-shell socket opening behavior. The port is hardcoded to 42000 which can fail the test if this port is used by an outgoing socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IMPALA-7181) Fix flaky test shell/test_shell_commandline.py::TestImpalaShell::test_socket_opening
Vincent Tran created IMPALA-7181: Summary: Fix flaky test shell/test_shell_commandline.py::TestImpalaShell::test_socket_opening Key: IMPALA-7181 URL: https://issues.apache.org/jira/browse/IMPALA-7181 Project: IMPALA Issue Type: Test Affects Versions: Impala 2.13.0, Impala 3.1.0 Reporter: Vincent Tran Assignee: Vincent Tran shell/test_shell_commandline.py::TestImpalaShell::test_socket_opening uses netcat to listen to an ephemeral port to verify impala-shell socket opening behavior. The port is hardcoded to 42000 which can fail the test if this port is used by an outgoing socket. -- 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-7130) impala-shell -b / --kerberos_host_fqdn flag overrides value passed in via -i
[
https://issues.apache.org/jira/browse/IMPALA-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515794#comment-16515794
]
Vincent Tran commented on IMPALA-7130:
--
[~csringhofer],
I suppose that was the original intent. But I see the problem with that.
I've refactored the test to use python's socket.bind(("",0)) function to pick
an open port on the fly. Should be less flaky. Will submit it for review
shortly.
> impala-shell -b / --kerberos_host_fqdn flag overrides value passed in via -i
>
>
> Key: IMPALA-7130
> URL: https://issues.apache.org/jira/browse/IMPALA-7130
> Project: IMPALA
> Issue Type: Bug
> Components: Clients
>Affects Versions: Impala 3.0, Impala 2.12.0
>Reporter: Vincent Tran
>Assignee: Vincent Tran
>Priority: Critical
> Fix For: Impala 2.13.0, Impala 3.1.0
>
>
> When impala-shell -b / --kerberos_host_fqdn is used, the value will override
> one passed in via -i / --impalad.
> This leads to the socket being created with the former value in the case when
> -b is used.
> The problematic section of code is here
> {noformat}
> if self.kerberos_host_fqdn is not None:
> host, port = (self.kerberos_host_fqdn.split(':')[0].encode('ascii',
> 'ignore'),
> int(self.impalad[1]))
> else:
> host, port = self.impalad[0].encode('ascii', 'ignore'),
> int(self.impalad[1])
> if self.use_ssl:
> if self.ca_cert is None:
> # No CA cert means don't try to verify the certificate
> sock = TSSLSocketWithWildcardSAN(host, port, validate=False)
> else:
> sock = TSSLSocketWithWildcardSAN(host, port, validate=True,
> ca_certs=self.ca_cert)
> else:
> sock = TSocket(host, port)
> if not (self.use_ldap or self.use_kerberos):
> return TBufferedTransport(sock)
> {noformat}
> The proposed fix is to always create the socket with the host passed in via -i
> {noformat}
> self.impalad[0].encode('ascii', 'ignore')
> {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-7130) impala-shell -b / --kerberos_host_fqdn flag overrides value passed in via -i
[
https://issues.apache.org/jira/browse/IMPALA-7130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16515700#comment-16515700
]
Csaba Ringhofer commented on IMPALA-7130:
-
[~thundergun]
I have seen some tests failing at test_socket_opening
(https://jenkins.impala.io/job/gerrit-verify-dryrun/2691/consoleFull). Port
42000 is in the ephemeral range, so some process may randomly use it, which
makes the test inherently flaky.
> impala-shell -b / --kerberos_host_fqdn flag overrides value passed in via -i
>
>
> Key: IMPALA-7130
> URL: https://issues.apache.org/jira/browse/IMPALA-7130
> Project: IMPALA
> Issue Type: Bug
> Components: Clients
>Affects Versions: Impala 3.0, Impala 2.12.0
>Reporter: Vincent Tran
>Assignee: Vincent Tran
>Priority: Critical
> Fix For: Impala 2.13.0, Impala 3.1.0
>
>
> When impala-shell -b / --kerberos_host_fqdn is used, the value will override
> one passed in via -i / --impalad.
> This leads to the socket being created with the former value in the case when
> -b is used.
> The problematic section of code is here
> {noformat}
> if self.kerberos_host_fqdn is not None:
> host, port = (self.kerberos_host_fqdn.split(':')[0].encode('ascii',
> 'ignore'),
> int(self.impalad[1]))
> else:
> host, port = self.impalad[0].encode('ascii', 'ignore'),
> int(self.impalad[1])
> if self.use_ssl:
> if self.ca_cert is None:
> # No CA cert means don't try to verify the certificate
> sock = TSSLSocketWithWildcardSAN(host, port, validate=False)
> else:
> sock = TSSLSocketWithWildcardSAN(host, port, validate=True,
> ca_certs=self.ca_cert)
> else:
> sock = TSocket(host, port)
> if not (self.use_ldap or self.use_kerberos):
> return TBufferedTransport(sock)
> {noformat}
> The proposed fix is to always create the socket with the host passed in via -i
> {noformat}
> self.impalad[0].encode('ascii', 'ignore')
> {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
