hadoop-mapreduce-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Nauroth <cnaur...@hortonworks.com>
Subject Re: Policy on adding timeouts to tests
Date Tue, 15 Apr 2014 18:37:34 GMT
+common-dev, hdfs-dev

My understanding of the current situation is that we had a period where we
tried to enforce adding timeouts on all new tests in patches, but it caused
trouble, and now we're back to not requiring it.  Jenkins test-patch isn't
checking for it anymore.

I don't think patches are getting rejected for using timeouts though.

The difficulty is that execution time is quite sensitive to the build
environment.  (Consider top-of-the-line server hardware used in build
infrastructure vs. a dev running a VirtualBox VM with 1 dedicated CPU, 2 GB
RAM and slow virtualized disk.)  When we were enforcing timeouts, it was
quite common to see follow-up patches tuning up the timeout settings to
make tests work reliably in a greater variety of environments.  At that
point, the benefit of using the timeout becomes questionable, because now
the fast machine is running with the longer timeout too.

Chris Nauroth

On Mon, Apr 14, 2014 at 9:41 AM, Karthik Kambatla <kasha@cloudera.com>wrote:

> Hi folks
> Just wanted to check what our policy for adding timeouts to tests is. Do we
> encourage/discourage using timeouts for tests? If we discourage using
> timeouts for tests in general, are we okay with adding timeouts for a few
> tests where we explicitly want the test to fail if it takes longer than a
> particular amount of time?
> Thanks
> Karthik

NOTICE: This message is intended for the use of the individual or entity to 
which it is addressed and may contain information that is confidential, 
privileged and exempt from disclosure under applicable law. If the reader 
of this message is not the intended recipient, you are hereby notified that 
any printing, copying, dissemination, distribution, disclosure or 
forwarding of this communication is strictly prohibited. If you have 
received this communication in error, please contact the sender immediately 
and delete it from your system. Thank You.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message