Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 14 Mar 2014 18:18:44 +0000 (UTC)
From: "Mike Matrigali (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12701314.1394737462972.71321.1394821124837@arcas>
In-Reply-To: <JIRA.12701314.1394737462972@arcas>
References: <JIRA.12701314.1394737462972@arcas>
Subject: [jira] [Commented] (DERBY-6510) Deby engine threads not making
 progress
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Mike Matrigali commented on DERBY-6510:
---------------------------------------

the posted query plan looks pretty straight forward.  I was looking for stuff like views and nested sub queries which have caused issues in the past, but did not see any.    All the row estimate counts look reasonable.

> 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, prstat.log, queryplan.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)