[jira] [Resolved] (IMPALA-7464) DCHECK(!released_exec_resources_) is triggered when ExecFInstance() RPC times out

[ https://issues.apache.org/jira/browse/IMPALA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7464. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > DCHECK(!released_exec_resources_) is

[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=16611283#comment-16611283 ] Dan Hecht commented on IMPALA-1262: --- Just saw IMPALA-7561, which I think answers my question. > user

[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=16611278#comment-16611278 ] Dan Hecht commented on IMPALA-1262: --- Agree, I would expect exception. I'm not sure I follow your last

[jira] [Commented] (IMPALA-7464) DCHECK(!released_exec_resources_) is triggered when ExecFInstance() RPC times out

[ https://issues.apache.org/jira/browse/IMPALA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16588172#comment-16588172 ] Dan Hecht commented on IMPALA-7464: --- Reproducing this requires making this change: {code:java} diff

[jira] [Commented] (IMPALA-7464) DCHECK(!released_exec_resources_) is triggered when ExecFInstance() RPC times out

[ https://issues.apache.org/jira/browse/IMPALA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586547#comment-16586547 ] Dan Hecht commented on IMPALA-7464: --- Yea, that sounds right. But here's what remains under this

[jira] [Commented] (IMPALA-7464) DCHECK(!released_exec_resources_) is triggered when ExecFInstance() RPC times out

[ https://issues.apache.org/jira/browse/IMPALA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586540#comment-16586540 ] Dan Hecht commented on IMPALA-7464: --- [~tarmstr...@cloudera.com], do you remember specifically which

[jira] [Commented] (IMPALA-7464) DCHECK(!released_exec_resources_) is triggered when ExecFInstance() RPC times out

[ https://issues.apache.org/jira/browse/IMPALA-7464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16586520#comment-16586520 ] Dan Hecht commented on IMPALA-7464: --- {quote}it calls {{ReleaseExecResource()}} again after the ref

[jira] [Commented] (IMPALA-7232) Display whether fragment instances' profile is complete

[ https://issues.apache.org/jira/browse/IMPALA-7232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16530001#comment-16530001 ] Dan Hecht commented on IMPALA-7232: --- We also have IMPALA- > Display whether fragment instances'

[jira] [Resolved] (IMPALA-7205) Respond to ReportExecStatus() RPC with CANCELLED whenever query execution has terminated

[ https://issues.apache.org/jira/browse/IMPALA-7205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7205. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 commit

[jira] [Commented] (IMPALA-7221) While reading from object store S3/ADLS at +500MB/sec TypeArrayKlass::allocate_common becomes a CPU bottleneck

[ https://issues.apache.org/jira/browse/IMPALA-7221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16526957#comment-16526957 ] Dan Hecht commented on IMPALA-7221: --- I think this is because S3A doesn't support the DirectByteBuffer

[jira] [Assigned] (IMPALA-1226) need better cancellation tests

[ https://issues.apache.org/jira/browse/IMPALA-1226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-1226: - Assignee: Dan Hecht (was: Mostafa Mokhtar) > need better cancellation tests >

[jira] [Resolved] (IMPALA-7210) Global debug_action should use case insensitive comparisons

[ https://issues.apache.org/jira/browse/IMPALA-7210?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7210. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Global debug_action should use case

[jira] [Commented] (IMPALA-6818) Rethink data-stream sender/receiver startup sequencing

[ https://issues.apache.org/jira/browse/IMPALA-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16523908#comment-16523908 ] Dan Hecht commented on IMPALA-6818: --- I think we need to think through the impact on IMPALA-3990 as

[jira] [Resolved] (IMPALA-7207) Make Coordinator ExecState an atomic enum

[ https://issues.apache.org/jira/browse/IMPALA-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7207. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Make Coordinator ExecState an atomic enum >

[jira] [Updated] (IMPALA-7205) Respond to ReportExecStatus() RPC with CANCELLED whenever query execution has terminated

[ https://issues.apache.org/jira/browse/IMPALA-7205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-7205: -- Description: Currently we respond with CANCELLED only when hitting EOS. It seems a bit more robust

[jira] [Created] (IMPALA-7210) Global debug_action should use case insensitive comparisons

Dan Hecht created IMPALA-7210: - Summary: Global debug_action should use case insensitive comparisons Key: IMPALA-7210 URL: https://issues.apache.org/jira/browse/IMPALA-7210 Project: IMPALA

[jira] [Created] (IMPALA-7207) Make Coordinator ExecState an atomic enum

Dan Hecht created IMPALA-7207: - Summary: Make Coordinator ExecState an atomic enum Key: IMPALA-7207 URL: https://issues.apache.org/jira/browse/IMPALA-7207 Project: IMPALA Issue Type: Sub-task

[jira] [Resolved] (IMPALA-7191) Daemons should call srand() early in main rather than at random locations

[ https://issues.apache.org/jira/browse/IMPALA-7191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7191. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 commit

[jira] [Comment Edited] (IMPALA-5119) Don't make RPCs from Coordinator::UpdateBackendExecStatus()

[ https://issues.apache.org/jira/browse/IMPALA-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518544#comment-16518544 ] Dan Hecht edited comment on IMPALA-5119 at 6/25/18 4:49 PM: The {{lock_}}

[jira] [Comment Edited] (IMPALA-5119) Don't make RPCs from Coordinator::UpdateBackendExecStatus()

[ https://issues.apache.org/jira/browse/IMPALA-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518544#comment-16518544 ] Dan Hecht edited comment on IMPALA-5119 at 6/25/18 4:49 PM: The {{lock_}}

[jira] [Updated] (IMPALA-5119) Don't make RPCs from Coordinator::UpdateBackendExecStatus()

[ https://issues.apache.org/jira/browse/IMPALA-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-5119: -- Summary: Don't make RPCs from Coordinator::UpdateBackendExecStatus() (was: Don't call

[jira] [Commented] (IMPALA-7180) Pin Impala CDH dependencies

[ https://issues.apache.org/jira/browse/IMPALA-7180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522511#comment-16522511 ] Dan Hecht commented on IMPALA-7180: --- Please note the commit that fixes this (looks like the jira bot

[jira] [Updated] (IMPALA-7205) Respond to ReportExecStatus() RPC with CANCELLED whenever query execution has terminated

[ https://issues.apache.org/jira/browse/IMPALA-7205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-7205: -- Issue Type: Sub-task (was: Improvement) Parent: IMPALA-5865 > Respond to ReportExecStatus()

[jira] [Commented] (IMPALA-6818) Rethink data-stream sender/receiver startup sequencing

[ https://issues.apache.org/jira/browse/IMPALA-6818?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16522500#comment-16522500 ] Dan Hecht commented on IMPALA-6818: --- I forgot that UpdateStatus() RPC is responded with CANCELLED

[jira] [Created] (IMPALA-7205) Respond to ReportExecStatus() RPC with CANCELLED whenever query execution has terminated

Dan Hecht created IMPALA-7205: - Summary: Respond to ReportExecStatus() RPC with CANCELLED whenever query execution has terminated Key: IMPALA-7205 URL: https://issues.apache.org/jira/browse/IMPALA-7205

[jira] [Resolved] (IMPALA-7046) Add targeted regression test for race in IMPALA-7033

[ https://issues.apache.org/jira/browse/IMPALA-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7046. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 commit

[jira] [Resolved] (IMPALA-5202) Debug action WAIT in PREPARE leads to hung query that cannot be cancelled.

[ https://issues.apache.org/jira/browse/IMPALA-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-5202. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 commit

[jira] [Created] (IMPALA-7191) Daemons should call srand() early in main rather than at random locations

Dan Hecht created IMPALA-7191: - Summary: Daemons should call srand() early in main rather than at random locations Key: IMPALA-7191 URL: https://issues.apache.org/jira/browse/IMPALA-7191 Project: IMPALA

[jira] [Comment Edited] (IMPALA-6788) Query fragments can spend lots of time starting up then fail right after "starting" all backends

[ https://issues.apache.org/jira/browse/IMPALA-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518547#comment-16518547 ] Dan Hecht edited comment on IMPALA-6788 at 6/20/18 8:08 PM: This has turned

[jira] [Commented] (IMPALA-6788) Query fragments can spend lots of time starting up then fail right after "starting" all backends

[ https://issues.apache.org/jira/browse/IMPALA-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518547#comment-16518547 ] Dan Hecht commented on IMPALA-6788: --- This has turned out a bit more complicated than hoped without

[jira] [Work stopped] (IMPALA-6788) Query fragments can spend lots of time starting up then fail right after "starting" all backends

[ https://issues.apache.org/jira/browse/IMPALA-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-6788 stopped by Dan Hecht. - > Query fragments can spend lots of time starting up then fail right after >

[jira] [Assigned] (IMPALA-5202) Debug action WAIT in PREPARE leads to hung query that cannot be cancelled.

[ https://issues.apache.org/jira/browse/IMPALA-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-5202: - Assignee: Dan Hecht > Debug action WAIT in PREPARE leads to hung query that cannot be

[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

[jira] [Comment Edited] (IMPALA-6153) Prevent Coordinator::UpdateFilter() running after query exec resources are released

[ https://issues.apache.org/jira/browse/IMPALA-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514558#comment-16514558 ] Dan Hecht edited comment on IMPALA-6153 at 6/16/18 12:14 AM: - We've been

[jira] [Commented] (IMPALA-6153) Prevent Coordinator::UpdateFilter() running after query exec resources are released

[ https://issues.apache.org/jira/browse/IMPALA-6153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16514558#comment-16514558 ] Dan Hecht commented on IMPALA-6153: --- We've been trying to clarify query lifecycle events and also

[jira] [Resolved] (IMPALA-7125) test_cancellation execute_cancel_test() should have a delay before fetch

[ https://issues.apache.org/jira/browse/IMPALA-7125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7125. --- Resolution: Not A Problem Actually, I think we get this coverage already from

[jira] [Resolved] (IMPALA-6942) "Cancelled due to unreachable impalad(s)" error message is misleading

[ https://issues.apache.org/jira/browse/IMPALA-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-6942. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 commit

[jira] [Work started] (IMPALA-6788) Query fragments can spend lots of time starting up then fail right after "starting" all backends

[ https://issues.apache.org/jira/browse/IMPALA-6788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-6788 started by Dan Hecht. - > Query fragments can spend lots of time starting up then fail right after >

[jira] [Work started] (IMPALA-7046) Add targeted regression test for race in IMPALA-7033

[ https://issues.apache.org/jira/browse/IMPALA-7046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-7046 started by Dan Hecht. - > Add targeted regression test for race in IMPALA-7033 >

[jira] [Work started] (IMPALA-6942) "Cancelled due to unreachable impalad(s)" error message is misleading

[ https://issues.apache.org/jira/browse/IMPALA-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on IMPALA-6942 started by Dan Hecht. - > "Cancelled due to unreachable impalad(s)" error message is misleading >

[jira] [Assigned] (IMPALA-6942) "Cancelled due to unreachable impalad(s)" error message is misleading

[ https://issues.apache.org/jira/browse/IMPALA-6942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-6942: - Assignee: Dan Hecht Thanks for the reminder. i can take care of it. > "Cancelled due to

[jira] [Resolved] (IMPALA-7109) TestPartitionMetadata::test_multiple_partitions_same_location uses incorrect paths

[ https://issues.apache.org/jira/browse/IMPALA-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7109. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 >

[jira] [Updated] (IMPALA-7153) filesystem_client methods expect unusual paths

[ https://issues.apache.org/jira/browse/IMPALA-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-7153: -- Labels: ramp-up (was: ) > filesystem_client methods expect unusual paths >

[jira] [Created] (IMPALA-7153) filesystem_client methods expect unusual paths

Dan Hecht created IMPALA-7153: - Summary: filesystem_client methods expect unusual paths Key: IMPALA-7153 URL: https://issues.apache.org/jira/browse/IMPALA-7153 Project: IMPALA Issue Type: Bug

[jira] [Resolved] (IMPALA-7071) Make get_fs_path() idempotent

[ https://issues.apache.org/jira/browse/IMPALA-7071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7071. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Make

[jira] [Comment Edited] (IMPALA-5555) Add timeline event to query profile to indicate that it is finished

[ https://issues.apache.org/jira/browse/IMPALA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505542#comment-16505542 ] Dan Hecht edited comment on IMPALA- at 6/8/18 12:28 AM: I don't think we

[jira] [Commented] (IMPALA-5555) Add timeline event to query profile to indicate that it is finished

[ https://issues.apache.org/jira/browse/IMPALA-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16505542#comment-16505542 ] Dan Hecht commented on IMPALA-: --- I don't think we want to guarantee that the profile finalization

[jira] [Resolved] (IMPALA-7101) Builds are timing out/hanging

[ https://issues.apache.org/jira/browse/IMPALA-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7101. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Builds are

[jira] [Updated] (IMPALA-7133) Beeswax methods return Default TException instead of real exception

[ https://issues.apache.org/jira/browse/IMPALA-7133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-7133: -- Description: An instance of this bug is that we see a "Default TException" error instead of "Query

[jira] [Updated] (IMPALA-6338) Tests fail due to runtime profile for query with limit missing pieces

[ https://issues.apache.org/jira/browse/IMPALA-6338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-6338: -- Summary: Tests fail due to runtime profile for query with limit missing pieces (was: Runtime profile

[jira] [Commented] (IMPALA-341) Remote profiles may be ignored by coordinator if query has a limit

[ https://issues.apache.org/jira/browse/IMPALA-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503551#comment-16503551 ] Dan Hecht commented on IMPALA-341: -- Once this is fixed let's consider which of the commits in

[jira] [Commented] (IMPALA-341) Remote profiles may be ignored by coordinator if query has a limit

[ https://issues.apache.org/jira/browse/IMPALA-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16503547#comment-16503547 ] Dan Hecht commented on IMPALA-341: -- Things have changed a bit since the original description was

[jira] [Created] (IMPALA-7125) test_cancellation execute_cancel_test() should have a delay before fetch

Dan Hecht created IMPALA-7125: - Summary: test_cancellation execute_cancel_test() should have a delay before fetch Key: IMPALA-7125 URL: https://issues.apache.org/jira/browse/IMPALA-7125 Project: IMPALA

[jira] [Assigned] (IMPALA-7101) Builds are timing out/hanging

[ https://issues.apache.org/jira/browse/IMPALA-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-7101: - Assignee: Dan Hecht (was: Tim Armstrong) > Builds are timing out/hanging >

[jira] [Commented] (IMPALA-7101) Builds are timing out/hanging

[ https://issues.apache.org/jira/browse/IMPALA-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500607#comment-16500607 ] Dan Hecht commented on IMPALA-7101: --- Below are the relevant logs. I think what's happening is that the

[jira] [Comment Edited] (IMPALA-7101) Builds are timing out/hanging

[ https://issues.apache.org/jira/browse/IMPALA-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500556#comment-16500556 ] Dan Hecht edited comment on IMPALA-7101 at 6/4/18 5:24 PM: --- I reproduced a

[jira] [Commented] (IMPALA-7101) Builds are timing out/hanging

[ https://issues.apache.org/jira/browse/IMPALA-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16500556#comment-16500556 ] Dan Hecht commented on IMPALA-7101: --- I reproduced a hang by looping test_cancellation.py. After a few

[jira] [Comment Edited] (IMPALA-7098) Re-enable blocksize-related tests under EC

[ https://issues.apache.org/jira/browse/IMPALA-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498560#comment-16498560 ] Dan Hecht edited comment on IMPALA-7098 at 6/1/18 8:59 PM: --- What value does

[jira] [Commented] (IMPALA-7098) Re-enable blocksize-related tests under EC

[ https://issues.apache.org/jira/browse/IMPALA-7098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498560#comment-16498560 ] Dan Hecht commented on IMPALA-7098: --- What value does mBlockSize on the return of hdfsGetPathInfo()

[jira] [Updated] (IMPALA-7099) test_unsupported_text_compression fails: Expected one file per partition dir

[ https://issues.apache.org/jira/browse/IMPALA-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-7099: -- Priority: Major (was: Blocker) Lowering priority – the xfail should avoid the build failure. I'll

[jira] [Updated] (IMPALA-7109) TestPartitionMetadata::test_multiple_partitions_same_location uses incorrect paths

[ https://issues.apache.org/jira/browse/IMPALA-7109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-7109: -- Summary: TestPartitionMetadata::test_multiple_partitions_same_location uses incorrect paths (was:

[jira] [Created] (IMPALA-7109) estPartitionMetadata::test_multiple_partitions_same_location uses incorrect paths

Dan Hecht created IMPALA-7109: - Summary: estPartitionMetadata::test_multiple_partitions_same_location uses incorrect paths Key: IMPALA-7109 URL: https://issues.apache.org/jira/browse/IMPALA-7109

[jira] [Commented] (IMPALA-7099) test_unsupported_text_compression fails: Expected one file per partition dir

[ https://issues.apache.org/jira/browse/IMPALA-7099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16498244#comment-16498244 ] Dan Hecht commented on IMPALA-7099: --- The problem is that the filesystem_client method calls expect a

[jira] [Resolved] (IMPALA-7068) Failed test: metadata.test_partition_metadata.TestPartitionMetadataUncompressedTextOnly.test_unsupported_text_compression on S3

[ https://issues.apache.org/jira/browse/IMPALA-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7068. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 > Failed test: >

[jira] [Created] (IMPALA-7071) Make get_fs_path() idempotent

Dan Hecht created IMPALA-7071: - Summary: Make get_fs_path() idempotent Key: IMPALA-7071 URL: https://issues.apache.org/jira/browse/IMPALA-7071 Project: IMPALA Issue Type: Improvement

[jira] [Assigned] (IMPALA-7068) Failed test: metadata.test_partition_metadata.TestPartitionMetadataUncompressedTextOnly.test_unsupported_text_compression on S3

[ https://issues.apache.org/jira/browse/IMPALA-7068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-7068: - Assignee: Dan Hecht > Failed test: >

[jira] [Commented] (IMPALA-7069) Java UDF tests can trigger a crash in Java ClassLoader

[ https://issues.apache.org/jira/browse/IMPALA-7069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489466#comment-16489466 ] Dan Hecht commented on IMPALA-7069: --- Any idea the earliest githash we first saw this at? Presumably

[jira] [Commented] (IMPALA-7067) sleep(100000) command from test_shell_commandline.py can hang around and cause test_metrics_are_zero to fail

[ https://issues.apache.org/jira/browse/IMPALA-7067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16489278#comment-16489278 ] Dan Hecht commented on IMPALA-7067: --- Does the close RPC show up in the log? i.e. do we think this is a

[jira] [Commented] (IMPALA-5212) consider switching to pread by default

[ https://issues.apache.org/jira/browse/IMPALA-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16488228#comment-16488228 ] Dan Hecht commented on IMPALA-5212: --- That reminds me that I vaguely recall the S3A path may have

[jira] [Commented] (IMPALA-5212) consider switching to pread by default

[ https://issues.apache.org/jira/browse/IMPALA-5212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16487719#comment-16487719 ] Dan Hecht commented on IMPALA-5212: --- It'd be good to do this to reduce the number of code paths. Pread

[jira] [Resolved] (IMPALA-7024) Convert Coordinator::wait_lock_ from boost::mutex to SpinLock

[ https://issues.apache.org/jira/browse/IMPALA-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7024. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Convert

[jira] [Updated] (IMPALA-6235) Reduce runtime of test_admission_control in exhaustive build

[ https://issues.apache.org/jira/browse/IMPALA-6235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-6235: -- Labels: admission-control resource-management (was: resource-management) > Reduce runtime of

[jira] [Created] (IMPALA-7046) Add targeted regression test for race in IMPALA-7033

Dan Hecht created IMPALA-7046: - Summary: Add targeted regression test for race in IMPALA-7033 Key: IMPALA-7046 URL: https://issues.apache.org/jira/browse/IMPALA-7046 Project: IMPALA Issue Type:

[jira] [Resolved] (IMPALA-7030) crash in impala::PartitionedAggregationNode::ProcessBatchNoGrouping

[ https://issues.apache.org/jira/browse/IMPALA-7030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-7030. --- Resolution: Duplicate Assignee: Dan Hecht I'm pretty sure this corruption has the same root

[jira] [Assigned] (IMPALA-7033) Impala crashes on exhaustive release tests

[ https://issues.apache.org/jira/browse/IMPALA-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-7033: - Assignee: Dan Hecht Fix Version/s: Impala 3.1.0 Was able to confirm the race was in

[jira] [Reopened] (IMPALA-5384) Simplify coordinator locking protocol

[ https://issues.apache.org/jira/browse/IMPALA-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reopened IMPALA-5384: --- I backed out the last change because it's suspected that it causes IMPALA-7033. I think thre is a

[jira] [Commented] (IMPALA-7033) Impala crashes on exhaustive release tests

[ https://issues.apache.org/jira/browse/IMPALA-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476636#comment-16476636 ] Dan Hecht commented on IMPALA-7033: --- The revert has merged. I'm not 100% sure that commit was the

[jira] [Commented] (IMPALA-7033) Impala crashes on exhaustive release tests

[ https://issues.apache.org/jira/browse/IMPALA-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476336#comment-16476336 ] Dan Hecht commented on IMPALA-7033: --- I put a review for the revert here:

[jira] [Commented] (IMPALA-7033) Impala crashes on exhaustive release tests

[ https://issues.apache.org/jira/browse/IMPALA-7033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476268#comment-16476268 ] Dan Hecht commented on IMPALA-7033: --- What git hash did we first observe the failure? > Impala crashes

[jira] [Commented] (IMPALA-7023) TestInsertQueries.test_insert_overwrite fails by hitting memory limit

[ https://issues.apache.org/jira/browse/IMPALA-7023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16476263#comment-16476263 ] Dan Hecht commented on IMPALA-7023: --- Do we know the earliest githash we hit this on? Are we sure this

[jira] [Resolved] (IMPALA-5384) Simplify coordinator locking protocol

[ https://issues.apache.org/jira/browse/IMPALA-5384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-5384. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Simplify

[jira] [Commented] (IMPALA-4268) Allow PlanRootSink to buffer more than a batch of rows

[ https://issues.apache.org/jira/browse/IMPALA-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16474634#comment-16474634 ] Dan Hecht commented on IMPALA-4268: --- [~tarmstrong], do you also expect to solve IMPALA-1618 with that?

[jira] [Resolved] (IMPALA-1790) FetchResults() sometimes returns very few resuts

[ https://issues.apache.org/jira/browse/IMPALA-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-1790. --- Resolution: Duplicate > FetchResults() sometimes returns very few resuts >

[jira] [Created] (IMPALA-7024) Convert Coordinator::wait_lock_ from boost::mutex to SpinLock

Dan Hecht created IMPALA-7024: - Summary: Convert Coordinator::wait_lock_ from boost::mutex to SpinLock Key: IMPALA-7024 URL: https://issues.apache.org/jira/browse/IMPALA-7024 Project: IMPALA

[jira] [Commented] (IMPALA-7007) Kudu duplicate key count can be off

[ https://issues.apache.org/jira/browse/IMPALA-7007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471256#comment-16471256 ] Dan Hecht commented on IMPALA-7007: --- Probably overflowing this: {code:java} // Error message exchange

[jira] [Created] (IMPALA-7011) Cleanups around PlanRootSink::CloseConsumer()

Dan Hecht created IMPALA-7011: - Summary: Cleanups around PlanRootSink::CloseConsumer() Key: IMPALA-7011 URL: https://issues.apache.org/jira/browse/IMPALA-7011 Project: IMPALA Issue Type:

[jira] [Resolved] (IMPALA-6993) Don't print status stack trace when propagating thrift status in Coordinator::BackendState::Exec()

[ https://issues.apache.org/jira/browse/IMPALA-6993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht resolved IMPALA-6993. --- Resolution: Fixed Fix Version/s: Impala 3.1.0 Impala 2.13.0 > Don't print

[jira] [Created] (IMPALA-6993) Don't print status stack trace when propagating thrift status in Coordinator::BackendState::Exec()

Dan Hecht created IMPALA-6993: - Summary: Don't print status stack trace when propagating thrift status in Coordinator::BackendState::Exec() Key: IMPALA-6993 URL: https://issues.apache.org/jira/browse/IMPALA-6993

[jira] [Created] (IMPALA-6984) Coordinator should cancel backends when returning EOS

Dan Hecht created IMPALA-6984: - Summary: Coordinator should cancel backends when returning EOS Key: IMPALA-6984 URL: https://issues.apache.org/jira/browse/IMPALA-6984 Project: IMPALA Issue Type:

[jira] [Assigned] (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:all-tabpanel ] Dan Hecht reassigned IMPALA-1262: - Assignee: Bikramjeet Vig > user initiated query cancellation should return operation_state = >

[jira] [Created] (IMPALA-6983) stress test binary search exits if process mem_limit is too low

Dan Hecht created IMPALA-6983: - Summary: stress test binary search exits if process mem_limit is too low Key: IMPALA-6983 URL: https://issues.apache.org/jira/browse/IMPALA-6983 Project: IMPALA

[jira] [Assigned] (IMPALA-1871) Impala is unable to read timestamp field value in avro written by hive

[ https://issues.apache.org/jira/browse/IMPALA-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-1871: - Assignee: Zoltan Ivanfi (was: Dan Hecht) [~zi], I've lost track of where this is at. Can you

[jira] [Assigned] (IMPALA-1034) Verify RSS stays within mem_limit + JVM heapsize

[ https://issues.apache.org/jira/browse/IMPALA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht reassigned IMPALA-1034: - Assignee: Tim Armstrong (was: Dan Hecht) Summary: Verify RSS stays within mem_limit + JVM

[jira] [Commented] (IMPALA-6882) Inline assembly instructions hoisted out of if(CpuInfo::IsSupported()) checks

[ https://issues.apache.org/jira/browse/IMPALA-6882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460044#comment-16460044 ] Dan Hecht commented on IMPALA-6882: --- Oh, weird. I guess technically it's still keeping the ordering

[jira] [Updated] (IMPALA-6954) Kudu CTAS Loses Partitioning

[ https://issues.apache.org/jira/browse/IMPALA-6954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Hecht updated IMPALA-6954: -- Component/s: Frontend > Kudu CTAS Loses Partitioning > > >