db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: [URGENT] Critical test situation on trunk
Date Wed, 08 Feb 2012 10:01:06 GMT
Rick Hillegas <rick.hillegas@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

Mime
View raw message