db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brett Bergquist (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5552) Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
Date Tue, 27 Dec 2011 16:12:30 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13176216#comment-13176216
] 

Brett Bergquist commented on DERBY-5552:
----------------------------------------

If I disable the istat daemon, I still the the timeout but now the error is reported as it
should and the transaction is aborted and my code continues.  With the itstat deamon enabled,
then the lock timeout is discovered and signaled by exception being thrown but between the
time it gets caught and processed, the istat daemon has set the "isValid" property of the
statement to "false".  The original lock timeout exception is caught but then the 

    Activation.checkStatementValidity()

is called in the exception handler.  This finds that the statement is not valid (isValid ==
false) and throws its own exception indicating that a recompilation is required, swallowing
the original lock timeout exception in the process.  This causes the existing statement to
be rebuilt and re-executed but the locks are still present, the lock timeout will occur again,
the lock timeout exception will be thrown, the istat daemon will set the "isValid" to false
again, etc.  The process just continues forever.

The patch that I attached to the bug only calls

    Activation.checkStatementValidity()

in the exception handler if the caught exception is not set to REPORT_ALWAYS.  This seem okay
and to make sense because if the code is handling an exception that is to be REPORT_ALWAYS,
there is no sense looking for a statement that is invalid; just report the exception.

                
> Derby threads hanging when using ClientXADataSource and a deadlock or lock timeout occurs
> -----------------------------------------------------------------------------------------
>
>                 Key: DERBY-5552
>                 URL: https://issues.apache.org/jira/browse/DERBY-5552
>             Project: Derby
>          Issue Type: Bug
>          Components: Network Server
>    Affects Versions: 10.8.1.2
>         Environment: Solaris 10, Glassfish V2.1.1,
>            Reporter: Brett Bergquist
>            Priority: Blocker
>         Attachments: appserverstack.txt, client.tar.Z, derby.log, derbystackatshutdown.txt,
execute.patch, transactionsleft.txt
>
>
> The issue arrives when multiple XA transactions are done in parallel and there is either
a lock timeout or a lock deadlock detected.  When this happens the connection is leaked in
the Glassfish connection pool and the client thread hangs in "org.apache.derby.client.netReply.fill(Reply.java:172)".
 
> Shutting down the app server fails because the thread has a lock in "org.apache.derby.client.net.NetConnection40"
and another task is calling "org.apache.derby.client.ClientPooledConnection.close(ClientPooledConnection.java:214)"
which is waiting for the lock.
> Killing the appsever using "kill" and then attempting to shutdown Derby network server
causes the Network Server to hang.  One of the threads hangs waiting for a lock at "org.apache.derby.impl.drda.NeworkServerControlImpl.removeFromSessionTable(NetworkServerControlImpl.java:1525)"
and the "main" thread has this locked at "org.apache.derby.impl.drda.NetworkServerControlImpl.executeWork(NetworkServerControlImpl.java:2242)"
and it itself is waiting for a lock which belongs to a thread that is stuck at "org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118)
which is in the TIMED_WAITING state.
> Only by killing the Network Server using "kill" is possible at this point.
> There are transactions left even though all clients have been removed.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message