[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6498 at 4/8/16 10:45 AM:
--------------------------------------------------------------------
{noformat}
// first invocation
//
// invocation *has* an associated UserTransaction id
//
09:54:16,018 INFO [stdout] (default task-60) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: Invocation has transaction id: UserTransactionID [484948545469547054525453506851487055664853664969]
//
// create a Transaction corresonding to this transaction id in the RemoteTransactionRepository
//
09:54:16,018 INFO [stdout] (default task-60) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: creating transaction
//
// use the caller's transaction
//
09:54:16,019 INFO [stdout] (default task-60) org.jboss.as.ejb3.tx.CMTTxInterceptor: got transaction from txn manager: status = 0
//
// get the SFSB instance
//
09:54:16,019 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor: looking for stateful component instance wih session id: UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]
09:54:16,019 INFO [stdout] (default task-60) org.jboss.as.ejb3.cache.distributable.DistributableCache: get(UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]) - start
//
// create a Batch associated with the get() command *on this specific thread*; this creates a new txn associated with the Batch
//
09:54:16,019 INFO [stdout] (default task-60) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: entering createBatch()
09:54:16,019 INFO [stdout] (default task-60) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: no current batch exists: creating new batch
09:54:16,019 INFO [stdout] (default task-60) org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager: locating bean UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.cache.distributable.DistributableCache: get() - end
//
// got the SFSB instance and saved the Batch in the instance - this is before the invocation gets processed
//
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor: invoking instance instance wih session id: UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]
//
// lock the SFSB instance and set up the Synchronization to call release when finished with the SFSB instance
//
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: lock owner (based on active txn or thread) = 0:ffffc0a80067:-1ae21b0:5707b7eb:67
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: trying to acquire lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3ddff7c8[Unlocked] for stateful component instance: Instance of StatefulIncrementorBean {UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]} during invocation: org.jboss.invocation.InterceptorContext@5489a92c
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: acquired lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@3ddff7c8[Locked by 0:ffffc0a80067:-1ae21b0:5707b7eb:67] for stateful component instance: Instance of StatefulIncrementorBean {UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]} during invocation: org.jboss.invocation.InterceptorContext@5489a92c
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: using container managed txns - check if we need to register sync
09:54:16,020 INFO [stdout] (default task-60) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: registered tx synchronization: org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization@8c37e77 for tx: 0:ffffc0a80067:-1ae21b0:5707b7eb:67 associated with stateful component instance: Instance of StatefulIncrementorBean {UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]}
//
// peform the invocation ...
//
//
// NOTE: release is not called (the UserTransaction has not completed, so release is not called), the Batch() is not completed
//
// second invocation
//
// invocation *has* an associated UserTransaction id
//
09:54:16,032 INFO [stdout] (default task-61) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: Invocation has transaction id: UserTransactionID [484948545469547054525453506851487055664853664969]
//
// resume the Transaction corresonding to this transaction id in the RemoteTransactionRepository
//
09:54:16,032 INFO [stdout] (default task-61) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: resuming transaction
//
// use the caller's transaction
//
09:54:16,036 INFO [stdout] (default task-61) org.jboss.as.ejb3.tx.CMTTxInterceptor: got transaction from txn manager: status = 0
09:54:16,036 INFO [stdout] (default task-61) org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor: looking for stateful component instance wih session id: UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]
//
// get the SFSB instance
//
09:54:16,036 INFO [stdout] (default task-61) org.jboss.as.ejb3.cache.distributable.DistributableCache: get(UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]) - start
//
// create a *new* Batch associated with the get() command *on this new thread*; this creates a new txn (with new lock owner) associated with the Batch
//
09:54:16,036 INFO [stdout] (default task-61) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: entering createBatch()
09:54:16,036 INFO [stdout] (default task-61) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: no current batch exists: creating new batch
09:54:16,037 INFO [stdout] (default task-61) org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager: locating bean UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457]
//
// the get() command cannot locate the SFSB instance in the cache as it is already held by the previous Batch/transaction (not on the same thread)
//
09:54:31,038 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-61) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [5448506569506551655457515248655466554968515550655657705668505457] and requestor GlobalTransaction:<node-0>:104:local. Lock is held by GlobalTransaction:<node-0>:102:local
at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:125)
at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:257)
{noformat}
was (Author: rachmato):
{noformat}
First invocation in userTransaction1 on target node-0
11:16:07,558 INFO [stdout] (default task-56) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: Invocation has transaction id: UserTransactionID [484948545469547054525453506851486850526669535566]
//
// UserTransaction defined, create a txn on the server
//
11:16:07,560 INFO [stdout] (default task-56) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: creating transaction
11:16:07,562 INFO [stdout] (default task-56) org.jboss.as.ejb3.tx.CMTTxInterceptor: got transaction from txn manager: status = 0
11:16:07,562 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor: looking for stateful component instance wih session id: UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]
11:16:07,562 INFO [stdout] (default task-56) org.jboss.as.ejb3.cache.distributable.DistributableCache: get(UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]) - start
11:16:07,562 INFO [stdout] (default task-56) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: entering createBatch()
11:16:07,562 INFO [stdout] (default task-56) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: no current batch exists: creating new batch
11:16:07,563 INFO [stdout] (default task-56) org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager: locating bean UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]
11:16:07,564 INFO [stdout] (default task-56) org.jboss.as.ejb3.cache.distributable.DistributableCache: get() - end
11:16:07,564 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor: invoking instance instance wih session id: UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]
11:16:07,564 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: lock owner (based on active txn or thread) = 0:ffffc0a80067:-55fecb13:570527e9:d9
11:16:07,564 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: trying to acquire lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@2345f95e[Unlocked] for stateful component instance: Instance of StatefulIncrementorBean {UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]} during invocation: org.jboss.invocation.InterceptorContext@6e12e314
11:16:07,565 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: acquired lock: org.jboss.as.ejb3.tx.OwnableReentrantLock@2345f95e[Locked by 0:ffffc0a80067:-55fecb13:570527e9:d9] for stateful component instance: Instance of StatefulIncrementorBean {UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]} during invocation: org.jboss.invocation.InterceptorContext@6e12e314
11:16:07,565 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: using container managed txns - check if we need to register sync
11:16:07,565 INFO [stdout] (default task-56) org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor: registered tx synchronization: org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor$StatefulSessionSynchronization@1a7a265f for tx: 0:ffffc0a80067:-55fecb13:570527e9:d9 associated with stateful component instance: Instance of StatefulIncrementorBean {UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]}
//
// register a synchronization for the UserTransaction (to call release)
//
11:16:07,565 INFO [stdout] (default task-56) org.jboss.as.ejb3.cache.distributable.DistributableCache: getWeakAffinity() - start
11:16:07,565 INFO [stdout] (default task-56) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: entering createBatch()
11:16:07,565 INFO [stdout] (default task-56) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: current batch exists: interposing
11:16:07,565 INFO [stdout] (default task-56) org.wildfly.clustering.ee.infinispan.InfinispanBatch: interposing batch: count = 1
11:16:07,566 INFO [stdout] (default task-56) org.jboss.as.ejb3.cache.distributable.DistributableCache: getWeakAffinity() - end
11:16:07,566 INFO [stdout] (default task-56) org.wildfly.clustering.ee.infinispan.InfinispanBatch: closing batch - count = 1
--------------------------------------------------------------
Second invocation in userTransaction1 on target node-0
11:16:07,573 INFO [stdout] (default task-57) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: Invocation has transaction id: UserTransactionID [484948545469547054525453506851486850526669535566]
//
// UserTransaction defined, resume the txn on the server
//
11:16:07,573 INFO [stdout] (default task-57) org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor: resuming transaction
11:16:07,577 INFO [stdout] (default task-57) org.jboss.as.ejb3.tx.CMTTxInterceptor: got transaction from txn manager: status = 0
11:16:07,578 INFO [stdout] (default task-57) org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor: looking for stateful component instance wih session id: UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]
11:16:07,578 INFO [stdout] (default task-57) org.jboss.as.ejb3.cache.distributable.DistributableCache: get(UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]) - start
11:16:07,578 INFO [stdout] (default task-57) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: entering createBatch()
11:16:07,578 INFO [stdout] (default task-57) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: no current batch exists: creating new batch
11:16:07,578 INFO [stdout] (default task-57) org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager: locating bean UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166]
11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction:<node-0>:120:local. Lock is held by GlobalTransaction:<node-0>:118:local
at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124)
at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333)
at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
{noformat}
> EJBClient UserTransactions with multiple method invocations generate lock conflicts
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6498
> URL: https://issues.jboss.org/browse/WFLY-6498
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> Using the EJBClient library, we should be able to do the following from a standalone EJBClient application:
> // create a UserTransaction associated with a clustered server node X
> // make an invocation on an EJB on X
> // make an invocation on an EJB on X
> // commit the UserTransaction
> However, doing so results in this exception which occurs during processing of the second invocation:
> {noformat}
> [0m[31m11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction:<node-0>:120:local. Lock is held by GlobalTransaction:<node-0>:118:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> {noformat}
> The exception does not arise if we perform only one invocation within the UserTransaction.
> This exception is repeatable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6498) EJBClient UserTransactions with multiple method invocations generate lock conflicts
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-6498?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-6498 at 4/8/16 10:44 AM:
--------------------------------------------------------------------
The problem here involves Batcher and Batch processing carried out by DistributableCache.
It also involves the order and timing in which get() and release() are called when accessing a SFSB instance during invocation processing.
The calling of release() after an invocation has completed is set up by the EJB interceptor StatefulSessionSynchronizationInterceptor.
If we *do not* enclose method invocations within a user transaction, here is roughly what happens:
// method invocation arrives at server with no UserTransaction id
// no user transaction is created in RemoteTransactionRepository (EJBRemoteTransactionPropagatingInterceptor)
// new txn is created to wrap the method invocation (CMTTxInterceptor)
// get() is used to get the SFSB instance (StatefulComponentInstanceInterceptor)
// Batch is opened on invocation thread with new txn
// Batch is stored with bean instance
// txn synchronization is set up to call release() on txn completion (StatefulSessionSynchronizationInterceptor)
// method executes
// txn commits (CMTTxInterceptor)
// txn synchronization gets called and calls release()
// Batch associated with SFSB instance is resumed, then closed, which causes Batch txn to commit
If we *do* enclose method invocations within a user transaction, here is roughly what happens:
// first method invocation arrives at server with UserTransaction id
// user txn is created in RemoteTransactionRepository (EJBRemoteTransactionPropagatingInterceptor)
// caller's txn is used to wrap the method invocation (CMTTxInterceptor)
// get() is used to get the SFSB instance (StatefulComponentInstanceInterceptor)
// Batch is opened on invocation thread with new txn
// Batch is stored with bean instance
// txn synchronization is set up to call release() on txn completion (StatefulSessionSynchronizationInterceptor)
// method executes
// second method invocation arrives at server with UserTransaction id
// user txn is resumed in RemoteTransactionRepository (EJBRemoteTransactionPropagatingInterceptor)
// caller's txn is used to wrap the method invocation (CMTTxInterceptor)
// get() is used to get the SFSB instance (StatefulComponentInstanceInterceptor)
// Batch is opened on invocation thread with new txn - because the new invocation is run on a different thread and the Batch is not aware of the UserTransaction - instead of creating a new Batch() we should really interpose
// BANG: lock conflict between the two Batches as the first Batch/transaction is still uncommitted, has a different lockOwner and they are trying to access the same SFSB instance
This is a rough description; i'll include a stack trace in a following comment to illustrate details.
was (Author: rachmato):
The problem here involves Batcher and Batch processing carried out by DistributableCache.
It also involves the order and timing in which get() and release() are called when accessing a SFSB instance during invocation processing.
The calling of release() after an invocation has completed is set up by the EJB interceptor StatefulSessionSynchronizationInterceptor.
If we *do not* enclose method invocations within a user transaction, here is roughly what happens:
// method invocation arrives
// txn is created to wrap the method invocation (EJBRemoteTransactionPropagatingInterceptor, CMTTxInterceptor)
// txn synchronization is set up to call release() on txn completion (StatefulSessionSynchronizationInterceptor)
// method executes (this involves cache operations on the SFSB instance which take locks)
// Batch is opened
// txn commits (CMTTxInterceptor)
// txn synchronization gets called and calls release()
// Batch is closed
If we *do* enclose method invocations within a user transaction, here is roughly what happens:
// first method invocation arrives
// user txn is created to wrap the method invocation(s)
// txn synchronization is set up to call release() on txn completion
// method executes (this involves cache operations on the SFSB instance which take locks)
// Batch is opened
// txn is suspended
// Batch close does not trigger commit
// second method invocation arrives
// user txn is resumed to wrap the method invocation(s)
// method executes (this involves cache operations on the SFSB instance which take locks)
// new Batch is opened
// BANG: lock conflict as no one has yet called release()
This is a rough description; i'll include a track trace in a following comment to illustrate details.
> EJBClient UserTransactions with multiple method invocations generate lock conflicts
> ------------------------------------------------------------------------------------
>
> Key: WFLY-6498
> URL: https://issues.jboss.org/browse/WFLY-6498
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Richard Achmatowicz
> Assignee: Paul Ferraro
> Fix For: 11.0.0.Alpha1
>
>
> Using the EJBClient library, we should be able to do the following from a standalone EJBClient application:
> // create a UserTransaction associated with a clustered server node X
> // make an invocation on an EJB on X
> // make an invocation on an EJB on X
> // commit the UserTransaction
> However, doing so results in this exception which occurs during processing of the second invocation:
> {noformat}
> [0m[31m11:16:22,580 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-57) ISPN000136: Error executing command GetKeyValueCommand, writing keys []: org.infinispan.util.concurrent.TimeoutException: ISPN000299: Unable to acquire lock after 15 seconds for key UnknownSessionID [4967684957516649565452525270575756545166695455535750486549485166] and requestor GlobalTransaction:<node-0>:120:local. Lock is held by GlobalTransaction:<node-0>:118:local
> at org.infinispan.util.concurrent.locks.impl.DefaultLockManager$KeyAwareExtendedLockPromise.lock(DefaultLockManager.java:236)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.lockAndRecord(AbstractLockingInterceptor.java:190)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.checkPendingAndLockKey(AbstractTxLockingInterceptor.java:192)
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.lockOrRegisterBackupLock(AbstractTxLockingInterceptor.java:113)
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitDataReadCommand(PessimisticLockingInterceptor.java:70)
> at org.infinispan.interceptors.locking.AbstractLockingInterceptor.visitGetKeyValueCommand(AbstractLockingInterceptor.java:77)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:330)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:176)
> at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:153)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:107)
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:76)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:40)
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:336)
> at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> at org.infinispan.cache.impl.DecoratedCache.get(DecoratedCache.java:443)
> at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:87)
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanFactory.findValue(InfinispanBeanFactory.java:49)
> at org.wildfly.clustering.ejb.infinispan.InfinispanBeanManager.findBean(InfinispanBeanManager.java:244)
> at org.jboss.as.ejb3.cache.distributable.DistributableCache.get(DistributableCache.java:124)
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:59)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:333)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> {noformat}
> The exception does not arise if we perform only one invocation within the UserTransaction.
> This exception is repeatable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-492) Add a generic HttpScope implementation with Builder
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-492:
------------------------------------
Summary: Add a generic HttpScope implementation with Builder
Key: ELY-492
URL: https://issues.jboss.org/browse/ELY-492
Project: WildFly Elytron
Issue Type: Feature Request
Components: HTTP
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 1.1.0.Beta6
The HttpScope implementations can easily be built using functions, this task is to provide a generic implementation that can be built from a set of functions.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ]
Chen Maoqian updated WFLY-6083:
-------------------------------
Description: In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. (was: _emphasized text_In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.)
> Removing of non-existent login-module finishes with outcome success
> -------------------------------------------------------------------
>
> Key: WFLY-6083
> URL: https://issues.jboss.org/browse/WFLY-6083
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Minor
>
> In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6083) Removing of non-existent login-module finishes with outcome success
by Chen Maoqian (JIRA)
[ https://issues.jboss.org/browse/WFLY-6083?page=com.atlassian.jira.plugin.... ]
Chen Maoqian updated WFLY-6083:
-------------------------------
Description: _emphasized text_In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command. (was: In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.)
> Removing of non-existent login-module finishes with outcome success
> -------------------------------------------------------------------
>
> Key: WFLY-6083
> URL: https://issues.jboss.org/browse/WFLY-6083
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 10.0.0.Final
> Reporter: Ondrej Lukas
> Assignee: Brian Stansberry
> Priority: Minor
>
> _emphasized text_In case when non-existent login-module is removed through Management CLI, opertation should finish with failure. However it finishes with outcome success and nothing is changed. It can be confusing since wrong command seems same as correct command.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6504) [Migration operation] wrong resource address in migration warning
by Miroslav Novak (JIRA)
[ https://issues.jboss.org/browse/WFLY-6504?page=com.atlassian.jira.plugin.... ]
Miroslav Novak commented on WFLY-6504:
--------------------------------------
Yes, the word "from" is misleading. Let's see how we unify on JBEAP-4116.
> [Migration operation] wrong resource address in migration warning
> -----------------------------------------------------------------
>
> Key: WFLY-6504
> URL: https://issues.jboss.org/browse/WFLY-6504
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Say I take EAP 6.4 default {{standalone-full.xml}} and add a discovery group like this:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:messaging:1.4">
> <hornetq-server>
> ...
> <discovery-groups>
> <discovery-group name="my-discovery-group">
> <group-address>224.0.1.105</group-address>
> <group-port>56789</group-port>
> </discovery-group>
> </discovery-groups>
> ...
> </hornetq-server>
> </subsystem>
> {code}
> This is the only change I make to the configuration file. Then I try to migrate the {{messaging}} subsystem, expecting a migration warning that I should use the {{socket-binding}} attribute.
> The warning appears indeed:
> {code}
> [standalone@localhost:9999 /] /subsystem=messaging:migrate
> {
> "outcome" => "success",
> "result" => {"migration-warnings" => [
> "WFLYMSG0084: Can not migrate attribute group-address from resource [
> (\"subsystem\" => \"messaging-activemq\"),
> (\"server\" => \"default\"),
> (\"discovery-group\" => \"my-discovery-group\")
> ]. Use instead the socket-binding attribute to configure this discovery-group.",
> "WFLYMSG0084: Can not migrate attribute group-port from resource [
> (\"subsystem\" => \"messaging-activemq\"),
> (\"server\" => \"default\"),
> (\"discovery-group\" => \"my-discovery-group\")
> ]. Use instead the socket-binding attribute to configure this discovery-group."
> ]}
> }
> {code}
> But the resource addresses in the warning are wrong. They refer to the {{messaging-activemq}} subsystem, which clearly isn't what I'm migrating _from_, it's what I'm migrating _to_.
> I understand from the code that the DMR structure of the old subsystem model is very close to the structure of the new subsystem model, which is why these warning are produced on an already translated structure, but it generates wrong warnings.
> CC [~mnovak].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6504) [Migration operation] wrong resource address in migration warning
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-6504?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil moved JBEAP-4130 to WFLY-6504:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6504 (was: JBEAP-4130)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: JMS
(was: Domain Management)
(was: JMS)
(was: Migration)
Target Release: (was: 7.backlog.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER7)
> [Migration operation] wrong resource address in migration warning
> -----------------------------------------------------------------
>
> Key: WFLY-6504
> URL: https://issues.jboss.org/browse/WFLY-6504
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
>
> Say I take EAP 6.4 default {{standalone-full.xml}} and add a discovery group like this:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:messaging:1.4">
> <hornetq-server>
> ...
> <discovery-groups>
> <discovery-group name="my-discovery-group">
> <group-address>224.0.1.105</group-address>
> <group-port>56789</group-port>
> </discovery-group>
> </discovery-groups>
> ...
> </hornetq-server>
> </subsystem>
> {code}
> This is the only change I make to the configuration file. Then I try to migrate the {{messaging}} subsystem, expecting a migration warning that I should use the {{socket-binding}} attribute.
> The warning appears indeed:
> {code}
> [standalone@localhost:9999 /] /subsystem=messaging:migrate
> {
> "outcome" => "success",
> "result" => {"migration-warnings" => [
> "WFLYMSG0084: Can not migrate attribute group-address from resource [
> (\"subsystem\" => \"messaging-activemq\"),
> (\"server\" => \"default\"),
> (\"discovery-group\" => \"my-discovery-group\")
> ]. Use instead the socket-binding attribute to configure this discovery-group.",
> "WFLYMSG0084: Can not migrate attribute group-port from resource [
> (\"subsystem\" => \"messaging-activemq\"),
> (\"server\" => \"default\"),
> (\"discovery-group\" => \"my-discovery-group\")
> ]. Use instead the socket-binding attribute to configure this discovery-group."
> ]}
> }
> {code}
> But the resource addresses in the warning are wrong. They refer to the {{messaging-activemq}} subsystem, which clearly isn't what I'm migrating _from_, it's what I'm migrating _to_.
> I understand from the code that the DMR structure of the old subsystem model is very close to the structure of the new subsystem model, which is why these warning are produced on an already translated structure, but it generates wrong warnings.
> CC [~mnovak].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1116) After adding new Rule by different drl filename getting error while calling fireRules
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1116?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1116:
-------------------------------------
Sorry, but it's impossible to reproduce this problem using your description. Where are the rules to be used? And the objects to be inserted into the session? Please attach a complete test case reproducing this problem or even better send a pull request with it.
> After adding new Rule by different drl filename getting error while calling fireRules
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1116
> URL: https://issues.jboss.org/browse/DROOLS-1116
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Vivek Singh
> Assignee: Mario Fusco
>
> Issue is similar to https://issues.jboss.org/browse/DROOLS-978
> But its showing its fixed in 6.4.0.Beta1 but i am still lfacing in 6.4.0.CR2
> While Adding the new or Updated Rules by createKieJar.
> Even renaming the Drool file.
> After that while calling the fireRules i am getting the below error:-
> Exception in thread "main" java.lang.NullPointerException
> at org.drools.core.reteoo.NodeTypeEnums.isBetaNode(NodeTypeEnums.java:88)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:254)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123)
> at org.drools.core.phreak.RuleExecutor.evaluateNetwork(RuleExecutor.java:65)
> at org.drools.core.common.DefaultAgenda.evaluateEagerList(DefaultAgenda.java:1004)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:961)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1117) After 2 times loading the same Rule 3rd time its not loading, Even No error occured
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1117?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1117:
-------------------------------------
Sorry, but it's impossible to reproduce this problem using your description. Where are the rules to be used? And the objects to be inserted into the session? Please attach a complete test case reproducing this problem or even better send a pull request with it.
> After 2 times loading the same Rule 3rd time its not loading, Even No error occured
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1117
> URL: https://issues.jboss.org/browse/DROOLS-1117
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Vivek Singh
> Assignee: Mario Fusco
>
> While Loading the Rules in Server, After that i removed the Rule from KieBase then again
> added the Rule By creating the newJar with different ReleaseId but same Drl filename.
> Then i again removed the rule from KieBase using same command
> kieBase.removeRule(kiePackage.getName(), ruleName);
> But after that when i again added the same Rule it will not adding into the KieBase Knowledge packages. Even i am not getting any error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1117) After 2 times loading the same Rule 3rd time its not loading, Even No error occured
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1117?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1117:
-----------------------------------
Assignee: Mario Fusco (was: Edson Tirelli)
> After 2 times loading the same Rule 3rd time its not loading, Even No error occured
> -----------------------------------------------------------------------------------
>
> Key: DROOLS-1117
> URL: https://issues.jboss.org/browse/DROOLS-1117
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Vivek Singh
> Assignee: Mario Fusco
>
> While Loading the Rules in Server, After that i removed the Rule from KieBase then again
> added the Rule By creating the newJar with different ReleaseId but same Drl filename.
> Then i again removed the rule from KieBase using same command
> kieBase.removeRule(kiePackage.getName(), ruleName);
> But after that when i again added the same Rule it will not adding into the KieBase Knowledge packages. Even i am not getting any error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years