Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 85123 invoked from network); 18 Feb 2010 19:43:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 18 Feb 2010 19:43:05 -0000 Received: (qmail 99312 invoked by uid 500); 18 Feb 2010 19:43:04 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 99263 invoked by uid 500); 18 Feb 2010 19:43:04 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 99255 invoked by uid 99); 18 Feb 2010 19:43:04 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2010 19:43:04 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of charlie.hubbard@gmail.com designates 74.125.92.25 as permitted sender) Received: from [74.125.92.25] (HELO qw-out-2122.google.com) (74.125.92.25) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 18 Feb 2010 19:42:56 +0000 Received: by qw-out-2122.google.com with SMTP id 9so400570qwb.13 for ; Thu, 18 Feb 2010 11:42:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=OrCptOU6b7kBX7MgK/WGn8fbR0gYW33T/b3S173rz0Q=; b=dSTz3dse7RBZjHmNYS62doY79a8ylMXH4ZLgunxdhgE0xbNjjBxYNTOwKHGRp3idQl I3B/7X35657nvSQTz/w1GDjhHTqNi/ja0J3yIWUC+dH1If+BNjFEMACCpxj2xwPTfcpt ps3Zmwf5BEXJCJyYh3WJoIMOJfRVxCt3aXK/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=fB0ysrbyVW2O6fFWuz1hMIEqu4spncSWb1PkmycNcqsWNcJh+UysIOF+RRGZ2/d9si mf/JCje0oVqZiFGkW+kRGSdKM+j7KumPFIFRnBd9z9OeckuOkAFcE5AGtusyUvTDqu/r DjRFdVVq/HPCTox3RuSYtKq7mYm+5AML7z12Y= MIME-Version: 1.0 Received: by 10.239.168.9 with SMTP id i9mr1129189hbe.76.1266522152757; Thu, 18 Feb 2010 11:42:32 -0800 (PST) In-Reply-To: <4B7C77EC.8020109@amberpoint.com> References: <4B7C77EC.8020109@amberpoint.com> Date: Thu, 18 Feb 2010 14:42:32 -0500 Message-ID: Subject: Re: Deadlocked in Log2File From: Charlie Hubbard To: Derby Discussion Content-Type: multipart/alternative; boundary=001485f87c6203eb19047fe52b94 X-Virus-Checked: Checked by ClamAV on apache.org --001485f87c6203eb19047fe52b94 Content-Type: text/plain; charset=ISO-8859-1 We do not call SYSCS_UTIL.SYSCS_FREEZE_DATABASE or SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE. We do perform backups using CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE(?). However, in this particular test case the backup hasn't been run. So, for this particular test case the backup_database stored proc hasn't been called. This is a new application that uses derby so I can't say if this is new behavior for this application or not. We don't do any replication. This seems to happen fairly frequently if I try and process a very large data set for my application (70,000 entries). For smaller data set sizes it seems to work out ok (7500 entries). I encountered this from within my profiler so I decided to try this outside the profiler, and I didn't encounter any locking issue. If I do this within my profiler I see it frequently. For right now I think it's the profiler unless I can reproduce this outside my profiler. I'm using Derby 10.5.3. Thanks, Charlie On Wed, Feb 17, 2010 at 6:12 PM, Bryan Pendleton wrote: > I'm sometimes getting deadlocks in Log2File where all my worker threads >> are getting blocked, but I can't figure out which monitor they are blocked >> on. >> > > Thanks for sending the thread dump, it was very interesting. > > I agree with you, it's not clear what is blocking these threads, > at least from the thread dump. > > I think this could be a Derby bug. How often does it happen? Is it > a new behavior? > > Looking at the source code, LogToFile.flush() has some complicated > synchronization logic which interacts with the backup/checkpoint methods. > > Does your application perform a backup? > > Does your application involve replication? > > Does your application ever call SYSCS_UTIL.SYSCS_FREEZE_DATABASE > or SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE? > > If you are calling SYSCS_FREEZE_DATABASE, is it possible that you > have some path through your system which fails to subsequently call > SYSCS_UNFREEZE_DATABASE? > > thanks, > > bryan > > --001485f87c6203eb19047fe52b94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We do not call=A0SYSCS_UTIL.SYSCS_FREEZE_DATABASE or=A0SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE.
<= br>
We do perform backups using=A0CALL SYSCS_UTIL.SY= SCS_BACKUP_DATABASE(?). =A0However, in this particular test case the backup= hasn't been run. =A0So, for this particular test case the backup_datab= ase stored proc hasn't been called.

This is a new application that uses derby s= o I can't say if this is new behavior for this application or not. =A0W= e don't do any replication. =A0This seems to happen fairly frequently i= f I try and process a very large data set for my application (70,000 entrie= s). =A0For smaller data set sizes it seems to work out ok (7500 entries).

I encountered this from within my profiler = so I decided to try this outside the profiler, and I didn't encounter a= ny locking issue. =A0If I do this within my profiler I see it frequently. = =A0For right now I think it's the profiler unless I can reproduce this = outside my profiler.

I'm using Derby 10.5.3.

Thanks,
Charlie

On Wed, Feb 17, 2010 at 6:12 P= M, Bryan Pendleton <bpendleton@amberpoint.com> wrote= :
I'm sometimes getting deadlocks in Log2File where all my worker threads= are getting blocked, but I can't figure out which monitor they are blo= cked on.

Thanks for sending the thread dump, it was very interesting.

I agree with you, it's not clear what is blocking these threads,
at least from the thread dump.

I think this could be a Derby bug. How often does it happen? Is it
a new behavior?

Looking at the source code, LogToFile.flush() has some complicated
synchronization logic which interacts with the backup/checkpoint methods.
Does your application perform a backup?

Does your application involve replication?

Does your application ever call SYSCS_UTIL.SYSCS_FREEZE_DATABASE
or SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE?

If you are calling SYSCS_FREEZE_DATABASE, is it possible that you
have some path through your system which fails to subsequently call
SYSCS_UNFREEZE_DATABASE?

thanks,

bryan


--001485f87c6203eb19047fe52b94--