db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Myrna van Lunteren <m.v.lunte...@gmail.com>
Subject Re: [URGENT] Critical test situation on trunk
Date Tue, 07 Feb 2012 13:33:27 GMT
On Tue, Feb 7, 2012 at 3:08 AM, Knut Anders Hatlen
<knut.hatlen@oracle.com> wrote:
> Rick Hillegas <rick.hillegas@oracle.com> writes:
>> Thanks, Kathey. I will re-enable NativeAuthenticationServiceTest for
>> non-windows platforms with my next checkin for DERBY-866. I hope to do
>> that tomorrow after running a full test cycle on my machine tonight.
> One observation: When NativeAuthenticationServiceTest was disabled on
> all platforms, the Oracle tests started working again on non-Windows
> platforms. Might be coincidental, but it might also mean that the test
> is (still) causing problems on *nix.
> (The Windows machines didn't produce any test results even after the
> disabling of NativeAuthenticationServiceTest, but it looked like that
> was because of some old test processes still hanging. I think I've
> cleaned up those machines now, so Windows results may show up in the
> next test cycle.)
> The Tinderbox has been running successfully all the time, though (on a
> Solaris machine). Not sure why it has been successful while the nightly
> tests on the same platform choked.
> --
> Knut Anders


I have done various experiments to narrow down the problem situation.
I did not look at the error failure in depth, thinking it's a
environment problem...

I've been looking for the error and failure in SecureServerTest,
assuming it's at the root of the problem, and because this test gets
run pretty early in the suites.All.

So far, I have the following details:
 - the problem only happens with cygwin (1.7). We used to  have an old
version of mks shell environment on this machine and SecureServerTest
does not fail with that.
- however, on other machines, using the same cygwin version, there is
no problem.
- the problem does not reproduce when running SecureServerTest by
itself, or when running tests.derbynet._Suite.

The machine where I did see the problem is a 2 CPU (with
hyperthreading on) whereas most of the other machines I have available
are 1 CPU.

I will do further experiments:
- run with an older version of derby, using cygwin, on the machine
where we see the problem
- use a modified test environment such that the only test run by
suites.All is SecureServerTest
- attempt to get a (more clear) error/failure stack trace out of
- have the hardware people switch off hyperthreading (this could take
some time as I'm dependent on others for it)

I'll report back as things progress.


View raw message