TestNegativeCliDriver failures are concerning. We are practically having no
negative test coverage since a last couple of weeks. I think we should
treat it as a blocker for Hive 3.0.0 release. Thoughts?
On Thu, Apr 5, 2018 at 9:50 PM, Prasanth Jayachandran <
pjayachand...@hortonworks.com> wrote:
It may be because of legitimate memory issue/leak. Alternative is to decrease
the batch size of negative cli driver on ptest cluster but again we wouldn't
know if there is any actual memory issue.
Thanks
Prasanth
On Thu, Apr 5, 2018 at 1:36 PM -0700, "Vineet Garg"
TestNegativeCli driver tests are still failing with java.lang.OutOfMemoryError:
GC overhead limit exceeded error.
Can we increase the amount of memory for tests?
Vineet
On Mar 5, 2018, at 11:35 AM, Sergey Shelukhin
> wrote:
On a
On a semi-related note, I noticed recently that negative tests seem to OOM
in setup from time to time.
Can we increase the amount of memory for the tests a little bit, and/or
maybe add the dump on OOM to them, saved to test logs directory, so we
could investigate?
On 18/3/5, 11:07, "Vineet Garg"
+1 for nightly build. We could generate reports to identify both frequent and
sporadic test failures plus other interesting bits like average build time,
yetus failures etc. It’ll also help narrow down the culprit commit(s) range to
one day.
If you guys decide to go ahead with this I would like
Wow that HBase UI looks super useful. +1 to having something like that.
If not, +1 to having a proper nightly build, it would help devs identify
which commits break which tests. I find using git-bisect can take a long
time to run, and can be difficult to use (e.g. finding a known good commit
Without a nightly build and with this many flaky tests it is very hard to
identify the braking commits. We can use something like bisect and multiple
test runs.
There is a more elegant way to do this with nightly test runs:
https://issues.apache.org/jira/browse/HBASE-15917
+1
Does anyone have suggestions about how to efficiently identify which commit
is breaking a test? Is it just git-bisect or is there an easier way? Hive
QA isn't always that helpful, it will say a test is failing for the past
"x" builds, but that doesn't help much since Hive QA isn't a nightly
+1
Commenting on JIRA and giving a 24hr heads-up (excluding weekends) would be
good.
On Thu, Feb 22, 2018 at 10:19 AM, Alan Gates wrote:
> +1.
>
> Alan.
>
> On Thu, Feb 22, 2018 at 8:25 AM, Thejas Nair
> wrote:
>
> > +1
> > I agree, this makes
+1.
Alan.
On Thu, Feb 22, 2018 at 8:25 AM, Thejas Nair wrote:
> +1
> I agree, this makes sense. The number of failures keeps increasing.
> A 24 hour heads up in either case before revert would be good.
>
>
> On Thu, Feb 22, 2018 at 2:45 AM, Peter Vary
+1
I agree, this makes sense. The number of failures keeps increasing.
A 24 hour heads up in either case before revert would be good.
On Thu, Feb 22, 2018 at 2:45 AM, Peter Vary wrote:
> I agree with Zoltan. The continuously braking tests make it very hard to
> spot real
I agree with Zoltan. The continuously braking tests make it very hard to spot
real issues.
Any thoughts on doing it automatically?
> On Feb 22, 2018, at 10:47 AM, Zoltan Haindrich wrote:
>
> *
>
> Hello,
>
> *
> *
>
> **
>
> In the last couple weeks the number of broken tests
*
Hello,
*
*
**
In the last couple weeks the number of broken tests have started to go
up...and even tho I run bisect/etc from time to time ; sometimes people
don’t react to my comments/tickets/etc.
Because keeping this many failing tests makes it easier for a new one to
slip in...I
13 matches
Mail list logo