[jboss-jira] [JBoss JIRA] (AS7-4813) Shutdown in REPL SYNC results in TimeoutException: Unable to acquire lock after

[ https://issues.jboss.org/browse/AS7-4813?page=com.atlassian.jira.plugin.s... ] Richard Achmatowicz edited comment on AS7-4813 at 5/15/12 2:45 PM: ------------------------------------------------------------------- A request is initiated by Runner 229 on perf17 which generates a session sgalNLPm8jvqZzLyQjwt4oZ3 which gets assigned jvmRoute perf19. It uses perf19 to process requests until perf19 fails and the jvmRoute is changed to perf18. The server logs show activity at perf18 and perf21: the perf18 exceptions come in groups of three {noformat} ./lastSuccessful/perf18.log:[JBossINF] 11:46:54,112 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ajp-perf18/10.16.90.54:8009-97) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [sgalNLPm8jvqZzLyQjwt4oZ3] for requestor [GlobalTransaction:<perf18/web>:3840:remote]! Lock held by [GlobalTransaction:<perf18/web>:3617:remote] ./lastSuccessful/perf18.log:[JBossINF] 11:46:54,123 ERROR [org.infinispan.transaction.TransactionCoordinator] (ajp-perf18/10.16.90.54:8009-97) Error while processing prepare: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [sgalNLPm8jvqZzLyQjwt4oZ3] for requestor [GlobalTransaction:<perf18/web>:3840:remote]! Lock held by [GlobalTransaction:<perf18/web>:3617:remote] ./lastSuccessful/perf18.log:[JBossINF] 11:46:54,132 ERROR [org.infinispan.transaction.tm.DummyTransaction] (ajp-perf18/10.16.90.54:8009-97) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=3842}, status=1}, lockedKeys=null, backupKeyLocks=[sgalNLPm8jvqZzLyQjwt4oZ3], viewId=7} org.infinispan.transaction.synchronization.SyncLocalTransaction@f00} org.infinispan.transaction.synchronization.SynchronizationAdapter@f1f: org.infinispan.CacheException: Could not prepare. {noformat} representing an incoming prepare request to the assigned slave; the perf21 exceptions {noformat} ./lastSuccessful/perf21.log:[JBossINF] 11:46:54,106 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-1720,null) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [sgalNLPm8jvqZzLyQjwt4oZ3] for requestor [GlobalTransaction:<perf18/web>:3840:remote]! Lock held by [GlobalTransaction:<perf18/web>:3617:remote] {noformat} are the corresponding remote prepare commands which are sent to all hosts participating in the prepare and which fail only on perf21. Those exceptions are then returned to perf18 and show up there. These coupled pairs of exceptions occur every 19 (= 4 + 15) seconds where the client sends out requests every 4 seconds regularly, and the timeout on waiting for the locks is 15 seconds. Each coupled pair of exceptions represents a different incoming retry request by the client to do complete the HTTP request. These exceptions only arise after perf19 fails and they disappear when perf19 comes back. Is it possible that perf21 was a remote participant in a transaction initiated on perf19 (before failure) and perf19 (the coordinator for the prepare) was shutdown during the prepare phase for a transaction involving the session in question. So perf21 ended up with locks on the session which let's assume were never released, in a different cache view. Then perf18 becomes the new jvmRoute for the session, and, in a new cache view, tries to prepare a transaction using the same session id. When it coordinates its prepare phase, the remote command goes out to perf21 which tries to take locks for that session locally and it times out waiting for the locks. The way locks are taken on remote nodes as in AbstractLockingTxInterceptor.lockKeyAndCheckOwnership() is to: - check if there any pending locks for that session id (i.e. locks on transactions from previous cache views which are pending - have not completed) - if there are pending locks, wait for them to complete The exceptions in this issue are occurring when we try to wait for locks for pending transactions (in earlier cache views) and we never get them time (in 15 seconds). So it may be that there are stale entries in the transaction tables. was (Author: rachmato): A request is initiated by Runner 229 on perf17 which generates a session sgalNLPm8jvqZzLyQjwt4oZ3 which gets assigned jvmRoute perf19. It uses perf19 to process requests until perf19 fails and the jvmRoute is changed to perf18. The server logs show activity at perf18 and perf21: the perf18 exceptions come in groups of three {noformat} ./lastSuccessful/perf18.log:[JBossINF] 11:46:54,112 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (ajp-perf18/10.16.90.54:8009-97) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [sgalNLPm8jvqZzLyQjwt4oZ3] for requestor [GlobalTransaction:<perf18/web>:3840:remote]! Lock held by [GlobalTransaction:<perf18/web>:3617:remote] ./lastSuccessful/perf18.log:[JBossINF] 11:46:54,123 ERROR [org.infinispan.transaction.TransactionCoordinator] (ajp-perf18/10.16.90.54:8009-97) Error while processing prepare: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [sgalNLPm8jvqZzLyQjwt4oZ3] for requestor [GlobalTransaction:<perf18/web>:3840:remote]! Lock held by [GlobalTransaction:<perf18/web>:3617:remote] ./lastSuccessful/perf18.log:[JBossINF] 11:46:54,132 ERROR [org.infinispan.transaction.tm.DummyTransaction] (ajp-perf18/10.16.90.54:8009-97) ISPN000109: beforeCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, transaction=DummyTransaction{xid=DummyXid{id=3842}, status=1}, lockedKeys=null, backupKeyLocks=[sgalNLPm8jvqZzLyQjwt4oZ3], viewId=7} org.infinispan.transaction.synchronization.SyncLocalTransaction@f00} org.infinispan.transaction.synchronization.SynchronizationAdapter@f1f: org.infinispan.CacheException: Could not prepare. {noformat} representing an incoming prepare request to the assigned slave; the perf21 exceptions {noformat} ./lastSuccessful/perf21.log:[JBossINF] 11:46:54,106 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (OOB-1720,null) ISPN000136: Execution error: org.infinispan.util.concurrent.TimeoutException: Unable to acquire lock after [15 seconds] on key [sgalNLPm8jvqZzLyQjwt4oZ3] for requestor [GlobalTransaction:<perf18/web>:3840:remote]! Lock held by [GlobalTransaction:<perf18/web>:3617:remote] {noformat} are the corresponding remote prepare commands which are sent to all hosts participating in the prepare and which fail only on perf21. Those exceptions are then returned to perf18 and show up there. These coupled pairs of exceptions occur every 19 (= 4 + 15) seconds where the client sends out requests every 4 seconds regularly, and the timeout on waiting for the locks is 15 seconds. Each coupled pair of exceptions represents a different incoming retry request by the client to do complete the HTTP request. These exceptions only arise after perf19 fails and they disappear when perf19 comes back. Is it possible that perf21 was a remote participant in a transaction initiated on perf19 (before failure) and perf19 (the coordinator for the prepare) was shutdown during the prepare phase for a transaction involving the session in question. So perf21 ended up with locks on the session which let's assume were never released, in a different cache view. Then perf18 becomes the new jvmRoute for the session, and tries to prepare a transaction using the same session id. When it coordinates its prepare phase, the remote command goes out to perf21 which tries to take locks for that session locally and it times out waiting for the locks. The way locks are taken on remote nodes as in AbstractLockingTxInterceptor.lockKeyAndCheckOwnership() is to: - check if there any pending locks for that session id (i.e. locks on transactions from previous cache views which are pending - have not completed) - if there are pending locks, wait for them to complete The exceptions in this issue are occurring when we try to wait for locks for pending transactions (in earlier cache views) and we never get them time (in 15 seconds). So it may be that there are stale entries in the transaction tables. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira