Return-Path: X-Original-To: apmail-curator-dev-archive@minotaur.apache.org Delivered-To: apmail-curator-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5E5BB180CF for ; Fri, 4 Mar 2016 13:42:43 +0000 (UTC) Received: (qmail 61799 invoked by uid 500); 4 Mar 2016 13:42:43 -0000 Delivered-To: apmail-curator-dev-archive@curator.apache.org Received: (qmail 61357 invoked by uid 500); 4 Mar 2016 13:42:41 -0000 Mailing-List: contact dev-help@curator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@curator.apache.org Delivered-To: mailing list dev@curator.apache.org Received: (qmail 61334 invoked by uid 99); 4 Mar 2016 13:42:40 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 04 Mar 2016 13:42:40 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id C97772C1F58 for ; Fri, 4 Mar 2016 13:42:40 +0000 (UTC) Date: Fri, 4 Mar 2016 13:42:40 +0000 (UTC) From: =?utf-8?Q?Jakub_Strolen=C3=BD_=28JIRA=29?= To: dev@curator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (CURATOR-307) InterProcessReadWriteLock can throw IndexOutOfBoundsException when connection is lost MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/CURATOR-307?page=3Dcom.atlassi= an.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakub Strolen=C3=BD updated CURATOR-307: ----------------------------------- Description:=20 We are using recipe InterProcessMutex as lock for our cluster environment. We found that it is possible that acquiring and/or releasing of lock can fa= il when connection to ZooKeeper is lost or changed. If you have have following sample code: InterProcessMutex.acquire(); doSomething(); InterProcessMutex.release(); You can get following exception in release() method, when connection is los= t after lock is acquired. Stack trace: {{java.lang.IllegalMonitorStateException: You do not own the lock: /cluster= s/Production/something/lock at org.apache.curator.framework.recipes.locks.InterProcessMutex.release(Int= erProcessMutex.java:128)}} and following stack trace when lock directory is empty (because emphemeral = nodes are deleted, because of connection was lost) {{java.lang.IndexOutOfBoundsException: Index: 2147483647, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock.rea= dLockPredicate(InterProcessReadWriteLock.java:190) at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock.acc= ess$0(InterProcessReadWriteLock.java:163) at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock$2.g= etsTheLock(InterProcessReadWriteLock.java:137) at org.apache.curator.framework.recipes.locks.LockInternals.internalLockLoo= p(LockInternals.java:287) at org.apache.curator.framework.recipes.locks.LockInternals.attemptLock(Loc= kInternals.java:226) at org.apache.curator.framework.recipes.locks.InterProcessMutex.internalLoc= k(InterProcessMutex.java:221) at org.apache.curator.framework.recipes.locks.InterProcessMutex.acquire(Int= erProcessMutex.java:77)}} These operations should fail more gracefully, maybe with dedicated exceptio= n, when connection is lost or changed. was: We are using recipe InterProcessMutex as lock for our cluster environment. We found that it is possible that acquiring and/or releasing of lock can fa= il when connection to ZooKeeper is lost or changed. If you have have following sample code: InterProcessMutex.acquire(); doSomething(); InterProcessMutex.release(); You can get following exception in release() method, when connection is los= t after lock is acquired. Stack trace: {{ java.lang.IllegalMonitorStateException: You do not own the lock: /clusters/= Production/something/lock at org.apache.curator.framework.recipes.locks.InterProcessMutex.release(Int= erProcessMutex.java:128) }} and following stack trace when lock directory is empty (because emphemeral = nodes are deleted, because of connection was lost) {{ java.lang.IndexOutOfBoundsException: Index: 2147483647, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:653) at java.util.ArrayList.get(ArrayList.java:429) at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock.rea= dLockPredicate(InterProcessReadWriteLock.java:190) at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock.acc= ess$0(InterProcessReadWriteLock.java:163) at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock$2.g= etsTheLock(InterProcessReadWriteLock.java:137) at org.apache.curator.framework.recipes.locks.LockInternals.internalLockLoo= p(LockInternals.java:287) at org.apache.curator.framework.recipes.locks.LockInternals.attemptLock(Loc= kInternals.java:226) at org.apache.curator.framework.recipes.locks.InterProcessMutex.internalLoc= k(InterProcessMutex.java:221) at org.apache.curator.framework.recipes.locks.InterProcessMutex.acquire(Int= erProcessMutex.java:77) }} These operations should fail more gracefully, maybe with dedicated exceptio= n, when connection is lost or changed. > InterProcessReadWriteLock can throw IndexOutOfBoundsException when connec= tion is lost > -------------------------------------------------------------------------= ------------ > > Key: CURATOR-307 > URL: https://issues.apache.org/jira/browse/CURATOR-307 > Project: Apache Curator > Issue Type: Bug > Components: Recipes > Affects Versions: 2.4.0 > Reporter: Jakub Strolen=C3=BD > Priority: Critical > > We are using recipe InterProcessMutex as lock for our cluster environment= . > We found that it is possible that acquiring and/or releasing of lock can = fail when connection to ZooKeeper is lost or changed. > If you have have following sample code: > InterProcessMutex.acquire(); > doSomething(); > InterProcessMutex.release(); > You can get following exception in release() method, when connection is l= ost after lock is acquired. > Stack trace: > {{java.lang.IllegalMonitorStateException: You do not own the lock: /clust= ers/Production/something/lock > at org.apache.curator.framework.recipes.locks.InterProcessMutex.release(I= nterProcessMutex.java:128)}} > and following stack trace when lock directory is empty (because emphemera= l nodes are deleted, because of connection was lost) > {{java.lang.IndexOutOfBoundsException: Index: 2147483647, Size: 0 > at java.util.ArrayList.rangeCheck(ArrayList.java:653) > at java.util.ArrayList.get(ArrayList.java:429) > at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock.r= eadLockPredicate(InterProcessReadWriteLock.java:190) > at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock.a= ccess$0(InterProcessReadWriteLock.java:163) > at org.apache.curator.framework.recipes.locks.InterProcessReadWriteLock$2= .getsTheLock(InterProcessReadWriteLock.java:137) > at org.apache.curator.framework.recipes.locks.LockInternals.internalLockL= oop(LockInternals.java:287) > at org.apache.curator.framework.recipes.locks.LockInternals.attemptLock(L= ockInternals.java:226) > at org.apache.curator.framework.recipes.locks.InterProcessMutex.internalL= ock(InterProcessMutex.java:221) > at org.apache.curator.framework.recipes.locks.InterProcessMutex.acquire(I= nterProcessMutex.java:77)}} > These operations should fail more gracefully, maybe with dedicated except= ion, when connection is lost or changed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)