Return-Path: Delivered-To: apmail-jackrabbit-users-archive@minotaur.apache.org Received: (qmail 1780 invoked from network); 18 May 2010 23:02:44 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 18 May 2010 23:02:44 -0000 Received: (qmail 80942 invoked by uid 500); 18 May 2010 23:02:44 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 80833 invoked by uid 500); 18 May 2010 23:02:44 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 80824 invoked by uid 99); 18 May 2010 23:02:44 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 18 May 2010 23:02:44 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of aklimets@day.com designates 207.126.148.85 as permitted sender) Received: from [207.126.148.85] (HELO psmtp.com) (207.126.148.85) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 18 May 2010 23:02:38 +0000 Received: from source ([74.125.83.44]) by eu3sys201aob102.postini.com ([207.126.154.11]) with SMTP ID DSNKS/McdncU2s2NpqJg6z9I9iQUVhwi4W45@postini.com; Tue, 18 May 2010 23:02:17 UTC Received: by gwb19 with SMTP id 19so3616224gwb.17 for ; Tue, 18 May 2010 16:02:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.210.16 with SMTP id i16mr131468ybg.70.1274223734366; Tue, 18 May 2010 16:02:14 -0700 (PDT) Received: by 10.150.201.2 with HTTP; Tue, 18 May 2010 16:02:14 -0700 (PDT) In-Reply-To: References: <17DF5A8C-6AC1-4FFD-9EF5-A4A344943805@sptci.com> Date: Wed, 19 May 2010 01:02:14 +0200 Message-ID: Subject: Re: Persistence Manager - Query on Concurrency From: Alexander Klimetschek To: users@jackrabbit.apache.org Content-Type: text/plain; charset=ISO-8859-1 On Tue, May 18, 2010 at 18:03, Narendra Sharma wrote: > The reason I asked this query is because I noticed lot of threads (70-75%) > BLOCKED in ISMLocking (tried with both DefaultISMLocking and > FineGrainedISMLocking). What I understand is that when a session is saved > the data gets written to persistence manager and the events are sent to > listeners. Some of these listeners are synchronous listeners like > SearchManager which in turn updates the Lucene index. > > All the 70-75% threads are blocked in either acquireReadLock or > acquireWriteLock. The number of threads in my test are large (between 400 to > 800). The question is why are there so many blocks? Could you share your test case (and the jackrabbit version used)? If all those threads each have sessions that are writing to the repository, some blocking might be "normal" due to the high level of contention. Just a guess, though. Regards, Alex -- Alexander Klimetschek alexander.klimetschek@day.com