Thanks. Filed: https://issues.apache.org/jira/browse/DERBY-6333
-----Original Message----- From: Rick Hillegas [mailto:[email protected]] Sent: Wednesday, September 04, 2013 10:54 AM To: [email protected] Subject: Re: possible bug in DRDAConnThread.java Hi Yoel, Yes, an NPE sounds like a bug to me. Thanks for offering to file a bug. Thanks, -Rick On 9/4/13 4:09 PM, Yoel Spotts wrote: > > I'm using derby 10.10.1.1 on windows and am encountering an issue when > shutting down derby. After tracking down the problem, there seems to > be a possible bug in the DRDAConnThread.java - before filing a jira > item, I wanted to run this by the community for feedback. > > The issue manifests itself when shutting down derby - under certain > circumstances, a NullPointerException is thrown. Even worse - the > exception is "hidden" since the handling of the exception itself > throws an exception. This issue is not consistent in our tests and > presents unpredictably - most likely a timing issue. While I don't > have a firm grasp of the exact circumstances that cause the exception > to be thrown, I believe it is clear that the handling of an exception > is less than ideal and leads to this exception. Tracing through the > code in DRDAConnThread.java will provide the best explanation: > > 1)Code enters parseSECCHK (line 3117) to perform security check on a > new session > > 2)All security checks pass and control continues to line 3357 to the > call > > database.getConnection().resetFromPool(); > > 3)That method call generates an exception as derby is shutting down as > follows: > > java.sql.SQLNonTransientConnectionException: No current connection. > > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLEx > ceptionFactory40.java:77) > > > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:148) > > at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:164) > > at org.apache.derby.impl.jdbc.Util.noCurrentConnection(Util.java:333) > > at > org.apache.derby.impl.jdbc.EmbedConnection.checkIfClosed(EmbedConnecti > on.java:2375) > > > at > org.apache.derby.impl.jdbc.EmbedConnection.setupContextStack(EmbedConn > ection.java:2588) > > > at > org.apache.derby.impl.jdbc.EmbedConnection.resetFromPool(EmbedConnecti > on.java:2983) > > > at > org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.j > ava:3357) > > > at > org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConn > Thread.java:1198) > > > at > org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThre > ad.java:998) > > > at > org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) > > Caused by: java.sql.SQLException: No current connection. > > at > org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExce > ptionFactory.java:42) > > > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportA > crossDRDA(SQLExceptionFactory40.java:125) > > > at > org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(SQLEx > ceptionFactory40.java:71) > > > ... 10 more > > 4)This gets caught in line 3365 and calls handleException > > 5)handleException attempts to inform the client of the exception and > then calls closeSession and close on lines 8759 and 8760. > > *6)*closeSession() sets the *session* member variable to null. *This > is the crux of the issue * > > 7)After handleException is called, control returns to parseSECCHK() > and continues to line 3374 (as all security checks passed). > > 8)This line attempts to deference a member of *session* which has just > been set to null by closeSession (in step 6) !! > > 9)This will throw a NullPointerException which is passed up the stack > and eventually caught and handled on line 320 > > 10)This handling calls handleException(e) > > 11)handleException then calls sendUnexpectedException which attempts > to dereference *session* once again on line 8794, which of course > throws a NullPointerException. > > 12)This NPE is never caught, thus handled by the > uncaughtExceptionHandler which by default terminates the thread (note > that this causes the above exception to step 3 to be "hidden" as only > this exception is bubbled to the uncaughtExceptionHandler) > > 13)However, we have set a default uncaughtExceptionHandler in our > application which terminates on an uncaught exception. This is > undesirable in this situation since we are only trying to terminate an > embedded derby instance, but do not wish our application to terminate. > However, this default behavior makes sense as an uncaught exception > usually indicates a serious error. > > Thus, it seems that the handling of an exception thrown by > resetFromPool() needs work. I'm not sure what the "correct" behavior > should be but throwing a DRDAProtocolException.newDisconnectException > after handleException does "fix" the issue. > > Shall I file a bug? Is there anything else I should be aware of? > > Thanks > > Yoel Spotts >
