You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Katherine Marsden <km...@sbcglobal.net> on 2012/02/03 21:30:02 UTC
[URGENT] Critical test situation on trunk
Right now the IBM Tests are not running due to a hang from in
NativeAuthenticationServiceTest DERBY-5601
http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1239981.html
Oracle tests seem to be broken:
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1239719.html
I am not sure if Oracle has the same issue or something else.
As far as I know these are our only sources of regression tests so I
think we better close down trunk except for efforts to get the runs
going again. Unfortunately for DERBY-5601 I cannot reproduce at least
with the single test on my machine.Unfortunately also I am about to head
out of town for the weekend.
Rick, would you be willing to disable NativeAuthenticationServiceTest
for the short term to see if that at least gets the IBM runs going again?
Can someone look to see what is happening with the Oracle runs?
Can everyone please refrain from other trunk checkins until we get
things stabilized?
Thanks
Kathey
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/7/2012 12:18 PM, Kristian Waagan wrote:
>
>
FYI: Myrna switched the run temporarily over to a slower machine
without the problem. It is running just IBM 1.6 and weme 6.2 and so now
we have something minimal on Windows while she debugs the other machine
problem.
http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1241338.html
Yay! Thanks Myrna
Re: [URGENT] Critical test situation on trunk
Posted by Kristian Waagan <kr...@oracle.com>.
On 07.02.2012 17:18, Katherine Marsden wrote:
> On 2/7/2012 2:55 AM, Kristian Waagan wrote:
>>>
>>> (net)derbynet.SecureServerTest.testServerStartup used 6750 ms E.
>>> (net)derbynet.SecureServerTest.testServerStartup used 46827 ms F.
>>
>>
>> Is the stack trace ([1]) for the first SecureServerStartup, or for the
>> second one?
>> If from the second one, what's the error for the first?
>> And, do you know where the interrupt comes from?
>> Did you manually kill/interrupt the test run, or did it die on its own?
> think it is from the first one:
> Full output is at:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/1240879-suites.All_diff.txt
>> And, do you know where the interrupt comes from?
> It seems related somehow to launching a process with cygwin on that
> particuar machine.
>
>> Did you manually kill/interrupt the test run, or did it die on its own?
>
> Once NativeAuthenticationServiceTest was disabled the tests ran through
> to completion but with 75-77 failures and 817 errors as you can see from
> the above run.
Thanks, Kathey.
If you're interested, you can try to apply the attached patch ([1]) and
see if the logs contain any useful information.
The patch catches the interrupt and tries to collect any output on the
subprocess' stdout and stderr before killing the process. Depending on
what's going on, there may be nothing there.
I've only tested the patch with SecureServerTest.
--
Kristian
[1] It's a git patch, use -p1 with patch when applying.
>
>
>>
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/7/2012 2:55 AM, Kristian Waagan wrote:
>>
>> (net)derbynet.SecureServerTest.testServerStartup used 6750 ms E.
>> (net)derbynet.SecureServerTest.testServerStartup used 46827 ms F.
>
>
> Is the stack trace ([1]) for the first SecureServerStartup, or for the
> second one?
> If from the second one, what's the error for the first?
> And, do you know where the interrupt comes from?
> Did you manually kill/interrupt the test run, or did it die on its own?
think it is from the first one:
Full output is at:
http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/1240879-suites.All_diff.txt
> And, do you know where the interrupt comes from?
It seems related somehow to launching a process with cygwin on that
particuar machine.
> Did you manually kill/interrupt the test run, or did it die on its own?
Once NativeAuthenticationServiceTest was disabled the tests ran through
to completion but with 75-77 failures and 817 errors as you can see
from the above run.
>
Re: [URGENT] Critical test situation on trunk
Posted by Kristian Waagan <kr...@oracle.com>.
On 06.02.2012 19:52, Katherine Marsden wrote:
> On 2/6/2012 5:52 AM, Rick Hillegas wrote:
>> I am looking into the best way to get a window installation where I
>> can debug this. Stand by...
>>
> Thanks Rick,
>
> Talking with Myrna, Mike and Mamta and looking back at the onset of
> the NativeAuthenticationTest hang. I see that even at that time we
> had the prior SecureServerTest failure
>
> (net)derbynet.SecureServerTest.testServerStartup used 6750 ms E.
> (net)derbynet.SecureServerTest.testServerStartup used 46827 ms F.
Is the stack trace ([1]) for the first SecureServerStartup, or for the
second one?
If from the second one, what's the error for the first?
And, do you know where the interrupt comes from?
Did you manually kill/interrupt the test run, or did it die on its own?
Regads,
--
Kristian
> Which we found later to have the stack Trace below [1] and which
> seemed to send things going down hill and let up to the hagn.
> Myrna also told me at the the time this all started, she just
> switched over to cygwin from another shell program.
>
> I have done suites.All runs sane and insane on my Windows machine as
> have Mike and Mamta and runs are clean, so I think it would be good to
> reenable NativeAuthenticationServiceTest on non-windows platforms and
> even on windows for non-ibm jvm's.
> Myrna is working on figuring out why the cygwin upgrade caused such
> trouble on this machine. I will do this tomorrow unless someone else
> beats me to it.
>
>
> Thanks
>
> Kathey
>
> [1] SecureServerTest( Opened = false, Authenticated= false, CustomDerbyProperties= null, WildCardHost= null )java.lang.InterruptedException
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:184)
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:146)
> at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runServerCommand(SecureServerTest.java:481)
> at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runsysinfo(SecureServerTest.java:411)
> at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:350)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
On 2/6/12 12:44 PM, Katherine Marsden wrote:
> On 2/6/2012 12:36 PM, Rick Hillegas wrote:
>> 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.
> Thanks Rick,
>
> Is that a fairly major change? I don't see the patch attached to the
> issue yet.
I just attached it to DERBY-866. I didn't do anything fancy. I copied
the check for windows platforms which I see in other tests. If that's
not subtle enough, we may need to adjust the check.
> Although things are looking like infrastructure for both Oracle and
> IBM runs, we still don't have public Window's runs published on trunk,
> so I think it is good still to be very conservative about what goes in.
I agree. We are flying blind on Windows right now.
Thanks,
-Rick
>
> Kathey
>
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/6/2012 12:36 PM, Rick Hillegas wrote:
> 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.
Thanks Rick,
Is that a fairly major change? I don't see the patch attached to the
issue yet. Although things are looking like infrastructure for both
Oracle and IBM runs, we still don't have public Window's runs published
on trunk, so I think it is good still to be very conservative about what
goes in.
Kathey
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
On 2/8/12 12:44 AM, Knut Anders Hatlen wrote:
> Rick Hillegas<ri...@oracle.com> writes:
>
>> On 2/7/12 8:38 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas<ri...@oracle.com> writes:
>>>
>>>> My last checkin (1241479) re-enabled NativeAuthenticationServiceTest
>>>> on non-windows platforms. If the *nix tests fall over again tonight,
>>>> then we should disable NativeAuthenticationServiceTest again until we
>>>> understand the situation better.
>>> Hi Rick,
>>>
>>> I just gave the test a try with Java 5 on Solaris, and it seems to get
>>> stuck in the fifth configuration (consistently). No problems with Java 6
>>> or Java 7. Do you have any theories on why it behaves differently on
>>> Java 5?
>>>
>>> Thanks,
>>>
>> Hi Knut,
>>
>> Thanks for running the test on other platforms. I don't know what is
>> special about that configuration. I have instrumented the test to
>> produce a fair amount of chatty output if you set
>> -Dderby.tests.debug=true. If you set that flag and run on Java 5 on
>> Solaris, we may get some clue about the problem from looking at the
>> last statements printed to the console before the test hangs.
> I'll take a look. The latest test cycle (with the test re-enabled)
> passed on all platforms with Java 6 (including Windows). With Java 5,
> the tests only passed on Windows. No Java 5 results were reported from
> the Solaris and Linux variants.
>
> Does the test pass with Java 5 in your (OS/X) environment?
>
Can't test that. Apple doesn't want users to linger on old VMs. You
can't get Java 5 for my machine anymore. In its infinite wisdom, Apple
only put Java 6 on my old machine (when they repaired its crashed disk).
On my new machine I have Apple's official Java 6 and various versions of
the OpenJDK Java 7.
Thanks,
-Rick
Re: [URGENT] Critical test situation on trunk
Posted by Myrna van Lunteren <m....@gmail.com>.
On Wed, Feb 8, 2012 at 12:44 AM, Knut Anders Hatlen
<kn...@oracle.com> wrote:
> Rick Hillegas <ri...@oracle.com> writes:
>
>> On 2/7/12 8:38 AM, Knut Anders Hatlen wrote:
>>> Rick Hillegas<ri...@oracle.com> writes:
>>>
>>>> My last checkin (1241479) re-enabled NativeAuthenticationServiceTest
>>>> on non-windows platforms. If the *nix tests fall over again tonight,
>>>> then we should disable NativeAuthenticationServiceTest again until we
>>>> understand the situation better.
>>> Hi Rick,
>>>
>>> I just gave the test a try with Java 5 on Solaris, and it seems to get
>>> stuck in the fifth configuration (consistently). No problems with Java 6
>>> or Java 7. Do you have any theories on why it behaves differently on
>>> Java 5?
>>>
>>> Thanks,
>>>
>> Hi Knut,
>>
>> Thanks for running the test on other platforms. I don't know what is
>> special about that configuration. I have instrumented the test to
>> produce a fair amount of chatty output if you set
>> -Dderby.tests.debug=true. If you set that flag and run on Java 5 on
>> Solaris, we may get some clue about the problem from looking at the
>> last statements printed to the console before the test hangs.
>
> I'll take a look. The latest test cycle (with the test re-enabled)
> passed on all platforms with Java 6 (including Windows). With Java 5,
> the tests only passed on Windows. No Java 5 results were reported from
> the Solaris and Linux variants.
>
> Does the test pass with Java 5 in your (OS/X) environment?
>
> --
> Knut Anders
Hi,
I just put some comments in DERBY-5601, regarding the run I did with
Kristian's patch...
In our environment, on the machine where we see the SecureServerTest
failure, the behavior appears the same with ibm 1.5, 1.6, or 1.7.
Myrna
Re: [URGENT] Critical test situation on trunk
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> On 2/7/12 8:38 AM, Knut Anders Hatlen wrote:
>> Rick Hillegas<ri...@oracle.com> writes:
>>
>>> My last checkin (1241479) re-enabled NativeAuthenticationServiceTest
>>> on non-windows platforms. If the *nix tests fall over again tonight,
>>> then we should disable NativeAuthenticationServiceTest again until we
>>> understand the situation better.
>> Hi Rick,
>>
>> I just gave the test a try with Java 5 on Solaris, and it seems to get
>> stuck in the fifth configuration (consistently). No problems with Java 6
>> or Java 7. Do you have any theories on why it behaves differently on
>> Java 5?
>>
>> Thanks,
>>
> Hi Knut,
>
> Thanks for running the test on other platforms. I don't know what is
> special about that configuration. I have instrumented the test to
> produce a fair amount of chatty output if you set
> -Dderby.tests.debug=true. If you set that flag and run on Java 5 on
> Solaris, we may get some clue about the problem from looking at the
> last statements printed to the console before the test hangs.
I'll take a look. The latest test cycle (with the test re-enabled)
passed on all platforms with Java 6 (including Windows). With Java 5,
the tests only passed on Windows. No Java 5 results were reported from
the Solaris and Linux variants.
Does the test pass with Java 5 in your (OS/X) environment?
--
Knut Anders
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
On 2/8/12 6:27 AM, Katherine Marsden wrote:
> On 2/8/2012 2:15 AM, Kristian Waagan wrote:
>> On 08.02.2012 11:01, Knut Anders Hatlen wrote:
>> <snip>
>>
>>> This deadlock does not happen in Java 6 because the getConnection()
>>> method is no longer synchronized, and the synchronized section in
>>> getDriver() has been narrowed down (and in Java 7 it's completely
>>> removed).
>>
>> We had the same problem in the replication test code at some point. I
>> can't remember what was done to fix it, maybe the code was
>> restructured to avoid the problem altogether.
>>
>>
> We had this problem in Network Server initially if client was in the
> same jvm. The solution was to avoid using Driver Manager in
> internally all together and let the user have the DriverManagerLock.
> In NetworkServerControlImpl we have:
> // start the server.
> cloudscapeDriver = (Driver)
> Class.forName(CLOUDSCAPE_DRIVER).newInstance();
>
> and then use that Driver for getting connections.
>
>
>
Thanks Kathey, Knut, and Kristian. The discussion and experiments were
very helpful. I can reproduce this hang on Linux on Java 5 using the
short test case attached to newly filed DERBY-5607.
Thanks,
-Rick
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/8/2012 2:15 AM, Kristian Waagan wrote:
> On 08.02.2012 11:01, Knut Anders Hatlen wrote:
> <snip>
>
>> This deadlock does not happen in Java 6 because the getConnection()
>> method is no longer synchronized, and the synchronized section in
>> getDriver() has been narrowed down (and in Java 7 it's completely
>> removed).
>
> We had the same problem in the replication test code at some point. I
> can't remember what was done to fix it, maybe the code was
> restructured to avoid the problem altogether.
>
>
We had this problem in Network Server initially if client was in the
same jvm. The solution was to avoid using Driver Manager in internally
all together and let the user have the DriverManagerLock. In
NetworkServerControlImpl we have:
// start the server.
cloudscapeDriver = (Driver)
Class.forName(CLOUDSCAPE_DRIVER).newInstance();
and then use that Driver for getting connections.
Re: [URGENT] Critical test situation on trunk
Posted by Kristian Waagan <kr...@oracle.com>.
On 08.02.2012 11:01, Knut Anders Hatlen wrote:
<snip>
> This deadlock does not happen in Java 6 because the getConnection()
> method is no longer synchronized, and the synchronized section in
> getDriver() has been narrowed down (and in Java 7 it's completely
> removed).
We had the same problem in the replication test code at some point. I
can't remember what was done to fix it, maybe the code was restructured
to avoid the problem altogether.
--
Kristian
Re: [URGENT] Critical test situation on trunk
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> Thanks for running the test on other platforms. I don't know what is
> special about that configuration. I have instrumented the test to
> produce a fair amount of chatty output if you set
> -Dderby.tests.debug=true. If you set that flag and run on Java 5 on
> Solaris, we may get some clue about the problem from looking at the
> last statements printed to the console before the test hangs.
There were no differences in the output on Java 5 and Java 6 (except
time stamps) up to the hang. The last lines of debug output seen on Java
5 looked like this:
(net)lang.NativeAuthenticationServiceTest.testAll DEBUG: [ NATIVE authentication on, LOCAL authentication ON, Authentication/Authorization turned OFF, Client/Server ]
DEBUG: Credentials DB physical name = singleUse/oneuse30
DEBUG: derby.authentication.provider = NATIVE:singleUse/oneuse30:LOCAL
DEBUG: APPLE attempting to get connection to database secondDB aka singleUse/oneuse31
I took a thread dump while the test was hanging. The main thread was
stuck in a read call, waiting for data from the server:
"main" prio=3 tid=0x08074b78 nid=0x1 runnable [0x08044000..0x08046b40]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at org.apache.derby.client.net.Reply.fill(Reply.java:172)
at org.apache.derby.client.net.Reply.ensureALayerDataInBuffer(Reply.java:216)
at org.apache.derby.client.net.Reply.readDssHeader(Reply.java:318)
at org.apache.derby.client.net.Reply.startSameIdChainParse(Reply.java:1160)
at org.apache.derby.client.net.NetConnectionReply.readSecurityCheck(NetConnectionReply.java:112)
at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:825)
at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:762)
at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(NetConnection.java:591)
at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:406)
at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:220)
at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl.newNetConnection(ClientJDBCObjectFactoryImpl.java:270)
at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:157)
at java.sql.DriverManager.getConnection(DriverManager.java:525)
- locked <0x633712b8> (a java.lang.Class)
at java.sql.DriverManager.getConnection(DriverManager.java:140)
- locked <0x633712b8> (a java.lang.Class)
at org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:99)
at org.apache.derbyTesting.junit.TestConfiguration.openConnection(TestConfiguration.java:1683)
at org.apache.derbyTesting.functionTests.tests.lang.NativeAuthenticationServiceTest.openConnection(NativeAuthenticationServiceTest.java:920)
at org.apache.derbyTesting.functionTests.tests.lang.NativeAuthenticationServiceTest.getConnection(NativeAuthenticationServiceTest.java:823)
at org.apache.derbyTesting.functionTests.tests.lang.NativeAuthenticationServiceTest.vetCoreBehavior(NativeAuthenticationServiceTest.java:340)
at org.apache.derbyTesting.functionTests.tests.lang.NativeAuthenticationServiceTest.testAll(NativeAuthenticationServiceTest.java:320)
Notice the thread has locked a monitor in DriverManager.getConnection().
The server thread is blocked trying to lock the same monitor in
DriverManager.getDriver():
"DRDAConnThread_31" daemon prio=3 tid=0x08515368 nid=0x6d waiting for monitor entry [0xfa049000..0xfa049aa0]
at java.sql.DriverManager.getDriver(DriverManager.java:209)
- waiting to lock <0x633712b8> (a java.lang.Class)
at org.apache.derby.jdbc.EmbeddedDataSource.findDriver(EmbeddedDataSource.java:506)
- locked <0x430a43f0> (a org.apache.derby.jdbc.EmbeddedDataSource)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:480)
at org.apache.derby.jdbc.EmbeddedDataSource.getConnection(EmbeddedDataSource.java:424)
at org.apache.derby.impl.jdbc.authentication.NativeAuthenticationServiceImpl.authenticateRemotely(NativeAuthenticationServiceImpl.java:419)
at org.apache.derby.impl.jdbc.authentication.NativeAuthenticationServiceImpl.authenticateUser(NativeAuthenticationServiceImpl.java:310)
at org.apache.derby.impl.jdbc.authentication.AuthenticationServiceBase.authenticate(AuthenticationServiceBase.java:257)
at org.apache.derby.impl.jdbc.EmbedConnection.checkUserCredentials(EmbedConnection.java:1247)
at org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:404)
at org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
at org.apache.derby.jdbc.Driver30.getNewEmbedConnection(Driver30.java:80)
at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:255)
at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126)
at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257)
at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1473)
at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1423)
at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3274)
at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1203)
at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1008)
at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
This deadlock does not happen in Java 6 because the getConnection()
method is no longer synchronized, and the synchronized section in
getDriver() has been narrowed down (and in Java 7 it's completely
removed).
--
Knut Anders
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
On 2/7/12 8:38 AM, Knut Anders Hatlen wrote:
> Rick Hillegas<ri...@oracle.com> writes:
>
>> My last checkin (1241479) re-enabled NativeAuthenticationServiceTest
>> on non-windows platforms. If the *nix tests fall over again tonight,
>> then we should disable NativeAuthenticationServiceTest again until we
>> understand the situation better.
> Hi Rick,
>
> I just gave the test a try with Java 5 on Solaris, and it seems to get
> stuck in the fifth configuration (consistently). No problems with Java 6
> or Java 7. Do you have any theories on why it behaves differently on
> Java 5?
>
> Thanks,
>
Hi Knut,
Thanks for running the test on other platforms. I don't know what is
special about that configuration. I have instrumented the test to
produce a fair amount of chatty output if you set
-Dderby.tests.debug=true. If you set that flag and run on Java 5 on
Solaris, we may get some clue about the problem from looking at the last
statements printed to the console before the test hangs.
Thanks,
-Rick
Re: [URGENT] Critical test situation on trunk
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@oracle.com> writes:
> My last checkin (1241479) re-enabled NativeAuthenticationServiceTest
> on non-windows platforms. If the *nix tests fall over again tonight,
> then we should disable NativeAuthenticationServiceTest again until we
> understand the situation better.
Hi Rick,
I just gave the test a try with Java 5 on Solaris, and it seems to get
stuck in the fifth configuration (consistently). No problems with Java 6
or Java 7. Do you have any theories on why it behaves differently on
Java 5?
Thanks,
--
Knut Anders
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
My last checkin (1241479) re-enabled NativeAuthenticationServiceTest on
non-windows platforms. If the *nix tests fall over again tonight, then
we should disable NativeAuthenticationServiceTest again until we
understand the situation better.
Thanks,
-Rick
Re: [URGENT] Critical test situation on trunk
Posted by Myrna van Lunteren <m....@gmail.com>.
On Tue, Feb 7, 2012 at 3:08 AM, Knut Anders Hatlen
<kn...@oracle.com> wrote:
> Rick Hillegas <ri...@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
Hi,
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
SecureServerTest
- 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.
Myrna
Re: [URGENT] Critical test situation on trunk
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Rick Hillegas <ri...@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
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
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.
Thanks,
-Rick
On 2/6/12 10:52 AM, Katherine Marsden wrote:
> On 2/6/2012 5:52 AM, Rick Hillegas wrote:
>> I am looking into the best way to get a window installation where I
>> can debug this. Stand by...
>>
> Thanks Rick,
>
> Talking with Myrna, Mike and Mamta and looking back at the onset of
> the NativeAuthenticationTest hang. I see that even at that time we
> had the prior SecureServerTest failure
>
> (net)derbynet.SecureServerTest.testServerStartup used 6750 ms E.
> (net)derbynet.SecureServerTest.testServerStartup used 46827 ms F.
> Which we found later to have the stack Trace below [1] and which
> seemed to send things going down hill and let up to the hagn.
> Myrna also told me at the the time this all started, she just
> switched over to cygwin from another shell program.
>
> I have done suites.All runs sane and insane on my Windows machine as
> have Mike and Mamta and runs are clean, so I think it would be good to
> reenable NativeAuthenticationServiceTest on non-windows platforms and
> even on windows for non-ibm jvm's.
> Myrna is working on figuring out why the cygwin upgrade caused such
> trouble on this machine. I will do this tomorrow unless someone else
> beats me to it.
>
>
> Thanks
>
> Kathey
>
> [1] SecureServerTest( Opened = false, Authenticated= false, CustomDerbyProperties= null, WildCardHost= null )java.lang.InterruptedException
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:184)
> at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:146)
> at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runServerCommand(SecureServerTest.java:481)
> at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runsysinfo(SecureServerTest.java:411)
> at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:350)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
>
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/6/2012 5:52 AM, Rick Hillegas wrote:
> I am looking into the best way to get a window installation where I
> can debug this. Stand by...
>
Thanks Rick,
Talking with Myrna, Mike and Mamta and looking back at the onset of the
NativeAuthenticationTest hang. I see that even at that time we had the
prior SecureServerTest failure
(net)derbynet.SecureServerTest.testServerStartup used 6750 ms E.
(net)derbynet.SecureServerTest.testServerStartup used 46827 ms F.
Which we found later to have the stack Trace below [1] and which seemed
to send things going down hill and let up to the hagn.
Myrna also told me at the the time this all started, she just switched
over to cygwin from another shell program.
I have done suites.All runs sane and insane on my Windows machine as
have Mike and Mamta and runs are clean, so I think it would be good to
reenable NativeAuthenticationServiceTest on non-windows platforms and
even on windows for non-ibm jvm's.
Myrna is working on figuring out why the cygwin upgrade caused such
trouble on this machine. I will do this tomorrow unless someone else
beats me to it.
Thanks
Kathey
[1] SecureServerTest( Opened = false, Authenticated= false, CustomDerbyProperties= null, WildCardHost= null )java.lang.InterruptedException
at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:184)
at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:146)
at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runServerCommand(SecureServerTest.java:481)
at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runsysinfo(SecureServerTest.java:411)
at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:350)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
Re: [URGENT] Critical test situation on trunk
Posted by Rick Hillegas <ri...@oracle.com>.
On 2/3/12 12:30 PM, Katherine Marsden wrote:
> Right now the IBM Tests are not running due to a hang from in
> NativeAuthenticationServiceTest DERBY-5601
>
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1239981.html
>
>
> Oracle tests seem to be broken:
> http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1239719.html
>
>
> I am not sure if Oracle has the same issue or something else.
>
> As far as I know these are our only sources of regression tests so I
> think we better close down trunk except for efforts to get the runs
> going again. Unfortunately for DERBY-5601 I cannot reproduce at least
> with the single test on my machine.Unfortunately also I am about to
> head out of town for the weekend.
>
> Rick, would you be willing to disable NativeAuthenticationServiceTest
> for the short term to see if that at least gets the IBM runs going again?
I am looking into the best way to get a window installation where I can
debug this. Stand by...
Thanks,
-Rick
>
> Can someone look to see what is happening with the Oracle runs?
>
> Can everyone please refrain from other trunk checkins until we get
> things stabilized?
>
> Thanks
>
> Kathey
>
Re: [URGENT] Critical test situation on trunk
Posted by Myrna van Lunteren <m....@gmail.com>.
On Mon, Feb 20, 2012 at 3:51 PM, Katherine Marsden
<km...@sbcglobal.net> wrote:
> On 2/17/2012 5:07 PM, Dag H. Wanvik wrote:
>>
>> Katherine Marsden<km...@sbcglobal.net> writes:
>>
>>> Both IBM and Oracle tests are running through to completion now on
>>> all platforms. Thanks Rick for the hang fix, Kristian for the spawned
>>> process improvements and Myrna for debugging the environment and
>>> machine issues and Mike for making lots of intermittent test failure
>>> fixes and everyone who did local runs while things were down. Such a
>>> community effort!
>>
>> And thanks to Knut for checking/unclogging the Oracle nightlies :)
>
> Yes indeed. Thanks to Knut and anyone else I forgot!
>
+2 (can I do that?) A big thanks from me too!
Myrna
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/17/2012 5:07 PM, Dag H. Wanvik wrote:
> Katherine Marsden<km...@sbcglobal.net> writes:
>
>> Both IBM and Oracle tests are running through to completion now on
>> all platforms. Thanks Rick for the hang fix, Kristian for the spawned
>> process improvements and Myrna for debugging the environment and
>> machine issues and Mike for making lots of intermittent test failure
>> fixes and everyone who did local runs while things were down. Such a
>> community effort!
> And thanks to Knut for checking/unclogging the Oracle nightlies :)
Yes indeed. Thanks to Knut and anyone else I forgot!
Re: [URGENT] Critical test situation on trunk
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Katherine Marsden <km...@sbcglobal.net> writes:
> Both IBM and Oracle tests are running through to completion now on
> all platforms. Thanks Rick for the hang fix, Kristian for the spawned
> process improvements and Myrna for debugging the environment and
> machine issues and Mike for making lots of intermittent test failure
> fixes and everyone who did local runs while things were down. Such a
> community effort!
And thanks to Knut for checking/unclogging the Oracle nightlies :)
Dag
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/3/2012 12:30 PM, Katherine Marsden wrote:
> Right now the IBM Tests are not running due to a hang from in
> NativeAuthenticationServiceTest DERBY-5601
>
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1239981.html
>
>
> Oracle tests seem to be broken:
> http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1239719.html
>
>
> I am not sure if Oracle has the same issue or something else.
>
> As far as I know these are our only sources of regression tests so I
> think we better close down trunk except for efforts to get the runs
> going again. Unfortunately for DERBY-5601 I cannot reproduce at least
> with the single test on my machine.Unfortunately also I am about to
> head out of town for the weekend.
>
Both IBM and Oracle tests are running through to completion now on all
platforms. Thanks Rick for the hang fix, Kristian for the spawned
process improvements and Myrna for debugging the environment and machine
issues and Mike for making lots of intermittent test failure fixes and
everyone who did local runs while things were down. Such a community
effort!
Here are the latest results with a few new failures. I filed a new
issue from the IBM runs in SecureServerTest but not the ones that show
up in the oracle runs.
IBM trunk Test runs Feb 15 (1244826)
Windows all passed:
people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1244826.html
Linux 1 new failure in SecureServerTest -
http://people.apache.org/~myrnavl/derby_test_results/main/linux/testSummary-1244826.html
I filed https://issues.apache.org/jira/browse/DERBY-5621 for the Linux
issue.
Oracle trunk test runs Feb 15 (1244593)
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/Limited/testSummary-1244593.html
I see new failures in UpdateLocksTest on vista 1.5: I will leave to
someone with access to this system to file the issue and determine if it
might be checkin related.
http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.5/testing/testlog/vista/1244593-suitesAll_diff.txt
1) testReadUncommitted(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)java.sql.SQLException: Table/View 'A' already exists in Schema 'APP'.
at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.Util.generateCsSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source)
at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:185)
at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testReadUncommitted(UpdateLocksTest.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
Caused by: ERROR X0Y32: Table/View 'A' already exists in Schema 'APP'.
at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)
at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.duplicateDescriptorException(Unknown Source)
at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(Unknown Source)
at org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(Unknown Source)
at org.apache.derby.impl.sql.execute.MiscResultSet.open(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
... 36 more
There was 1 failure:
1) testSerializable(org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest)junit.framework.AssertionFailedError: Missing rows in ResultSet
at org.apache.derbyTesting.junit.JDBC.assertUnorderedResultSet(JDBC.java:1351)
at org.apache.derbyTesting.junit.JDBC.assertUnorderedResultSet(JDBC.java:1287)
at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.updateBtreeSetLocks(UpdateLocksTest.java:6897)
at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.doRunTests(UpdateLocksTest.java:387)
at org.apache.derbyTesting.functionTests.tests.store.UpdateLocksTest.testSerializable(UpdateLocksTest.java:154)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:113)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
FAILURES!!!
Tests run: 13247, Failures: 1, Errors: 1
Kathey
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/3/2012 1:45 PM, Katherine Marsden wrote:
> On 2/3/2012 1:36 PM, Dag H. Wanvik wrote:
>> Katherine Marsden<km...@sbcglobal.net> writes:
>>
>>> Can someone look to see what is happening with the Oracle runs?
>> Knut has been tending these lately, Apparently he has had some issues
>> with the machines, and he's out this week. We aim to get tests up and
>> running again.
> Thanks Dag,
>
> Just so we have some sort of regression test reporting in the
> meanwhile. I am going to go ahead and disable
> NativeAuthenticationServiceTest so hopefully the IBM runs will get
> going again.
>
> On my windows machine, I kicked of suites.All and it ran through
> this test with no problem, so I am not clear what the problem may be,
> but would like to start seeing something run that the community can
> check.
>
>
>
Good news is IBM trunk runs are not hanging. The bad news is they are
failing miserably with 77 failures and 816 errors.
It starts with
java.lang.InterruptedException in ServerPropertiesTest and then fails to start the database from there.
http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1240448.html
and again the next night with:
http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1240654.html
1) SecureServerTest( Opened = false, Authenticated= false, CustomDerbyProperties= null, WildCardHost= null )java.lang.InterruptedException
at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:184)
at org.apache.derbyTesting.junit.SpawnedProcess.complete(SpawnedProcess.java:146)
at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runServerCommand(SecureServerTest.java:481)
at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.runsysinfo(SecureServerTest.java:411)
at org.apache.derbyTesting.functionTests.tests.derbynet.SecureServerTest.testServerStartup(SecureServerTest.java:350)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:116)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
Jira is down right now. I will file an issue as soon as it is up.
Thanks
Kathey
Re: [URGENT] Critical test situation on trunk
Posted by Katherine Marsden <km...@sbcglobal.net>.
On 2/3/2012 1:36 PM, Dag H. Wanvik wrote:
> Katherine Marsden<km...@sbcglobal.net> writes:
>
>> Can someone look to see what is happening with the Oracle runs?
> Knut has been tending these lately, Apparently he has had some issues
> with the machines, and he's out this week. We aim to get tests up and
> running again.
Thanks Dag,
Just so we have some sort of regression test reporting in the meanwhile.
I am going to go ahead and disable NativeAuthenticationServiceTest so
hopefully the IBM runs will get going again.
On my windows machine, I kicked of suites.All and it ran through this
test with no problem, so I am not clear what the problem may be, but
would like to start seeing something run that the community can check.
Re: [URGENT] Critical test situation on trunk
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Katherine Marsden <km...@sbcglobal.net> writes:
> Can someone look to see what is happening with the Oracle runs?
Knut has been tending these lately, Apparently he has had some issues
with the machines, and he's out this week. We aim to get tests up and
running again.
Thanks,
Dag