Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When the server fails (due to a full disk) the client can get into a NPE inside jaybird [JDBC359] #401

Closed
firebird-automations opened this issue Jul 10, 2014 · 5 comments

Comments

@firebird-automations
Copy link

Submitted by: Steffen Heil (firebirdsql.org_partner.sh-solutions.de)

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: CORE4491

| 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)

Commits: f3e3b1a ca1f999 FirebirdSQL/fbt-repository@72c49a5 FirebirdSQL/fbt-repository@4655ba0

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

This might be related to JDBC350 and JDBC357, 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

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2.6 [ 10588 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

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.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants