Re: ASF Board Meeting Summary - November 15, 2017

Woohoo! On Thu, Nov 16, 2017 at 6:51 AM, Jeszy wrote: > Congrats, very glad to hear! > > On 16 November 2017 at 04:56, Tom White wrote: > > Well done, and thanks to everyone who has contributed to Impala. Also, > > thanks Jim for your tireless work on Apache infrastructure and > > procedural ma

Need to rebase Impala-lzo

I'm in the midst of a coordinated change to impala/Impala-lzo that will require you to rebase Impala-lzo once this Impala change goes in: https://gerrit.cloudera.org/#/c/8424/ Fortunately the Impala-lzo change is written to be backward compatible for the moment, so you can rebase your local checko

Re: Impalad Process Crash

Crashes in tcmalloc::CentralFreeList::FetchFromSpans() or in TCMalloc functions in general usually indicate a heap corruption bug (e.g. a double-free or a free of an invalid pointer). The stack trace often isn't useful because the corruption happened on a different thread. These are among the hard

Re: build broken

Thanks for investigating Jin Chul. I came to the same conclusion and merged the change. On Tue, Dec 5, 2017 at 5:57 PM, Jin Chul Kim wrote: > Hi, > > Currently Impala build is broken because the child change was merged > without the merge of the parent change. > > (parent) https://gerrit.clouder

Re: build broken

ry > > for missing that during code review. > > > > On Tue, Dec 5, 2017 at 6:00 PM, Tim Armstrong > > wrote: > > > > > Thanks for investigating Jin Chul. I came to the same conclusion and > > merged > > > the change. > > > > >

Re: build broken

nge -- you'll > need to explicitly merge part 1 first. > > On Wed, Dec 6, 2017 at 8:41 AM, Tim Armstrong > wrote: > > > I think that's a consequence of the "cherry pick" merge strategy. It does > > seem like a flaw in our merge process. It would be n

Re: [DISCUSS] 2.11.0 release

I think that makes sense. We'll have to go through the fix versions of recent JIRAs and make sure that they weren't set to 2.12 though. On Thu, Dec 7, 2017 at 9:33 AM, Thomas Tauber-Marshall < tmarsh...@cloudera.com> wrote: > Since the response from the community has been good, and now that all o

Re: [DISCUSS] 2.11.0 release

It looks like https://issues.apache.org/jira/browse/IMPALA-5017 caused https://issues.apache.org/jira/browse/IMPALA-6284, so maybe we should not include IMPALA-5017 in the 2.11 release also. On Thu, Dec 7, 2017 at 9:43 AM, Jim Apple wrote: > I think it would be great to get a fix for > https://i

Re: [DISCUSS] 2.11.0 release

Actually it looks like we have a new blocker that Taras filed: https://issues.apache.org/jira/browse/IMPALA-6292 On Thu, Dec 7, 2017 at 10:03 AM, Tim Armstrong wrote: > I think that makes sense. We'll have to go through the fix versions of > recent JIRAs and make sure that they wer

Re: Re: How to control max memory usage in JNI

The catalog is cached on all Impala daemons so you also need to increase the impalad heap size too. There's a brief explanation in the docs: https://impala.apache.org/docs/build/html/topics/impala_scalability.html (see the "Impact of Many Tables or Partitions on Impala Catalog Performance and Memor

Switch gerrit merge strategy to "rebase always"?

