Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Received-SPF: pass (athena.apache.org: domain of jhurley@hortonworks.com
 designates 64.78.56.46 as permitted sender)
Subject: Re: Server unit tests take too long (30+ minutes)
MIME-Version: 1.0
From: Jonathan Hurley <jhurley@hortonworks.com>
To: "dev@ambari.apache.org" <dev@ambari.apache.org>
CC: Jayush Luniya <jluniya@hortonworks.com>
Thread-Topic: Server unit tests take too long (30+ minutes)
Thread-Index: AQHQY1fFHLHNZAPVQkCdmA0IxyVhcp0sdouA
Date: Tue, 24 Mar 2015 18:54:23 +0000
Message-ID: <C9D6F006-3202-48C8-881D-274A50C7B97B@hortonworks.com>
References: <1427221989273.42619@hortonworks.com>
In-Reply-To: <1427221989273.42619@hortonworks.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <D45F46D7A24F2B4E9AB23FABD7FA2E39@exch080.serverpod.net>
Content-Transfer-Encoding: quoted-printable

Many of these, such as the deadlock tests and alert tests are just going to=
 take a long time due to the nature of what they=92re doing. In general, if=
 b.a.o is timing out, we need to either increase the timeout for the job or=
 change our pom.xml to allow for forked execution of the tests.

In my local environment, 3 concurrent forks can run through the test suite =
in about 20 minutes. The problem is that both LDAP tests below always fail =
in a forked environment. I=92d say if we want to get the build times down, =
we should look into making the 2 LDAP tests work with forked test runners i=
n the pom.xml

> On Mar 24, 2015, at 2:33 PM, Sumit Mohanty <smohanty@hortonworks.com> wro=
te:
>=20
> ?Hi,
>=20
>=20
> these are some of the unit tests that take too long (more than 30 seconds=
 on my machine).  There are several that are above 10 seconds but below 30 =
seconds range that can also use some optimization.
>=20
>=20
> Jayush tells me that the Apache builds may be getting aborted as the buil=
d + UT run takes more than an hour.
>=20
>=20
> I will look into some of it when I get a chance. If there are any that pi=
ques your curiosity then take a look.
>=20
>=20
> Running org.apache.ambari.server.agent.TestHeartbeatHandler
> Tests run: 34, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 67.43 se=
c
>=20
> Running org.apache.ambari.server.state.cluster.ClusterTest
> Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 55.576 s=
ec
>=20
> Running org.apache.ambari.server.state.cluster.ClusterDeadlockTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 52.252 se=
c
>=20
> Running org.apache.ambari.server.upgrade.UpgradeTest
> Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 50.433 se=
c
>=20
> Running org.apache.ambari.server.orm.dao.AlertDispatchDAOTest
> Tests run: 25, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 46.681 s=
ec
>=20
> Running org.apache.ambari.server.orm.dao.AlertsDAOTest
> Tests run: 22, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 44.474 s=
ec
>=20
> Running org.apache.ambari.server.security.authorization.TestUsers
> Tests run: 26, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 36.421 s=
ec
>=20
> Running org.apache.ambari.server.security.authorization.AmbariLdapAuthent=
icationProviderTest
> Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.46 sec
>=20
> Running org.apache.ambari.server.security.authorization.AmbariLdapAuthent=
icationProviderForDNWithSpaceTest
> Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 35.706 se=
c
>=20
> Running org.apache.ambari.server.state.ConfigHelperTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.863 s=
ec
>=20
> Running org.apache.ambari.server.controller.internal.StackDefinedProperty=
ProviderTest
> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.247 s=
ec
>=20
> ...
>=20
> thanks
> ?-Sumit
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20