[
https://issues.apache.org/jira/browse/DERBY-6510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935201#comment-13935201
]
Brett Bergquist commented on DERBY-6510:
----------------------------------------
I was thinking about https://issues.apache.org/jira/browse/DERBY-6317 as well.
I can't remember if patched that into production or not :( I will check later
today.
I did some more analysis on the threads. 5 of the threads are relating to
executing the statement and 1 is relating to preparing the statement. Threads
75, 63, 42, 34, and 16 are executing a statement and threads 72 and 36 are
preparing a statement. Threads 75 and 42 do see changes in the stack trace
over the 1 minute and see it within the optimizer and also blocking within
prepMinion. Threads 63, 36, 34, and 16, always are blocking in prepMinion
during the stacktrace snapshot.
I believe Threads 75, 72, 63, 42, 34, and 16 are the same query being performed
with thread 72 being the prepare statement. Thread 36 appears to be related to
another long running request but is different and I think can be discounted.
> Deby engine threads not making progress
> ---------------------------------------
>
> Key: DERBY-6510
> URL: https://issues.apache.org/jira/browse/DERBY-6510
> Project: Derby
> Issue Type: Bug
> Components: Network Server
> Affects Versions: 10.9.1.0
> Environment: Oracle Solaris 10/9, Oracle M5000 32 CPU, 128GB memory,
> 8GB allocated to Derby Network Server
> Reporter: Brett Bergquist
> Priority: Critical
> Attachments: dbstate.log, derbystacktrace.txt
>
>
> We had an issue today in a production environment at a large customer site.
> Basically 5 database interactions became stuck and are not progressing.
> Part of the system dump performs a stack trace every few seconds for a period
> of a minute on the Glassfish application server and the Derby database engine
> (running in network server mode). Also, the dump captures the current
> transactions and the current lock table (ie. syscs_diag.transactions and
> syscs_diag.lock_table). We had to restart the system and in doing so, the
> Derby database engine would not shutdown and had to be killed.
> The stack traces of the Derby engine show 5 threads that are basically making
> no progress in that at each sample, they are at the same point, waiting.
> I will attach the stack traces as well as the state of the transactions and
> locks.
> Interesting is that the "derby.jdbc.xaTransactionTimeout =1800" is set, yet
> the transactions did not timeout. The timeout is for 30 minutes but the
> transactions were in process for hours.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