We recently had a bad merge that was allowed by the cherry-pick merge strategy merging a simple without its ancestor (since they didn't change any nearby lines): https://lists.apache.org/thread.html/ee81ee3e396a9a7b1214d92d713a2d28f2f1f7058184504ebc399170@%3Cdev.impala.apache.org%3E It looks like

Re: Switch gerrit merge strategy to "rebase always"?

the web. The committer header is also set to the > submitter, while the author header retains the original patch set author." > > I love that short message. It's useful to be able to easily see the code > review comments and reviewer names. > > On Mon, Dec 11, 2017 at 11:

Re: Switch gerrit merge strategy to "rebase always"?

Ok, I went ahead and changed it in gerrit. Let me know if you have any problems with it. On Mon, Dec 11, 2017 at 11:58 AM, Philip Zeyliger wrote: > Seems like it's the right thing to do. > > On Mon, Dec 11, 2017 at 11:43 AM, Tim Armstrong > wrote: > > > We recentl

New Impala Contributors: IMPALA-6296

If you'd like to contribute a patch to Impala, but aren't sure what you want to work on, you can look at Impala's newbie issues: https://issues.apache.org/jira/issues/?filter=12341668. You can find detailed instructions on submitting patches at https://cwiki.apache.org/confluence/display/IMPALA/Con

Re: A couple of questions

1. I think you're right that many of the shell tests don't inherently require to be executed serially. Some of them would require work to execute in parallel, particularly the ones that inspect files like .impalahistory and tests that check the values of global impala daemon metrics. 2. Yes, Java

Re: Joining Impala mailing list

Hi Xinran, That looks like a good JIRA to start with. I wasn't able to figure out your Apache JIRA username but please feel free to assign it to yourself (or let us know if you need permissions to do so) Cheers, Tim On Tue, Jan 2, 2018 at 4:30 PM, kenneth mcfarland < kennethpmcfarl...@gmail.com

Re: Could anybody help to explain why there is such a big gap in 'ProbeTime' and How to fix this gap?

That's a tricky one. I have a couple of ideas but it's a bit difficult to confirm since the profile isn't really designed to easily answer questions like this. ProbeTime measures wall-clock time rather than actual time spent executing on the CPU. My first guess is that it's because the Kudu scan i

Re: Re: Undefined Symbol: getJNIEnv

That symbol is defined in libhdfs.so or libhdfs.a. You could try using ldd on catalogd to investigate why it isn't able to find libhdfs.so at runtime. On Wed, Jan 3, 2018 at 1:54 AM, sky wrote: > I used Centos 6.5. > In addition to recompiling, are there any other ways ? > > > > > > > > > At 201

Re: Joining Impala mailing list

e > "Contributors" box. A text box will appear to the right of the > contributor box. > > 3. Type the name of the person in that box to attempt to find their > Apache JIRA username. > > 4. Once you have it, press "Update" > > > On Wed, Jan 3, 2018

Re: Build error

The error is probably higher up in your console output. The lines you have there look like the side-effects of parallel build tasks being killed off after an earlier failure. The below line hints that the failure may have been in building the frontend Java: fe/CMakeFiles/fe.dir/build.make:57: r

Re: .test file format

It is possible to get the test infra to generate .test files based on the actual output. For planner tests, they automatically get written to logs/fe_tests/PlannerTest/. If you're running end-to-end tests with impala-py.test, you can use the --update_results flag to get it to generate similar file

Re: Accumulo Integration [SEC=UNOFFICIAL]

I agree that the HBase integration would be a reasonable starting point to look at. The Kudu integration is also interesting because there are also similarities and the integration is generally more optimised and featureful. I think the devil is in the details - like Jim mentioned, auth can be tri

Re: Cancellation logic in HdfsScanners

ScannerContext::cancelled() == true means that the scan has completed, either because it has returned enough rows, because the query is cancelled, or because it hit an error. RuntimeState::cancelled() == true means that the query is cancelled. So there are cases where ScannerContext::cancelled()

Re: Contributor bit for Alex Rodoni?

I added her as a contributor in JIRA admin and tested assigning her IMPALA-3330. Seems to work. On Tue, Jan 16, 2018 at 12:04 PM, John Russell wrote: > Hi, > > Alex Rodoni will be contributing to the upstream Apache Impala docs. I > can see her user profile here: > > https://issues.apache.org/j

Re: Re: Cancellation logic in HdfsScanners

-+ > > When errors happen in F00, cancellation rpc will be sent to F01. However, the > hdfs scanner in F01 does not notice it in time and pass up all the row > batches. Then the DataStreamSender will try to send these row batch

Re: Re: Cancellation logic in HdfsScanners

Would you be able to file a JIRA? On Tue, Jan 16, 2018 at 3:00 PM, Tim Armstrong wrote: > Looks to me like you found a bug. I think the scanners should be checking > both cancellation conditions, i.e. RuntimeState::is_cancelled_ for MT and > non-MT scanners and hdfs_scan_node::done_ f

Re: Re: Re: Cancellation logic in HdfsScanners

y don't they just check > about RuntimeState::is_cancelled()? Are there any reasons that they > should go ahead until HdfsScanNode::done()? > > At 2018-01-17 07:00:51, "Tim Armstrong" wrote: > > Looks to me like you found a bug. I think the scanners should be checking > bo

Re: [Ready for Review] IMPALA-5717: Support reading from ORC format files

Thank you! I had few higher-level questions or thoughts: * Assuming we end up using the ORC C++ library, we probably want to manage it in the same way that we do Avro by building it externally and then linking against it (we use the native-toolchain project for convenience). Importing the code se

Re: Query compilation approach

Thanks for sharing. I think we have some of the infrastructure required to do something similar - we have an interpreted path already and we could swap in compiled versions of functions by updating function pointers. Michael Ho and I have talked about doing async codegen before or even having a c

Re: ERROR: NotImplementedException: MT_DOP not supported

We don't support multithreaded execution for all plans currently. I think the docs do a good job of explaining the current limitations: https://impala.apache.org/docs/build/html/topics/impala_mt_dop.html On Mon, Feb 5, 2018 at 1:05 PM, Xinran Yu Tinney wrote: > Hi, Impala dev, >I was creatin

Re: ERROR: NotImplementedException: MT_DOP not supported

was not aware > that. basically, I was trying to insert some values in a partitioned table > and trying to find a way set a specific row's numDVs and the error > happened. > > 2018-02-05 15:24 GMT-06:00 Tim Armstrong : > > > We don't support multithreaded execution for

Re: Any design docs about the buffer pool

I put together this summary to explain to reviewers the overall scope of the work: https://docs.google.com/presentation/d/1zSVATeUmhAmA6JvIWH4ODbhjsnx554WLeupigmUwi9g/edit#slide=id.p This was the top-level JIRA that tracked all of the work: https://issues.apache.org/jira/browse/IMPALA-3200 On Thu

ORC scanner - points for discussion

Quanlong has done a bunch of work implementing an ORC scanner. I've been playing around with it and it works pretty nicely - I can load and run TPC-H with no problem! It's a big addition to Impala and the integration with the external library has caused some implementation challenges, so I wanted

Re: Re: ORC scanner - points for discussion

Putting it behind a flag sounds good to me too. Hopefully we can get feedback from Hulu and other users of Impala that will try out the experimental version. On Mon, Feb 12, 2018 at 10:26 AM, Dimitris Tsirogiannis < dtsirogian...@cloudera.com> wrote: > Does the patch also implement an ORC writer?

Re: Re: Re: ORC scanner - points for discussion

Maybe it would make sense to create an Epic in JIRA for ORC scanner enhancements, following on from the initial implementation. I don't really feel strongly as long as the related JIRAs are linked together somehow. On Mon, Feb 12, 2018 at 1:42 PM, Quanlong Huang wrote: > Dimitris, as the first s

Re: Re: Re: Build fail in native-toolchain project

There are. I tried to document the list at some point here: https://cwiki.apache.org/confluence/display/IMPALA/Building+native-toolchain+from+scratch+and+using+with+Impala I believe that covers most of them, but it may be slightly stale. Please feel free to update the list or let us know if someth

Re: Inconsistent float/double sort order in spec and implementations can lead to incorrect results

We could also consider treating NaN similar to NULL and having a separate piece of information with a count of NaN values (or just a bit indicating presence/absence of NaN). I'm not sure if that is easier or harder to implement than a total order. On Thu, Feb 15, 2018 at 9:12 AM, Laszlo Gaal wrot

Re: Inconsistent float/double sort order in spec and implementations can lead to incorrect results

There is an extensibility mechanism with the ColumnOrder union - I think that was meant to avoid the need to add new stat fields? Given that the bug was in the Parquet spec, we'll need to make a spec change anyway, so we could add a new ColumnOrder - FloatingPointTotalOrder? at the same time as fi

Re: Inconsistent float/double sort order in spec and implementations can lead to incorrect results

not preclude a more thorough solution in the future, but it > addresses the common case quickly. > > For existing data files we could check the writer version ignore filters on > float/double. I don't know whether min/max filtering is common on > float/double, but I suspect it&#

Re: Inconsistent float/double sort order in spec and implementations can lead to incorrect results

orough solution in the future, but it > > addresses the common case quickly. > > > > For existing data files we could check the writer version ignore filters > on > > float/double. I don't know whether min/max filtering is common on > > float/double, but I susp

Re: Inconsistent float/double sort order in spec and implementations can lead to incorrect results

ed that. We set it per column, so all other types could keep > TypeDefinedOrder and floats could have something like NanAwareDoubleOrder. > > On Fri, Feb 16, 2018 at 9:18 AM, Tim Armstrong > wrote: > > > We wouldn't need to rev the whole TypeDefinedOrder thing right? Could

Re: Inconsistent float/double sort order in spec and implementations can lead to incorrect results

We could drop NaNs and require that -0 be normalised to +0 when writing out stats. That would remove any degrees of freedom from the writer and then straightforward comparison with =, <, >, >=, <=, != would work as expected. On Mon, Feb 19, 2018 at 8:04 AM, Zoltan Ivanfi wrote: > Hi, > > Tim, I

Re: Setting up ASF Git Bot?

What happened to git bot? I noticed that it stopped posting on JIRAs. E.g. I had to copy and paste the commit message manually on this one: https://issues.apache.org/jira/browse/IMPALA-6497 On Thu, Feb 1, 2018 at 10:17 AM, Philip Zeyliger wrote: > I filed https://issues.apache.org/jira/browse/IN

Re: Setting up ASF Git Bot?

again? > > Thanks! > > -- Philip > > > > On Wed, Feb 21, 2018 at 9:52 AM, Tim Armstrong > wrote: > > > What happened to git bot? I noticed that it stopped posting on JIRAs. > E.g. > > I had to copy and paste the commit message manually on this one: &g

Re: minicluster with SSL

If you figured this out, it would be helpful to add it to the developer wiki: https://cwiki.apache.org/confluence/display/IMPALA/Impala+Home . I gave you permissions to edit pages on it. On Wed, Feb 21, 2018 at 6:36 PM, Vincent Tran wrote: > Please disregard. It turns out that both of the flags

Working on cherry-picks to 2.x

Just an FYI, there were some merge conflicts causing a logjam with the cherry-pick job. Alex fixed the first set, now i'm working on cherry-picking the remaining patches.

Re: test_semi_joins_exhaustive error?

Looks like https://issues.apache.org/jira/browse/IMPALA-4857 . If there are rows with duplicate keys on the right side of a hash join, we have to be able to fit all rows for a key in memory to process it. I think we could avoid the problem by modifying the test so that it's joining on a column wit

Please hold off on merging changes that don't fix builds

I'm triaging a bunch of builds now that have broken with the influx of large changes this week. I'll continue to file JIRAs for issues are breaking builds, but for now let's avoid merging anything that might make the situation worse. I'll send out an email once things are healthier. - Tim

Re: Please hold off on merging changes that don't fix builds

, but please hold off on any large commits for now until builds are reliably green. On Fri, Feb 23, 2018 at 3:25 PM, Tim Armstrong wrote: > I'm triaging a bunch of builds now that have broken with the influx of > large changes this week. > > I'll continue to file JIRAs for

impala-4835 gerrit branch

You might see some gerrit notifications about commits to this branch. I created this temporary branch to make it easier to incrementally review fixes to my original IMPALA-4835 patches. I won't merge the changes to master without consultation with others. - Tim

Re: questions about resource management of impala

Hi, It's extremely common to run YARN and Impala on the same cluster. Currently we recommend setting up the cluster to divide CPU and memory resources between YARN and Impala statically. The idea is to set Impala's and YARN's memory limits to share the available memory, and then optionally to use

Re: Re: Re: ORC scanner - points for discussion

f pre-existing issues as a result of the testing done on this patch: https://issues.apache.org/jira/issues/?jql=project%20%3D%20ORC%20AND%20reporter%20in%20(stiga-huang) On Mon, Feb 12, 2018 at 1:52 PM, Tim Armstrong wrote: > Maybe it would make sense to create an Epic in JIRA for ORC

Re: Re: [DISCUSS] Apache Impala 2.12.0 and 3.0 releases

I don't think we should hold the release for the ORC scanner patch - it's a great feature, but there are many other equally important features and improvements that have been waiting for months to be released. Generally, there are always going to be big changes that are "nearly there" and I think

Re: Re: Re: [DISCUSS] Apache Impala 2.12.0 and 3.0 releases

o minimum waiting period between releases, we could cut > >those right after that patch lands if we like. > > > >On Mon, Apr 2, 2018 at 4:05 PM, Tim Armstrong > >wrote: > > > >> I don't think we should hold the release for the ORC scanner patch - > it&

Re: Debug page not loading

HDFS, Hive, etc need to be started before running start-impala-cluster.py. You can do that directly by running ./testdata/bin/run-all.sh, but it is started automatically by buildall.sh in a lot of cases, e.g. if you run ". /buildall.sh -noclean -testdata" like described here: https://cwiki.apache.o

Re: Maintenance for jenkins.impala.io today

Is it possible that the upgrade broke some of our builds? I'm seeing some weird errors like the below, e.g. on this build https://jenkins.impala.io/job/clang-tidy-ub1604/1327/consoleFull *17:38:46* FATAL: java.lang.RuntimeException: Failed to serialize hudson.model.Actionable#actions for class hu

Re: Help with task: Allow fully qualified table names to start with a number

Here are a few JIRAs that might be good starters: https://issues.apache.org/jira/browse/IMPALA-6844 (bug in builtin function) https://issues.apache.org/jira/browse/IMPALA-6393 (adding a small improvement to impala-shell) https://issues.apache.org/jira/browse/IMPALA-6234 (fixing a bug in query analy

Re: Help with task: Allow fully qualified table names to start with a number

Why is it incompatible? On Fri, Apr 13, 2018 at 9:05 AM, Alexander Behm wrote: > IMPALA-452 is not a good candidate because it's an incompatible change, > > On Fri, Apr 13, 2018 at 9:00 AM, Tim Armstrong > wrote: > > > Here are a few JIRAs that might b

Re: Help with task: Allow fully qualified table names to start with a number

. > > Determining the variant later during compilation requires deeper changes. > > On Fri, Apr 13, 2018 at 9:55 AM, Tim Armstrong > wrote: > > > Why is it incompatible? > > > > > > On Fri, Apr 13, 2018 at 9:05 AM, Alexander Behm > > wrote: > &

JIRA necromancy

I noticed that there's been a trend recently towards reopening old issues instead of filing new issues. Not trying to pick on anyone but it seems like its worth having a discussion about best practices. Personally I think reopening JIRAs is often a bad thing for a several reasons: * We don't tend

Re: JIRA necromancy

: > I agree, a JIRA shouldn't be reopened unless it's high confidence that the > original root cause wasn't actually addressed. > > On Tue, Apr 17, 2018 at 10:29 AM, Tim Armstrong > wrote: > > > I noticed that there's been a trend recently towards re

Re: Reminder to merge commits to the ASF repo

One tip is that the ASF JIRA bot doesn't post on JIRAs until the commits are pushed to ASF. So if you're resolving a JIRA and you don't see comments from the JIRA bot, you probably have forgotten to push your commits. - Tim On Mon, Apr 23, 2018 at 10:49 AM, Henry Robinson wrote: > (-private, +d

Re: 2.x branch divergence, its implications and what you can do.

It would be good to encourage people to proactively do cherry-picks but I think it needs a bit more thought before automating it or adding more barriers. That could potentially cause hold-ups if there's a dependency on a previous patch. E.g. if I'm merging two patches B and C that depend on each o

Re: 2.x branch divergence, its implications and what you can do.

Maybe we should just start with posting back a warning to the code review if the change doesn't cleanly apply? On Thu, May 3, 2018 at 12:34 PM, Tim Armstrong wrote: > It would be good to encourage people to proactively do cherry-picks but I > think it needs a bit more thought before

New committer - Zoltán Borók-Nagy

The Project Management Committee (PMC) for Apache Impala has invited Zoltán Borók-Nagy to become a committer and we are pleased to announce that they have accepted. Congratulations and welcome, Zoltán!

Re: [ANNOUNCE] Apache Impala 3.0.0 release

Thanks Sailesh! On Wed, May 9, 2018 at 10:09 PM, Jim Apple wrote: > Thanks to Sailesh for managing the release, and thanks to the many, many > others who contributed to creating this new branch and maintaining the > relationship between the two branches. > > On Wed, May 9, 2018 at 1:37 PM, Saile

Build error with sqlparse-0.1.14

Just an FYI, since everyone else is probably going to run into this. The sqlparse version change breaks buildall.sh if you run it on a non-clean tree. Creating an egg for /home/tarmstrong/Impala/incubator-impala/shell/ext-py/sqlparse-0.1.14 python: can't open file 'setup.py': [Errno 2] No such fil

Re: New message on your code reviews when cherry-picking your change fails.

Thanks for setting this up, this should make things a lot easier. On Fri, May 11, 2018 at 12:02 PM, Philip Zeyliger wrote: > Hey folks, > > I just updated https://jenkins.impala.io/job/cherrypick-2.x-and-test/ to > comment on a code review the first time a change causes the cherry-picking > job

Re: jenkins.impala.io's ubuntu-16.04-from-scratch will now have Junit test results

I think it's trying to interpret our docs as test results: https://jenkins.impala.io/job/ubuntu-16.04-from-scratch/2186/#showFailuresLink - - Test Result (250 failures

New committers - Gabor Kaszab and Attila Jeges

The Project Management Committee (PMC) for Apache Impala has invited Attila and Gabor to become committers and we are pleased to announce that they have accepted. Congratulations and welcome!

Re: New Committer: Csaba Ringhofer

Congratulations Csaba! On Tue, May 29, 2018 at 9:03 AM, Lars Volker wrote: > The Project Management Committee (PMC) for Apache Impala has invited > Csaba Ringhofer to become a committer and we are pleased to announce that > he has accepted. > > Congratulations and welcome, Csaba! >

Jenkins upgrade

I'll be upgrading Jenkins today in response to a security advisory. There was only one job running and I've talked to mikeb about it already. I'll reply to this thread once it's back up.

Re: Jenkins upgrade

And we're back up and running. Let me know if you see any issues. On Mon, Jun 4, 2018 at 10:21 AM, Tim Armstrong wrote: > I'll be upgrading Jenkins today in response to a security advisory. There > was only one job running and I've talked to mikeb about it already. I'

Re: Broken/Flaky Tests

Things are starting to look healthier now. I went through the broken-build JIRAs and downgraded some of the infrequent infrastructure issues to critical so we have a clearer idea of what's actually breaking the build now versus what's an occasional infra issue: https://issues.apache.org/jira/issue

Re: Broken/Flaky Tests

in mind, let me know and I can considering whether to merge them. On Tue, Jun 5, 2018 at 10:11 AM, Tim Armstrong wrote: > Things are starting to look healthier now. > > I went through the broken-build JIRAs and downgraded some of the > infrequent infrastructure issues to critical s

Re: UDA debugging, was Re: Broken/Flaky Tests

Ok, so 2/3 of those fixes are merged and the other is being merged. > > > > We still have a long list of flaky issues but I went through and we've > > either mitigated them or we're blocked on being able to repro them. > > > > I'll see how things look tomor

Re: Broken/Flaky Tests

We ran into some test issues cherry-picking the latest set of changes to 2.x. I pushed out a fix and I'm merging now. Once that is done the main build fixes should be on both 2.x and master. On Tue, Jun 5, 2018 at 6:08 PM, Tim Armstrong wrote: > Ok, so 2/3 of those fixes are merged

Re: Broken/Flaky Tests

sure that it won't break any other configurations (S3, Local, etc). On Wed, Jun 6, 2018 at 2:44 PM, Tim Armstrong wrote: > We ran into some test issues cherry-picking the latest set of changes to > 2.x. I pushed out a fix and I'm merging now. Once that is done the main > build f

Automatically rebase changes before GVO?

One annoyance with our precommit job is the requirement to manually rebase the change before starting the merge. Failure to do so either leads to false positives or false negatives - builds that failed because they were missing a flaky/broken test fix and builds that succeeded despite interacting b

Re: Automatically rebase changes before GVO?

ote: > > > Seems fine, especially since we do the rebase as our submission strategy > > anyway, so we're already accepting/testing something that's likely to get > > rebased, and we may as well minimize that window. > > > > I'd be in favor of the bot

Re: Automatically rebase changes before GVO?

I've tried my job a few times and it's working as expected. Any objections to me switching over gerrit-verify-dryrun to my approach? On Thu, Jun 7, 2018 at 2:42 PM, Tim Armstrong wrote: > Ok, I was able to put together a test job that does the automatic rebase > and carries

Re: Automatically rebase changes before GVO?

l rebase step that people have to remember to do. On Mon, Jun 11, 2018 at 12:04 PM, Tim Armstrong wrote: > I've tried my job a few times and it's working as expected. Any objections > to me switching over gerrit-verify-dryrun to my approach? > > On Thu, Jun 7, 2018 at 2:4

Re: Automatically rebase changes before GVO?

me. > > On Mon, Jun 11, 2018 at 12:06 PM, Tim Armstrong > wrote: > > > > On nit: as GVD gets more complex, it becomes harder for new people to > > understand the messages and +Ns applied to their patches. That doesn't > mean > > we shouldn't do this, only

Re: Automatically rebase changes before GVO?

Ok, I applied the changes. Let me know if you run into any issues. On Mon, Jun 11, 2018 at 3:05 PM, Sailesh Mukil wrote: > +1 > > On Mon, Jun 11, 2018 at 3:02 PM, Jim Apple wrote: > > > No objection from me. > > > > On Mon, Jun 11, 2018 at 12:06 PM, Tim Armstron

Re: Automatically rebase changes before GVO?

pala.io/job/gerrit-verify-dryrun/jobConfigHistory/ > showDiffFiles?timestamp1=2018-06-11_22-09-04×tamp2= > 2018-06-12_02-47-10 > > On Mon, Jun 11, 2018 at 3:09 PM, Tim Armstrong > wrote: > > > Ok, I applied the changes. Let me know if you run into any issues. > > > &

Re: Broken/Flaky Tests

253E%253D%252B2 On Thu, Jun 7, 2018 at 10:28 AM, Tim Armstrong wrote: > All of the major known issues except an S3 infra issue are fixed. We got > broken in a minor way by a Hive change: https://issues.apache.org/ > jira/browse/IMPALA-7143 so I disabled the tests until we can sort t

Re: Configuring Impala to exit on OutOfMemoryError

It definitely seems like it would result in more predictable behaviour. I think the other reasonable alternative is that we actually test the behaviour of the system when it gets into an OOM state and make sure that it can recover (which might not be possible with a reasonable amount of effort). O

Re: Broken/Flaky Tests

I'm concerned that for the last couple of days we've been finding new issues faster than we're fixing them. I'll start pushing back on some higher-risk changes (e.g. in race-prone parts of the code) until we've cleared up some of the issues. On Tue, Jun 12, 2018 at 1:31

Apache jira-bot stopped working

Just FYI, it decided to take a day off, in case you were waiting for a comment on your JIRA: https://issues.apache.org/jira/browse/INFRA-16651 Hopefully it's back up now.

Re: Branch 2.x

Thanks Phil, I think it will be good not to have to maintain this. On Mon, Jun 18, 2018 at 9:40 AM, Philip Zeyliger < phi...@cloudera.com.invalid> wrote: > I've not heard anything, so I've removed the "trigger" for job > https://jenkins.impala.io/job/cherrypick-2.x-and-test/. It used to "Poll > S

Re: Branch 2.x

This just came up - do we want to backport bug or test fixes to 2.x or nothing at all? https://gerrit.cloudera.org/#/c/10722/ On Mon, Jun 18, 2018 at 10:48 AM, Tim Armstrong wrote: > Thanks Phil, I think it will be good not to have to maintain this. > > On Mon, Jun 18, 2018 at 9:40 A

Future of unsupported formats?

For a few years now we've had write support for Sequence, Avro and compressed text hidden behind a query option. We haven't really made any progress on turning it into a supported feature, so I'm wondering if we should remove the code and save some overhead of building, testing and code maintenance

Re: Future of unsupported formats?

be worth taking a survey wider than dev@. User@ or the customers > of Impala packagers might be good places to start. > > On Mon, Jun 18, 2018 at 5:10 PM Tim Armstrong > wrote: > > > For a few years now we've had write support for Sequence, Avro and > > compressed

Re: Future of unsupported formats?

other > > communication channels they might have access to. > > > > Cheers, Lars > > > > On Tue, Jun 19, 2018 at 8:26 AM Tim Armstrong > > wrote: > > > > > I don't think we need to bump a major version to remove somethin

Re: Future of unsupported formats?

Lars, Even if people were using it, would that affect our decision if there's noone to maintain it? I don't think we were ambiguous about whether writing those formats was supported or not. On Tue, Jun 19, 2018 at 10:04 AM, Tim Armstrong wrote: > Hi Edward, > I was tal

Re: Future of unsupported formats?

sage: > > It seems like we should get it out of this in-between state - either delete > > the code or get it to the point where it's supported and tested. If we > > delete it, it's always possible for someone to resurrect it later. > > > Cheers, Lars > > &

Re: Re: Future of unsupported formats?

your work on fixing the recent > broken/flaky tests. > > > > Thanks for your hard working on this wonderful product! > > > > > > -- Quanlong > > > > > > At 2018-06-20 04:12:38, "Jim Apple" > wrote: > > >I'm convince

Need reviewer for SHUTDOWN patch

Does anyone have time to review this patch? It's a pretty big step towards being able to shrink an Impala cluster without disrupting workloads. https://gerrit.cloudera.org/#/c/10744/

Re: Broken/Flaky Tests

althy aside from IMPALA-6910 <https://issues.apache.org/jira/browse/IMPALA-6910> so we can continue merging as normal, but let's not get complacent. On Thu, Jun 14, 2018 at 3:35 PM, Tim Armstrong wrote: > I'm concerned that for the last couple of days we've been finding n

boost::scoped_ptr vs std::unique_ptr

I was just talking with Michael Ho on a review about this https://gerrit.cloudera.org/#/c/10810/7/be/src/exec/scan-node.h@271 For a while we've continued using scoped_ptr in some places because it supports a smaller set of operators and implies that the pointer isn't movable. See https://cwiki.apa

  1   2   3   >