[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/11/16 3:24 PM:
--------------------------------------------------------------------
BatchManager/Batch:
* goal is to coalesce DistributableCache operations *on the same thread* which happen between an initial get(K id) and a corresponding release(V value)/ discard(V value)
* uses a Batch() instance stored with the SFSB instance to to this; this Batch() is used for resuming the Batch on a thread for an SFSB instance
* problem is only works to coalesce operations on the same thread between get(K id) and release(V value)
* does not work for two or more invocations on different threads wrapped by the same transaction, as BatchManager is not aware that the two threads are wrapped by the same outer transaction
* BatchManager uses ISPN transaction manager and the invocations which access the cache use JBoss transaction manager (call it an external transaction manager for now)
///
* we need to let the BatchManager find out of there is a Batch associated with an enclosing transaction, and if so, install it on the thread, instead of creating a new Batch; we want all operations between get() and release() to use the same batch
///
* possible solution:
** BatchManager(tm, externalTm, externalTxSynchronizationRegistry)
*** keep a reference to the TM (and its SynchronizationRegistry) which may wrap BatchManager activities
*** use this to check:
(i) if we have a current external txn associated with the current thread and
(ii) if yes, if there is a Batch appended to the TransactionSynchronizationRegistry for the current thread
** Batch(count, txn, externalTxn)
*** now keep a reference to any external txn which this Batch needs to be aware of
*** when creating a batch:
**** check if there is a Batch on the current thread
**** if yes, interpose
**** if not, check if there is an external transaction
**** if external transaction, try to get a Batch() attached to the SynchronizationRegistry
- if there is such, use it for the current thread
- if there is not such, create a Batch on the current thread with the external txn and stick it up there
- if not, create a new batch as before ...
*** when resuming a Batch()
**** pretty much as before (?)
*** closing a BatchContext()
**** need to clean up the Batch() attachment on the enclosing transaction when the transaction commits
was (Author: rachmato):
BatchManager/Batch:
- goal is to coalesce DistributableCache operations *on the same thread* which happen between an initial get(K id) and a corresponding release(V value)/ discard(V value)
- uses a Batch() instance stored with the SFSB instance to to this; this Batch() is used for resuming the Batch on a thread for an SFSB instance
- problem is only works to coalesce operations on the same thread between get(K id) and release(V value)
- does not work for two or more invocations on different threads wrapped by the same transaction, as BatchManager is not aware that the two threads are wrapped by the same outer transaction
- BatchManager uses ISPN transaction manager and the invocations which access the cache use JBoss transaction manager (call it an external transaction manager for now)
- we need to let the BatchManager find out of there is a Batch associated with an enclosing transaction, and if so, install it on the thread, instead of creating a new Batch; we want all operations between get() and release() to use the same batch
- possible solution:
- BatchManager(tm, externalTm, externalTxSynchronizationRegistry)
- keep a reference to the TM (and its SynchronizationRegistry) which may wrap BatchManager activities
- use this to check:
(i) if we have a current external txn associated with the current thread and
(ii) if yes, if there is a Batch appended to the TransactionSynchronizationRegistry for the current thread
- Batch(count, txn, externalTxn)
- now keep a reference to any external txn which this Batch needs to be aware of
- when creating a batch:
- check if there is a Batch on the current thread
- if yes, interpose
- if not, check if there is an external transaction
- if external transaction, try to get a Batch() attached to the SynchronizationRegistry
- if there is such, use it for the current thread
- if there is not such, create a Batch on the current thread with the external txn and stick it up there
- if not, create a new batch as before ...
- when resuming a Batch()
- pretty much as before (?)
- closing a BatchContext()
- need to clean up the Batch() attachment on the enclosing transaction when the transaction commits
> 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 commented on WFLY-6498:
-------------------------------------------
BatchManager/Batch:
- goal is to coalesce DistributableCache operations *on the same thread* which happen between an initial get(K id) and a corresponding release(V value)/ discard(V value)
- uses a Batch() instance stored with the SFSB instance to to this; this Batch() is used for resuming the Batch on a thread for an SFSB instance
- problem is only works to coalesce operations on the same thread between get(K id) and release(V value)
- does not work for two or more invocations on different threads wrapped by the same transaction, as BatchManager is not aware that the two threads are wrapped by the same outer transaction
- BatchManager uses ISPN transaction manager and the invocations which access the cache use JBoss transaction manager (call it an external transaction manager for now)
- we need to let the BatchManager find out of there is a Batch associated with an enclosing transaction, and if so, install it on the thread, instead of creating a new Batch; we want all operations between get() and release() to use the same batch
- possible solution:
- BatchManager(tm, externalTm, externalTxSynchronizationRegistry)
- keep a reference to the TM (and its SynchronizationRegistry) which may wrap BatchManager activities
- use this to check:
(i) if we have a current external txn associated with the current thread and
(ii) if yes, if there is a Batch appended to the TransactionSynchronizationRegistry for the current thread
- Batch(count, txn, externalTxn)
- now keep a reference to any external txn which this Batch needs to be aware of
- when creating a batch:
- check if there is a Batch on the current thread
- if yes, interpose
- if not, check if there is an external transaction
- if external transaction, try to get a Batch() attached to the SynchronizationRegistry
- if there is such, use it for the current thread
- if there is not such, create a Batch on the current thread with the external txn and stick it up there
- if not, create a new batch as before ...
- when resuming a Batch()
- pretty much as before (?)
- closing a BatchContext()
- need to clean up the Batch() attachment on the enclosing transaction when the transaction commits
> 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] (DROOLS-1070) FactType object instantiated outside drools no longer match rules in 6.3.0.Final
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1070?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1070.
---------------------------------
Resolution: Rejected
KieBase.getFactType should be used only to retrieve beans defined as declared types and not plain java classes. Indeed trying to reproduce your use case I'm getting this exception https://github.com/droolsjbpm/drools/blob/master/drools-core/src/main/jav... and I'm honestly wondering how you're not getting the same.
That said you can easily achieve this result using the ClassLoader provided by the KieContainer like it follows:
{code}
Object testObject = kieContainer.getClassLoader().loadClass("my.package.MyClass").newInstance();
{code}
> FactType object instantiated outside drools no longer match rules in 6.3.0.Final
> --------------------------------------------------------------------------------
>
> Key: DROOLS-1070
> URL: https://issues.jboss.org/browse/DROOLS-1070
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: Java 8 (1.8.0_72)
> Reporter: Jogchem de Groot
> Assignee: Mario Fusco
>
> There's a problem of regression between the drools 6.2.0.Final and 6.3.0.Final releases:
> In 6.2.0.Final the following was possible:
> - You could create a FactType (for example a Data Object in the workbench) in your knowledge base
> - From your application code, after loading the knowledge base. You could obtain the specific FactType from the knowledge base, get the class and instantiate a new instance of that class, effectively being a new instance of the FactType.
> - This new instance of the FactType could then be inserted into a drools session for the knowledge base and would be succesfully matched by rules that match the FactType as defined in the knowledge base.
> In 6.3.0.Final these rules would no longer be activated as the new FactType instance would be loaded by a different class loader (and thus is a different class) than the FactType class that the rules are trying to match.
> Therefore: in 6.3.0.Final it's no longer possible to define your business objects in your rule base, but have them populated and supplied outside of the rule session (in your application code).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (ELY-493) Support SSL context building for client or server
by David Lloyd (JIRA)
David Lloyd created ELY-493:
-------------------------------
Summary: Support SSL context building for client or server
Key: ELY-493
URL: https://issues.jboss.org/browse/ELY-493
Project: WildFly Elytron
Issue Type: Enhancement
Components: SSL
Reporter: David Lloyd
Assignee: David Lloyd
Fix For: 1.1.0.Beta6
Broaden the SSL context build support in order to support both clients and servers, with appropriate ability to authenticate the peer.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6489) Distributable session may not exist after redirect to same node with optimistic locking.
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6489?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6489:
------------------------------------
[~glavoie] "We previously attempted to disable batching on WildFly 8 without success."
I've fixed this here: https://issues.jboss.org/browse/WFLY-6502
Included in the above fix, session reads will not trigger session replication, for non-tx session caches.
"Attribute replication ... would prove difficult as we would have to track every non-immutable attributes retrieval and force a setAttribute() at the end of the request to force an update on the other nodes, which is done transparently with the transaction enabled."
This isn't specific to attribute replication. So long as you don't have referential integrity constraints across session attributes (e.g. a given object isn't referenced by multiple session attributes), you can use attribute replication without issue.
> Distributable session may not exist after redirect to same node with optimistic locking.
> ----------------------------------------------------------------------------------------
>
> Key: WFLY-6489
> URL: https://issues.jboss.org/browse/WFLY-6489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 8.2.1.Final, 10.0.0.Final, 10.1.0.Final
> Reporter: Gabriel Lavoie
> Assignee: Paul Ferraro
> Priority: Critical
> Attachments: wfly-6489-showcase.zip, wildfly-10-session-issue.zip
>
>
> I'm currently working on porting an application running on EAP 6.1 to WildFly 10 and am encountering multiple session/authentication issues with clustering enabled. Our login flow currently starts from a servlet that accepts the credentials, creates the session, then redirect to the welcome page.
> The first time we execute this flow after the startup of a node, the welcome page can't see at all the session created previously.
> - request.getSession() creates yet another session and a new session cookie is returned.
> - request.getSession(false) returns "null"
> On the second attempt, the flow works as expected.
> The issue can be reproduced on both a single node or a two nodes cluster, as long as <distributable /> is enabled in web.xml.
> We are currently using the master build https://ci.jboss.org/hudson/job/WildFly-latest-master/2244/, but the problem has been noticed on 10.0.0-Final and also 8.2.1-Final.
> I attached a sample web application that I used to reproduce the issue. Our standalone.xml is also included with the clustering configuration we've been using for the web/session cache.
--
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/11/16 9:51 AM:
--------------------------------------------------------------------
[~pferraro]
Is it intended that there are two transaction managers at work here?
13:15:20,213 INFO [stdout] (default task-18) org.jboss.as.ejb3.tx.CMTTxInterceptor: processInvocation: txn manager instance : com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@4ecb8e22
...
13:15:20,229 INFO [stdout] (default task-18) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: current txn manager: org.infinispan.transaction.tm.DummyTransactionManager@7ae5a027
Answer from Paul on IRC:
Paul Ferraro: DummyTransactionManager is just how batching is implemented in Infinispan
Infinispan doesn't use com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate for ejbs
EJBs don't use org.infinispan.transaction.tm.DummyTransactionManager ever
or rather EJBs never use org.infinispan.transaction.tm.DummyTransactionManager
was (Author: rachmato):
[~pferraro]
Is it intended that there are two transaction managers at work here?
13:15:20,213 INFO [stdout] (default task-18) org.jboss.as.ejb3.tx.CMTTxInterceptor: processInvocation: txn manager instance : com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@4ecb8e22
...
13:15:20,229 INFO [stdout] (default task-18) org.wildfly.clustering.ee.infinispan.InfinispanBatcher: current txn manager: org.infinispan.transaction.tm.DummyTransactionManager@7ae5a027
> 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] (DROOLS-1059) Drools can't find rules under stress
by Massinissa BOUZIAD (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1059?page=com.atlassian.jira.plugi... ]
Massinissa BOUZIAD commented on DROOLS-1059:
--------------------------------------------
Work well now. No more error while trying to find queries. In version 7.0.0-SNAPSHOT.
Thank you !
> Drools can't find rules under stress
> ------------------------------------
>
> Key: DROOLS-1059
> URL: https://issues.jboss.org/browse/DROOLS-1059
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 6.4.0.Final, 7.0.0.Final
>
> Attachments: DroolsBugReproducerTest.java, reproducerRule.drl
>
>
> In my knowledge base, I have many rules.
> All of them are working very well in production with drools 6.0.1-FINAL even in stress condition hight trafic (arount 40 hits seconds)
> This bug append when we made an upgrade with drools 6.3.0-FINAL which is compatible with jdk8 mandatory in my case.
> So now when I put my rules under stress test (benchmarking) I got this random error.
> Drools is unable to find a query (not always the same one).
> I got this error for 0,6% of my requests.
> *+Following the stack trace : +*
> Unable to find query 'checkAndBindBasket'
> at org.drools.core.phreak.SegmentUtilities.getQueryLiaNode(SegmentUtilities.java:518) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:208) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SegmentMemory$QueryMemoryPrototype.populateMemory(SegmentMemory.java:505) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SegmentMemory$Prototype.newSegmentMemory(SegmentMemory.java:400) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.KnowledgeBaseImpl.createSegmentFromPrototype(KnowledgeBaseImpl.java:1424) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.restoreSegmentFromPrototype(SegmentUtilities.java:186) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:83) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:167) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260) ~[darty-pricing-ws-2.0.2.jar:2.0.2]
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-3221) flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials
by valsaraj viswanathan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3221?page=com.atlassian.jira.plugin.... ]
valsaraj viswanathan commented on WFLY-3221:
--------------------------------------------
Thanks for sharing. I tried SessionListener fix. It worked for logged in user but during logout I got "javax.ejb.EJBAccessException: JBAS013323: Invalid User" exception because I have SessionAttribute listeners which calls EJB when attributes removed. So when session listener flushes cache, all EJB calls after this gets invalid user. Any work around for this scenario?
(Restricted to jira-users group)
> flushOnSessionInvalidation attribute in jboss-web.xml does not flush user credentials
> -------------------------------------------------------------------------------------
>
> Key: WFLY-3221
> URL: https://issues.jboss.org/browse/WFLY-3221
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.0.0.Final
> Reporter: Jorge Marmolejo
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 9.0.0.Beta1
>
>
> The attribute flushOnSessionInvalidation does not flush the user credentials when the session is invalidated or when it times out. If the password or roles change for the user, the only way to get the new changes is by restarting the server.
> I tried removing "cache-type=default" from the standalone-full.xml and it works, but for every action made on the site, the login method in the authentication module is called.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6509) Some clustering tests cause surefire error "There was a timeout or other error in the fork"
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-6509?page=com.atlassian.jira.plugin.... ]
Marek Kopecký reassigned WFLY-6509:
-----------------------------------
Assignee: Marek Kopecký (was: Paul Ferraro)
> Some clustering tests cause surefire error "There was a timeout or other error in the fork"
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6509
> URL: https://issues.jboss.org/browse/WFLY-6509
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.Final
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> *Description of problem:*
> Some clustering tests fails on pure-IPv6 machines with IBM JDK:
> * org.jboss.as.test.clustering.single.web.SimpleWebTestCase
> * org.jboss.as.test.clustering.single.provider.ServiceProviderRegistrationTestCase
> * org.jboss.as.test.clustering.single.registry.RegistryTestCase
> * org.jboss.as.test.clustering.single.dispatcher.CommandDispatcherTestCase
> * org.jboss.as.test.clustering.single.singleton.SingletonServiceTestCase
> * org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase
> These tests fail intermittently also on other platforms.
> There are also 7 other failing tests, but it's covered by JBEAP-322
> IBM JDK version: IBMJDK 1.8.0 build 20151023_01(SR2)
> IPv6 protocol will be fully supported in EAP 7.
> *How reproducible:*
> Always on pure IPv6 machines and IBM
> *Steps to Reproduce:*
> {noformat}
> export MYTESTIPV6_1_I=`ip -6 -o ad | grep $MYTESTIPV6_1 | awk '{print $2}'`
> export MYTESTIPV6_2_I=`ip -6 -o ad | grep $MYTESTIPV6_2 | awk '{print $2}'`
> ./integration-tests.sh -Dmaven.repo.local=$MAVEN_REPO_LOCAL -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIPV6_1 -Dnode1=$MYTESTIPV6_2 -Dmcast=$MCAST_ADDRV6 -Dipv6 -Djboss.dist=$JBOSS_DIST -DproxySet=true -DproxyHost=proxy-01-ipv6.mw.lab.eng.bos.redhat.com -DproxyPort=3128 -Dhttp.proxyHost=proxy-01-ipv6.mw.lab.eng.bos.redhat.com -Dhttp.proxyPort=3128 -Dhttps.proxyHost=proxy-01-ipv6.mw.lab.eng.bos.redhat.com -Dhttps.proxyPort=3128 -DnonProxyHosts="localhost|localhost.localdomain|[0:0:0:0:0:0:0:1]|127.*|[::0]|[::1]|[$MYTESTIPV6_2]|[$MYTESTIPV6_1]" -Dhttp.nonProxyHosts="localhost|localhost.localdomain|127.*|[::0]|[::1]|[0:0:0:0:0:0:0:1]|[$MYTESTIPV6_2]|[$MYTESTIPV6_1]|[${MYTESTIPV6_1}%${MYTESTIPV6_1_I}]|[${MYTESTIPV6_2}%${MYTESTIPV6_2_I}]" -Dts.noSmoke -Dts.clustering {noformat}
> *Actual results:*
> Logs are attached
> *Expected results:*
> No errors
> *Additional info:*
> Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years