Rick Hillegas <[email protected]> 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
