Issue Details (XML | Word | Printable)

Key: JDBC-359
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Mark Rotteveel
Reporter: Steffen Heil
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Jaybird JCA/JDBC Driver

When the server fails (due to a full disk) the client can get into a NPE inside jaybird

Created: 10/Jul/14 01:56 PM   Updated: 30/Dec/14 12:00 PM
Component/s: Connection pool
Affects Version/s: Jaybird 2.2.5
Fix Version/s: Jaybird 2.2.6

Environment: java 1.7.0_55, firebird 2.5.1.26351.ds4-2ubuntu0.1


 Description  « Hide
When the server disk was full, the firebird server process died and the client started to report NPEs instead of SQLExceptions.
We do have a jmap memory dump of that VM, pending reproduction.


related: http://tracker.firebirdsql.org/browse/CORE-4491

| java.lang.NullPointerException
| at org.firebirdsql.jca.FBManagedConnection.internalCommit(FBManagedConnection.java:625)
| at org.firebirdsql.jca.FBLocalTransaction.internalCommit(FBLocalTransaction.java:193)
| at org.firebirdsql.jca.FBLocalTransaction.commit(FBLocalTransaction.java:167)
| at org.firebirdsql.jdbc.InternalTransactionCoordinator$AutoCommitCoordinator.statementCompleted(InternalTransactionCoordinator.java:256)
| at org.firebirdsql.jdbc.InternalTransactionCoordinator.statementCompleted(InternalTransactionCoordinator.java:59)
| at org.firebirdsql.jdbc.AbstractStatement.notifyStatementCompleted(AbstractStatement.java:253)
| at org.firebirdsql.jdbc.AbstractPreparedStatement.notifyStatementCompleted(AbstractPreparedStatement.java:160)
| at org.firebirdsql.jdbc.AbstractStatement.notifyStatementCompleted(AbstractStatement.java:248)
| at org.firebirdsql.jdbc.AbstractPreparedStatement.executeUpdate(AbstractPreparedStatement.java:214)
| at sun.reflect.GeneratedMethodAccessor32.invoke(Unknown Source)
| at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
| at java.lang.reflect.Method.invoke(Method.java:606)
| at org.firebirdsql.pool.PooledPreparedStatementHandler.invoke(PooledPreparedStatementHandler.java:171)
| at org.firebirdsql.pool.$Proxy5.executeUpdate(Unknown Source)
| at com.osiris4.core.persistence.safe.PreparedStatement.executeUpdate(PreparedStatement.java:153)




 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Mark Rotteveel added a comment - 10/Jul/14 06:02 PM
This might be related to JDBC-350 and JDBC-357, but it could also be an independent problem.

Looking at the code when a fatal connection error occurs, the connection held within FBManagedConnection is 'destroyed' and then set to null. The sequence of events in this specific case seem to be:

1) attempt to commit
2) somewhere in the commit a GDSException is thrown
3) GDSException caught and forwarded to error listener which 'destroys' the connection and sets it to null
4) error caught in step 3 is rethrown
5) catch block from try around commit wants to rollback, but the connection is already null and causes a NullPointerException

Scheduled for 2.2.6

Mark Rotteveel added a comment - 11/Jul/14 05:10 PM
Replaced most direct uses of gdsHelper with a call to getGDSHelper() that checks for null and otherwise throws a GDSException (2.2.x) or SQLException (3.0). In the cases where that is not an option, I added an extra null check.

For 3.0 I will probably revisit this code for a more thorough refactoring when I remove the remnants of the old protocol implementation.