[jira] [Updated] (IMPALA-7789) Impala 3.1 Doc: Admission Control Status in Impala Shell
[ https://issues.apache.org/jira/browse/IMPALA-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rodoni updated IMPALA-7789: Summary: Impala 3.1 Doc: Admission Control Status in Impala Shell (was: Impala 3.2 Doc: Admission Control Status in Impala Shell) > Impala 3.1 Doc: Admission Control Status in Impala Shell > > > Key: IMPALA-7789 > URL: https://issues.apache.org/jira/browse/IMPALA-7789 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_32 > Fix For: Impala 3.1.0 > > -- 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-7532) Add retry/back-off to fetch-from-catalog RPCs
[ https://issues.apache.org/jira/browse/IMPALA-7532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-7532: -- Fix Version/s: (was: Impala 3.2.0) Since 3.1.0 isn't out yet, presumably anything in master will make it to 3.1.0. As such, I have changed the fix version to 3.1.0. > Add retry/back-off to fetch-from-catalog RPCs > - > > Key: IMPALA-7532 > URL: https://issues.apache.org/jira/browse/IMPALA-7532 > Project: IMPALA > Issue Type: Sub-task >Reporter: Todd Lipcon >Assignee: Tianyi Wang >Priority: Major > > Currently if there is an error connecting to the catalog server, the 'fetch > from catalog' implementation will retry with no apparent backoff. We should > retry for some period of time with backoff in between the attempts, so that > impala can ride over short interruptions of the catalog 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] [Updated] (IMPALA-5946) Add TPC-DS Q58 to functional tests
[ https://issues.apache.org/jira/browse/IMPALA-5946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-5946: -- Fix Version/s: (was: Impala 3.2.0) Since 3.1.0 isn't out yet, presumably anything in master will make it to 3.1.0. As such, I have changed the fix version to 3.1.0. > Add TPC-DS Q58 to functional tests > -- > > Key: IMPALA-5946 > URL: https://issues.apache.org/jira/browse/IMPALA-5946 > Project: IMPALA > Issue Type: Test > Components: Infrastructure >Affects Versions: Impala 2.10.0 >Reporter: Tim Wood >Assignee: Tim Armstrong >Priority: Major > Labels: TPCDS, decimal > Attachments: ttq-212.out, ttq-214.out > > > Because of our decimal_v2 rounding rules, the results lack some precision of > the reference answers. > Original description > bq. See attached query (tpcds-q58.test) + outputs. ttq-212.out uses float > constants in expressions, ttq-214.out uses integer constants. Both lose > precision. -- 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-7213) Port ReportExecStatus() RPCs to KRPC
[ https://issues.apache.org/jira/browse/IMPALA-7213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-7213: -- Fix Version/s: (was: Impala 3.2.0) Since 3.1.0 isn't out yet, presumably anything in master will make it to 3.1.0. As such, I have changed the fix version to 3.1.0. > Port ReportExecStatus() RPCs to KRPC > > > Key: IMPALA-7213 > URL: https://issues.apache.org/jira/browse/IMPALA-7213 > Project: IMPALA > Issue Type: Sub-task > Components: Distributed Exec >Affects Versions: Impala 3.0 >Reporter: Michael Ho >Assignee: Michael Ho >Priority: Major > Labels: impala-scalability-sprint-08-13-2018 > > This is a sub-task to track the porting of ReportExecStatus() to KRPC. This > should help reduce the number of connections to coordinator. -- 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-7735) Expose admission control status in impala-shell
[ https://issues.apache.org/jira/browse/IMPALA-7735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-7735: -- Fix Version/s: (was: Impala 3.2.0) Since 3.1.0 isn't out yet, presumably anything in master will make it to 3.1.0. As such, I have changed the fix version to 3.1.0. > Expose admission control status in impala-shell > --- > > Key: IMPALA-7735 > URL: https://issues.apache.org/jira/browse/IMPALA-7735 > Project: IMPALA > Issue Type: Improvement > Components: Clients >Affects Versions: Impala 3.1.0 >Reporter: Tim Armstrong >Assignee: Bikramjeet Vig >Priority: Critical > Labels: admission-control > Attachments: Screenshot1.png > > > Following on from IMPALA-7545 we should also expose this in impala-shell. I > left some notes on that JIRA. -- 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-5956) Add TPC-DS q31 and q89 to test suite
[ https://issues.apache.org/jira/browse/IMPALA-5956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-5956: -- Fix Version/s: (was: Impala 3.2.0) Since 3.1.0 isn't out yet, presumably anything in master will make it to 3.1.0. As such, I have changed the fix version to 3.1.0. > Add TPC-DS q31 and q89 to test suite > > > Key: IMPALA-5956 > URL: https://issues.apache.org/jira/browse/IMPALA-5956 > Project: IMPALA > Issue Type: Bug > Components: Infrastructure >Reporter: Tim Wood >Assignee: Tim Armstrong >Priority: Major > Labels: tpcds > Attachments: q59-flap.out, q89-flap1.out, q89-flap2.out, ttq-243.out, > ttq-256.out > > > When run esp. as part of the TPC-DS suite, query #89 returns varying results > in the LSD of a calculation. Using the output of the previous run as the > expected result for the next run fails. This SELECT item is a ROUND() > expression, so it's not clear why the result is not deterministic. -- 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-7504) ParseKerberosPrincipal() should use krb5_parse_name() instead
[
https://issues.apache.org/jira/browse/IMPALA-7504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Apple updated IMPALA-7504:
--
Target Version: Impala 3.1.0 (was: Impala 3.2.0)
Fix Version/s: Impala 3.1.0
> ParseKerberosPrincipal() should use krb5_parse_name() instead
> -
>
> Key: IMPALA-7504
> URL: https://issues.apache.org/jira/browse/IMPALA-7504
> Project: IMPALA
> Issue Type: Improvement
> Components: Security
>Affects Versions: Impala 3.0, Impala 2.12.0
>Reporter: Michael Ho
>Priority: Minor
> Labels: ramp-up
> Fix For: Impala 3.1.0
>
>
> [~tlipcon] pointed out during code review that we should be using
> krb5_parse_name() to parse the principal instead of creating our own
> bq. I wonder whether we should just be using krb5_parse_name here instead of
> implementing our own parsing? According to
> [http://web.mit.edu/kerberos/krb5-1.15/doc/appdev/refs/api/krb5_parse_name.html]
> there are various escapings, etc, that this function isn't currently
> supporting.
> We currently do the following to parse the principal:
> {noformat}
> vector names;
> split(names, principal, is_any_of("/"));
> if (names.size() != 2) return Status(TErrorCode::BAD_PRINCIPAL_FORMAT,
> principal);
> *service_name = names[0];
> string remaining_principal = names[1];
> split(names, remaining_principal, is_any_of("@"));
> if (names.size() != 2) return Status(TErrorCode::BAD_PRINCIPAL_FORMAT,
> principal);
> {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] [Updated] (IMPALA-7789) Impala 3.2 Doc: Admission Control Status in Impala Shell
[ https://issues.apache.org/jira/browse/IMPALA-7789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-7789: -- Target Version: Impala 3.1.0 (was: Impala 3.2.0) Fix Version/s: Impala 3.1.0 > Impala 3.2 Doc: Admission Control Status in Impala Shell > > > Key: IMPALA-7789 > URL: https://issues.apache.org/jira/browse/IMPALA-7789 > Project: IMPALA > Issue Type: Sub-task > Components: Docs >Reporter: Alex Rodoni >Assignee: Alex Rodoni >Priority: Major > Labels: future_release_doc, in_32 > Fix For: Impala 3.1.0 > > -- 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-6656) Metrics for time spent in BufferAllocator
[ https://issues.apache.org/jira/browse/IMPALA-6656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-6656: -- Target Version: Impala 3.1.0 (was: Impala 3.2.0) Fix Version/s: Impala 3.1.0 > Metrics for time spent in BufferAllocator > - > > Key: IMPALA-6656 > URL: https://issues.apache.org/jira/browse/IMPALA-6656 > Project: IMPALA > Issue Type: Improvement > Components: Backend >Reporter: Tim Armstrong >Assignee: Tim Armstrong >Priority: Major > Labels: observability, resource-management > Fix For: Impala 3.1.0 > > > We should track the total time spent and the time spent in TCMalloc so we can > understand where time is going globally. > I think we should shard these metrics across the arenas so we can see if the > problem is just per-arena, and also to avoid contention between threads when > updating the metrics. -- 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-7665) Bringing up stopped statestore causes queries to fail
[
https://issues.apache.org/jira/browse/IMPALA-7665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Apple updated IMPALA-7665:
--
Target Version: Impala 3.1.0 (was: Impala 3.2.0)
Fix Version/s: Impala 3.1.0
> Bringing up stopped statestore causes queries to fail
> -
>
> Key: IMPALA-7665
> URL: https://issues.apache.org/jira/browse/IMPALA-7665
> Project: IMPALA
> Issue Type: Bug
> Components: Distributed Exec
>Affects Versions: Impala 3.1.0
>Reporter: Tim Armstrong
>Priority: Major
> Labels: statestore
> Fix For: Impala 3.1.0
>
>
> I can reproduce this by running a long-running query then cycling the
> statestore:
> {noformat}
> tarmstrong@tarmstrong-box:~/Impala/incubator-impala$ impala-shell.sh -q
> "select distinct * from tpch10_parquet.lineitem"
> Starting Impala Shell without Kerberos authentication
> Connected to localhost:21000
> Server version: impalad version 3.1.0-SNAPSHOT DEBUG (build
> c486fb9ea4330e1008fa9b7ceaa60492e43ee120)
> Query: select distinct * from tpch10_parquet.lineitem
> Query submitted at: 2018-10-04 17:06:48 (Coordinator:
> http://tarmstrong-box:25000)
> {noformat}
> If I kill the statestore, the query runs fine, but if I start up the
> statestore again, it fails.
> {noformat}
> # In one terminal, start up the statestore
> $
> /home/tarmstrong/Impala/incubator-impala/be/build/latest/statestore/statestored
> -log_filename=statestored
> -log_dir=/home/tarmstrong/Impala/incubator-impala/logs/cluster -v=1
> -logbufsecs=5 -max_log_files=10
> # The running query then fails
> WARNINGS: Failed due to unreachable impalad(s): tarmstrong-box:22001,
> tarmstrong-box:22002
> {noformat}
> Note that I've seen different subsets impalads reported as failed, e.g.
> "Failed due to unreachable impalad(s): tarmstrong-box:22001"
--
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-7350) More accurate memory estimates for admission
[ https://issues.apache.org/jira/browse/IMPALA-7350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Apple updated IMPALA-7350: -- Target Version: Impala 3.1.0 (was: Impala 3.2.0) Fix Version/s: Impala 3.1.0 > More accurate memory estimates for admission > > > Key: IMPALA-7350 > URL: https://issues.apache.org/jira/browse/IMPALA-7350 > Project: IMPALA > Issue Type: Improvement > Components: Frontend >Reporter: Tim Armstrong >Assignee: Bikramjeet Vig >Priority: Major > Labels: admission-control, resource-management > Fix For: Impala 3.1.0 > > > For IMPALA-7349, we will be relying more on memory estimates. This is an > umbrella JIRA to track improvements to memory estimates where the current > estimates are way off and result in over- or under- admission. over-admission > is probably the more significant concern. -- 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-7241) progress-updater.cc:43] Check failed: delta >= 0 (-3 vs. 0)
[
https://issues.apache.org/jira/browse/IMPALA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Apple updated IMPALA-7241:
--
Fix Version/s: (was: Impala 3.2.0)
Impala 3.1.0
> progress-updater.cc:43] Check failed: delta >= 0 (-3 vs. 0)
> ---
>
> Key: IMPALA-7241
> URL: https://issues.apache.org/jira/browse/IMPALA-7241
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Michael Brown
>Assignee: Michael Ho
>Priority: Blocker
> Labels: crash, stress
> Fix For: Impala 3.1.0
>
>
> During a stress test with 8 nodes running an insecure debug build based off
> master, an impalad hit a DCHECK. The concurrency level at the time was
> between 150-180 queries.
> The DCHECK was {{progress-updater.cc:43] Check failed: delta >= 0 (-3 vs.
> 0)}}.
> The stack was:
> {noformat}
> #0 0x7f6a73e811f7 in raise () from /lib64/libc.so.6
> #1 0x7f6a73e828e8 in abort () from /lib64/libc.so.6
> #2 0x04300e34 in google::DumpStackTraceAndExit() ()
> #3 0x042f78ad in google::LogMessage::Fail() ()
> #4 0x042f9152 in google::LogMessage::SendToLog() ()
> #5 0x042f7287 in google::LogMessage::Flush() ()
> #6 0x042fa84e in google::LogMessageFatal::~LogMessageFatal() ()
> #7 0x01f7fedd in impala::ProgressUpdater::Update(long) ()
> #8 0x0313912b in
> impala::Coordinator::BackendState::InstanceStats::Update(impala::TFragmentInstanceExecStatus
> const&, impala::Coordinator::ExecSummary*, impala::ProgressUpdater*) ()
> #9 0x031369e6 in
> impala::Coordinator::BackendState::ApplyExecStatusReport(impala::TReportExecStatusParams
> const&, impala::Coordinator::ExecSummary*, impala::ProgressUpdater*) ()
> #10 0x031250b4 in
> impala::Coordinator::UpdateBackendExecStatus(impala::TReportExecStatusParams
> const&) ()
> #11 0x01e86395 in
> impala::ClientRequestState::UpdateBackendExecStatus(impala::TReportExecStatusParams
> const&) ()
> #12 0x01e27594 in
> impala::ImpalaServer::ReportExecStatus(impala::TReportExecStatusResult&,
> impala::TReportExecStatusParams const&) ()
> #13 0x01ebb8a0 in
> impala::ImpalaInternalService::ReportExecStatus(impala::TReportExecStatusResult&,
> impala::TReportExecStatusParams const&) ()
> #14 0x02fa6f62 in
> impala::ImpalaInternalServiceProcessor::process_ReportExecStatus(int,
> apache::thrift::protocol::TProtocol*, apache::thrift::protocol::TProtocol*,
> void*) ()
> #15 0x02fa6540 in
> impala::ImpalaInternalServiceProcessor::dispatchCall(apache::thrift::protocol::TProtocol*,
> apache::thrift::protocol::TProtocol*, std::string const&, int, void*) ()
> #16 0x018892b0 in
> apache::thrift::TDispatchProcessor::process(boost::shared_ptr,
> boost::shared_ptr, void*) ()
> #17 0x01c80d1b in
> apache::thrift::server::TAcceptQueueServer::Task::run() ()
> #18 0x01c78ffb in
> impala::ThriftThread::RunRunnable(boost::shared_ptr,
> impala::Promise*) ()
> #19 0x01c7a721 in boost::_mfi::mf2 boost::shared_ptr,
> impala::Promise (impala::PromiseMode)0>*>::operator()(impala::ThriftThread*,
> boost::shared_ptr,
> impala::Promise*) const ()
> #20 0x01c7a5b7 in void
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*>
> >::operator() boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list0>(boost::_bi::type, boost::_mfi::mf2 impala::ThriftThread,
> boost::shared_ptr,
> impala::Promise*>&,
> boost::_bi::list0&, int) ()
> #21 0x01c7a303 in boost::_bi::bind_t impala::ThriftThread,
> boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*> >
> >::operator()() ()
> #22 0x01c7a216 in
> boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf2 boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*> >
> >, void>::invoke(boost::detail::function::function_buffer&) ()
> #23 0x01bbb81c in boost::function0::operator()() const ()
> #24 0x01fb6eaf in impala::Thread::SuperviseThread(std::string const&,
> std::string const&, boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*) ()
> #25 0x01fbef87 in void
> boost::_bi::list5,
> boost::_bi::value, boost::_bi::value >,
> boost::_bi::value,
> boost::_bi::value*>
> >::operator() boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*),
> boost::_bi::list0>(boost::_bi::type, void (*&)(std::string const&,
> std::string const&, boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*), boost::_bi::list0&, int) ()
> #26 0x01fbeeab in boost::_bi::bind_t const&,
[jira] [Updated] (IMPALA-7241) progress-updater.cc:43] Check failed: delta >= 0 (-3 vs. 0)
[
https://issues.apache.org/jira/browse/IMPALA-7241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jim Apple updated IMPALA-7241:
--
Target Version: Impala 3.1.0 (was: Impala 3.2.0)
> progress-updater.cc:43] Check failed: delta >= 0 (-3 vs. 0)
> ---
>
> Key: IMPALA-7241
> URL: https://issues.apache.org/jira/browse/IMPALA-7241
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.1.0
>Reporter: Michael Brown
>Assignee: Michael Ho
>Priority: Blocker
> Labels: crash, stress
> Fix For: Impala 3.2.0
>
>
> During a stress test with 8 nodes running an insecure debug build based off
> master, an impalad hit a DCHECK. The concurrency level at the time was
> between 150-180 queries.
> The DCHECK was {{progress-updater.cc:43] Check failed: delta >= 0 (-3 vs.
> 0)}}.
> The stack was:
> {noformat}
> #0 0x7f6a73e811f7 in raise () from /lib64/libc.so.6
> #1 0x7f6a73e828e8 in abort () from /lib64/libc.so.6
> #2 0x04300e34 in google::DumpStackTraceAndExit() ()
> #3 0x042f78ad in google::LogMessage::Fail() ()
> #4 0x042f9152 in google::LogMessage::SendToLog() ()
> #5 0x042f7287 in google::LogMessage::Flush() ()
> #6 0x042fa84e in google::LogMessageFatal::~LogMessageFatal() ()
> #7 0x01f7fedd in impala::ProgressUpdater::Update(long) ()
> #8 0x0313912b in
> impala::Coordinator::BackendState::InstanceStats::Update(impala::TFragmentInstanceExecStatus
> const&, impala::Coordinator::ExecSummary*, impala::ProgressUpdater*) ()
> #9 0x031369e6 in
> impala::Coordinator::BackendState::ApplyExecStatusReport(impala::TReportExecStatusParams
> const&, impala::Coordinator::ExecSummary*, impala::ProgressUpdater*) ()
> #10 0x031250b4 in
> impala::Coordinator::UpdateBackendExecStatus(impala::TReportExecStatusParams
> const&) ()
> #11 0x01e86395 in
> impala::ClientRequestState::UpdateBackendExecStatus(impala::TReportExecStatusParams
> const&) ()
> #12 0x01e27594 in
> impala::ImpalaServer::ReportExecStatus(impala::TReportExecStatusResult&,
> impala::TReportExecStatusParams const&) ()
> #13 0x01ebb8a0 in
> impala::ImpalaInternalService::ReportExecStatus(impala::TReportExecStatusResult&,
> impala::TReportExecStatusParams const&) ()
> #14 0x02fa6f62 in
> impala::ImpalaInternalServiceProcessor::process_ReportExecStatus(int,
> apache::thrift::protocol::TProtocol*, apache::thrift::protocol::TProtocol*,
> void*) ()
> #15 0x02fa6540 in
> impala::ImpalaInternalServiceProcessor::dispatchCall(apache::thrift::protocol::TProtocol*,
> apache::thrift::protocol::TProtocol*, std::string const&, int, void*) ()
> #16 0x018892b0 in
> apache::thrift::TDispatchProcessor::process(boost::shared_ptr,
> boost::shared_ptr, void*) ()
> #17 0x01c80d1b in
> apache::thrift::server::TAcceptQueueServer::Task::run() ()
> #18 0x01c78ffb in
> impala::ThriftThread::RunRunnable(boost::shared_ptr,
> impala::Promise*) ()
> #19 0x01c7a721 in boost::_mfi::mf2 boost::shared_ptr,
> impala::Promise (impala::PromiseMode)0>*>::operator()(impala::ThriftThread*,
> boost::shared_ptr,
> impala::Promise*) const ()
> #20 0x01c7a5b7 in void
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*>
> >::operator() boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list0>(boost::_bi::type, boost::_mfi::mf2 impala::ThriftThread,
> boost::shared_ptr,
> impala::Promise*>&,
> boost::_bi::list0&, int) ()
> #21 0x01c7a303 in boost::_bi::bind_t impala::ThriftThread,
> boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*> >
> >::operator()() ()
> #22 0x01c7a216 in
> boost::detail::function::void_function_obj_invoker0 boost::_mfi::mf2 boost::shared_ptr,
> impala::Promise*>,
> boost::_bi::list3,
> boost::_bi::value >,
> boost::_bi::value*> >
> >, void>::invoke(boost::detail::function::function_buffer&) ()
> #23 0x01bbb81c in boost::function0::operator()() const ()
> #24 0x01fb6eaf in impala::Thread::SuperviseThread(std::string const&,
> std::string const&, boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*) ()
> #25 0x01fbef87 in void
> boost::_bi::list5,
> boost::_bi::value, boost::_bi::value >,
> boost::_bi::value,
> boost::_bi::value*>
> >::operator() boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*),
> boost::_bi::list0>(boost::_bi::type, void (*&)(std::string const&,
> std::string const&, boost::function, impala::ThreadDebugInfo const*,
> impala::Promise*), boost::_bi::list0&, int) ()
> #26 0x01fbeeab in boost::_bi::bind_t const&, std::string const&,
[jira] [Commented] (IMPALA-6910) Multiple tests failing on S3 build: error reading from HDFS file
[
https://issues.apache.org/jira/browse/IMPALA-6910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16674009#comment-16674009
]
Steve Loughran commented on IMPALA-6910:
Does the test overwrite a path which has been used for previous test runs with
the delete only kicking off before this test run? If so, you are seeing delayed
delete consistency
> Multiple tests failing on S3 build: error reading from HDFS file
>
>
> Key: IMPALA-6910
> URL: https://issues.apache.org/jira/browse/IMPALA-6910
> Project: IMPALA
> Issue Type: Bug
> Components: Backend
>Affects Versions: Impala 3.0
>Reporter: David Knupp
>Assignee: Sailesh Mukil
>Priority: Critical
> Labels: broken-build, flaky, s3
> Fix For: Impala 3.1.0
>
>
> Stacktrace
> {noformat}
> query_test/test_compressed_formats.py:149: in test_seq_writer
> self.run_test_case('QueryTest/seq-writer', vector, unique_database)
> common/impala_test_suite.py:397: in run_test_case
> result = self.__execute_query(target_impalad_client, query, user=user)
> common/impala_test_suite.py:612: in __execute_query
> return impalad_client.execute(query, user=user)
> common/impala_connection.py:160: in execute
> return self.__beeswax_client.execute(sql_stmt, user=user)
> beeswax/impala_beeswax.py:173: in execute
> handle = self.__execute_query(query_string.strip(), user=user)
> beeswax/impala_beeswax.py:341: in __execute_query
> self.wait_for_completion(handle)
> beeswax/impala_beeswax.py:361: in wait_for_completion
> raise ImpalaBeeswaxException("Query aborted:" + error_log, None)
> E ImpalaBeeswaxException: ImpalaBeeswaxException:
> EQuery aborted:Disk I/O error: Error reading from HDFS file:
> s3a://impala-cdh5-s3-test/test-warehouse/tpcds.store_sales_parquet/ss_sold_date_sk=2452585/a5482dcb946b6c98-7543e0dd0004_95929617_data.0.parq
> E Error(255): Unknown error 255
> E Root cause: SdkClientException: Data read has a different length than the
> expected: dataLength=8576; expectedLength=17785; includeSkipped=true;
> in.getClass()=class com.amazonaws.services.s3.AmazonS3Client$2;
> markedSupported=false; marked=0; resetSinceLastMarked=false; markCount=0;
> resetCount=0
> {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
