Return-Path: Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: (qmail 39621 invoked from network); 10 Nov 2006 12:28:59 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 10 Nov 2006 12:28:59 -0000 Received: (qmail 18336 invoked by uid 500); 10 Nov 2006 12:29:10 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 18009 invoked by uid 500); 10 Nov 2006 12:29:08 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 18000 invoked by uid 99); 10 Nov 2006 12:29:08 -0000 Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Nov 2006 04:29:08 -0800 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Nov 2006 04:28:57 -0800 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 1FA737142F7 for ; Fri, 10 Nov 2006 04:28:37 -0800 (PST) Message-ID: <3915882.1163161717126.JavaMail.jira@brutus> Date: Fri, 10 Nov 2006 04:28:37 -0800 (PST) From: "Przemo Pakulski (JIRA)" To: dev@jackrabbit.apache.org Subject: [jira] Created: (JCR-632) VersionManager lock not released in some circumstances MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org VersionManager lock not released in some circumstances ------------------------------------------------------ Key: JCR-632 URL: http://issues.apache.org/jira/browse/JCR-632 Project: Jackrabbit Issue Type: Bug Reporter: Przemo Pakulski Priority: Critical In some circumstances it is possible that lock is not released in VersionManager.checkin method. There is following block of code in checkin nethod : aquireReadLock(); try { ..... } catch (IllegalStateException e) { releaseReadLock(); throw new RepositoryException("Unable to start edit operation."); } Lock release should be in finally block to make sure that lock is released when unexpected exception is thrown. In our environment we are getting NPE in mentioned block of code, it results in persisten lock. No versioning operation is possible and our application server is running ot of threads (all threads are locked). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira