[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 7/6/16 4:33 PM:
-------------------------------------------------------------------
Had another look at this issue of the user transaction based test case failing.
The test case involves two EJB client invocations on a SFSB, all wrapped in an EJB client user transaction; something like this:
{noformat}
// begin txn
// invoke on SFSB
// invoke on SFSB
// commit txn
{noformat}
The problem is that because the first invocation is in the scope of a user transaction, the StatefulSessionSynchronizationInterceptor will register a synchronization to call release() at commit time. Not so for the second invocation as the StatefulSessionSynchronizationInterceptor knows that a synchronization has already been registered for the transaction. So the sequence of calls to get() and release() look like this:
{noformat}
// begin txn
// invoke on SFSB
// get()
// invoke on SFSB
// get()
// release()
// commit
// release()
{noformat}
Because the call to release() will by default remove any Batch associated with the SFSB instance (via value.removeCacheContext()), the Batch associated with the SFSB will be removed by the second invocation before the call to release() in the commit. This causes locks to be held by the uncommitted batch, and this causes exceptions in the second part of the test case which operates on the same SFSB. Also, at commit time, the TSR properties can no longer be accessed, as after completion, the transaction is no longer active.
So I changed release() to check if the tsr shows a transaction active:
- if a transaction is active, don't remove the batch from the session instance, leave it there as it will be needed in a sync
- otherwise, remove as usual
This fixes the case where we have two invocations on the same bean and the test case passes.
However, if we have two invocations each on a different bean, this will not work, it seems. Have to rethink things.
was (Author: rachmato):
Had another look at this issue of the user transaction based test case failing.
The test case involves two EJB client invocations on a SFSB, all wrapped in an EJB client user transaction; something like this:
// begin txn
// invoke on SFSB
// invoke on SFSB
// commit txn
The problem is that because the first invocation is in the scope of a user transaction, the StatefulSessionSynchronizationInterceptor will register a synchronization to call release() at commit time. Not so for the second invocation as the StatefulSessionSynchronizationInterceptor knows that a synchronization has already been registered for the transaction. So the sequence of calls to get() and release() look like this:
// begin txn
// invoke on SFSB
// get()
// invoke on SFSB
// get()
// release()
// commit
// release()
Because the call to release() will by default remove any Batch associated with the SFSB instance (via value.removeCacheContext()), the Batch associated with the SFSB will be removed by the second invocation before the call to release() in the commit. This causes locks to be held by the uncommitted batch, and this causes exceptions in the second part of the test case which operates on the same SFSB.
Also, at commit time, the TSR properties can no longer be accessed, as after completion, the transaction is no longer active.
So I changed release() to check if the tsr shows a transaction active:
- if a transaction is active, don't remove the batch from the session instance, leave it there as it will be needed in a sync
- otherwise, remove as usual
This fixes the case where we have two invocations on the same bean and the test case passes.
However, if we have two invocations each on a different bean, this will not work, it seems. Have to rethink things.
> 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)
8 years, 6 months
[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:
-------------------------------------------
Had another look at this issue of the user transaction based test case failing.
The test case involves two EJB client invocations on a SFSB, all wrapped in an EJB client user transaction; something like this:
// begin txn
// invoke on SFSB
// invoke on SFSB
// commit txn
The problem is that because the first invocation is in the scope of a user transaction, the StatefulSessionSynchronizationInterceptor will register a synchronization to call release() at commit time. Not so for the second invocation as the StatefulSessionSynchronizationInterceptor knows that a synchronization has already been registered for the transaction. So the sequence of calls to get() and release() look like this:
// begin txn
// invoke on SFSB
// get()
// invoke on SFSB
// get()
// release()
// commit
// release()
Because the call to release() will by default remove any Batch associated with the SFSB instance (via value.removeCacheContext()), the Batch associated with the SFSB will be removed by the second invocation before the call to release() in the commit. This causes locks to be held by the uncommitted batch, and this causes exceptions in the second part of the test case which operates on the same SFSB.
Also, at commit time, the TSR properties can no longer be accessed, as after completion, the transaction is no longer active.
So I changed release() to check if the tsr shows a transaction active:
- if a transaction is active, don't remove the batch from the session instance, leave it there as it will be needed in a sync
- otherwise, remove as usual
This fixes the case where we have two invocations on the same bean and the test case passes.
However, if we have two invocations each on a different bean, this will not work, it seems. Have to rethink things.
> 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)
8 years, 6 months
[JBoss JIRA] (WFCORE-1541) ModelControllerClientConfiguration.Builder should provide better control over the executor
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1541?page=com.atlassian.jira.plugi... ]
Brian Stansberry reopened WFCORE-1541:
--------------------------------------
Reopening as this looks to have been a bad idea. We probably don't want the user configuring this stuff.
> ModelControllerClientConfiguration.Builder should provide better control over the executor
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-1541
> URL: https://issues.jboss.org/browse/WFCORE-1541
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 2.2.0.CR1, 3.0.0.Alpha1
>
>
> The ModelControllerClientConfiguration provides an ExecutorService but the builder does not provide a way to set it. And then the impl has a field to toggle whether the executor is shut down by the close() method, but there is no way to set that field. It always ends up 'true'.
> Proposal:
> 1) Add setters to the builder for both the executor and the shutdown field.
> 2) Default for the shutdown field depends on whether the executor got set. If the user passes in an executor, then we assume they control its lifecycle. If they don't and the standard one gets used, then closing the config should close the executor. And if the user doesn't like those defaults they can set the flag themselves.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFCORE-1637) headers in Operation and Command are not properly completed
by Jean-Francois Denise (JIRA)
Jean-Francois Denise created WFCORE-1637:
--------------------------------------------
Summary: headers in Operation and Command are not properly completed
Key: WFCORE-1637
URL: https://issues.jboss.org/browse/WFCORE-1637
Project: WildFly Core
Issue Type: Bug
Components: CLI
Reporter: Jean-Francois Denise
Assignee: Alexey Loubyansky
For example:
1) ls --headers {allow-resource-service-restart <TAB>
doesn't give you the '='
2) ls --headers {allow-resource-service-restart=true; <TAB>
list you the commands one can type...not at al an header.
Completion should properly complete each header.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6405) Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6405?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6405:
-------------------------------------
I've added a follow up PR, https://github.com/wildfly/wildfly/pull/9021, as {{ConcurrentHashMap}}'s don't allow null keys. {{Class.getClassLoader()}} may return {{null}} if the class was loaded on the bootstrap class loader. e.g. {{java.lang.Integer}}.
> Performance: WeldDeployment.getBeanDeploymentArchive method is synchronized
> ---------------------------------------------------------------------------
>
> Key: WFLY-6405
> URL: https://issues.jboss.org/browse/WFLY-6405
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Class Loading
> Affects Versions: 10.0.0.Final
> Reporter: Panos Grigoropoulos
> Assignee: Stuart Douglas
>
> (Wildfly 10.0.0.FINAL)
> During the performance test of my app (50 concurrent users with jmeter) I am running into the following issue:
> There are locked threads in the method WeldDeployment.getBeanDeploymentArchive(). Looking the code, this method is synchronized, so it makes sense. The question is, is this the expected behavior or this is a bug. In both cases is there any workaround to overcome this limitation?
> STACK TRACE:
> ....
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():73
> org.jboss.as.weld.WeldProvider$CdiImpl.getBeanManager():93
> org.jboss.as.weld.deployment.WeldDeployment.getBeanDeploymentArchive():226
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (JGRP-1914) S3_PING doesn't work with S3 buckets created in Frankfurt region
by Mark Morris (JIRA)
[ https://issues.jboss.org/browse/JGRP-1914?page=com.atlassian.jira.plugin.... ]
Mark Morris commented on JGRP-1914:
-----------------------------------
I have submitted a pull request that contains support for AWS Authentication Version 4 RESTful API. Use the new protocol class, S3_PING2 for access to ALL AWS regions. Run and review the several JUnit tests that exercise the code. Until the pull request is accepted you can access the code at:
URL: https://github.com/TarantulaTechnology/JGroups.git
Branch: S3_PING2_rc1.
> S3_PING doesn't work with S3 buckets created in Frankfurt region
> -----------------------------------------------------------------
>
> Key: JGRP-1914
> URL: https://issues.jboss.org/browse/JGRP-1914
> Project: JGroups
> Issue Type: Bug
> Reporter: Gleb Leonov
> Assignee: Bela Ban
> Fix For: 4.1
>
> Attachments: AWS4.png
>
>
> I tried to use S3_PING with access and secret key pair. However, I got 400 (Bad Request) error. After some investigation, I found that modern S3 buckets created in Frankfurt needs amazon v4 authentication, which needs hmac-sha256. But now S3_PING supports only hmac-sha1, so I see no way to use S3_PING with buckets in Frankfurt region.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6800) Database ignored in Postgres JDBC URL
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6800?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6800:
------------------------------------
thanks Mickaël, I'll close this as a duplicate of WFLY-6200.
> Database ignored in Postgres JDBC URL
> -------------------------------------
>
> Key: WFLY-6800
> URL: https://issues.jboss.org/browse/WFLY-6800
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Environment: java 8
> windows 7
> postgresql 9.4
> Reporter: Mickaël Vera
> Assignee: Scott Marlow
>
> I created a data source like this
> {code:xml}
> <datasource jndi-name="java:jboss/datasources/crawlRuntimeDS" pool-name="crawlRuntimePool" enabled="true" use-java-context="true">
> <connection-url>jdbc:postgresql://localhost:5432/runtimedb</connection-url>
> <driver>postgresDD</driver>
> <security>
> <user-name>postgres</user-name>
> <password>postgres</password>
> </security>
> </datasource>
> {code}
> {code:xml}
> I reference it in a persistent unit:
> <persistence-unit name="crawl-runtime-pu">
> <jta-data-source>java:jboss/datasources/crawlRuntimeDS</jta-data-source>
> <class>org.mvera.webscrap.model.crawl.runtime.CrawlEntity</class>
> <class>org.mvera.webscrap.model.crawl.runtime.PageCrawlStatusEntity</class>
> <exclude-unlisted-classes>true</exclude-unlisted-classes>
> <properties>
> <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect" />
> <property name="hibernate.show_sql" value="true" />
> <property name="hibernate.format_sql" value="true" />
> <property name="javax.persistence.schema-generation.database.action"
> value="none" />
> <property name="javax.persistence.schema-generation.scripts.action"
> value="drop-and-create" />
> <property name="javax.persistence.schema-generation.scripts.create-target"
> value="D:/mvera/crawl-runtime-pu-create.sql" />
> <property name="javax.persistence.schema-generation.scripts.drop-target"
> value="D:/mvera/crawl-runtime-pu-drop.sql" />
> </properties>
> </persistence-unit>
> {code}
> I thought for a moment that all was working right. My data was persisted and I could read it from within an EJB using this datasource. But then I discovered that my data was not persisted at all in the database "crawlRuntimeDS" specified on the jdbc URL of the datasource but in the database "postgres" (a default database created during install of postgres).
> This is a real problem as my application uses serveral databases (several persistence units). The workaround today is to put all entities in the same "postgres" database.
> In the datasource, I can put any name as the database name, it is ignored, even if the database doesn't exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6800) Database ignored in Postgres JDBC URL
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6800?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-6800.
------------------------------
Resolution: Duplicate Issue
> Database ignored in Postgres JDBC URL
> -------------------------------------
>
> Key: WFLY-6800
> URL: https://issues.jboss.org/browse/WFLY-6800
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 10.0.0.Final
> Environment: java 8
> windows 7
> postgresql 9.4
> Reporter: Mickaël Vera
> Assignee: Scott Marlow
>
> I created a data source like this
> {code:xml}
> <datasource jndi-name="java:jboss/datasources/crawlRuntimeDS" pool-name="crawlRuntimePool" enabled="true" use-java-context="true">
> <connection-url>jdbc:postgresql://localhost:5432/runtimedb</connection-url>
> <driver>postgresDD</driver>
> <security>
> <user-name>postgres</user-name>
> <password>postgres</password>
> </security>
> </datasource>
> {code}
> {code:xml}
> I reference it in a persistent unit:
> <persistence-unit name="crawl-runtime-pu">
> <jta-data-source>java:jboss/datasources/crawlRuntimeDS</jta-data-source>
> <class>org.mvera.webscrap.model.crawl.runtime.CrawlEntity</class>
> <class>org.mvera.webscrap.model.crawl.runtime.PageCrawlStatusEntity</class>
> <exclude-unlisted-classes>true</exclude-unlisted-classes>
> <properties>
> <property name="hibernate.dialect" value="org.hibernate.dialect.PostgreSQLDialect" />
> <property name="hibernate.show_sql" value="true" />
> <property name="hibernate.format_sql" value="true" />
> <property name="javax.persistence.schema-generation.database.action"
> value="none" />
> <property name="javax.persistence.schema-generation.scripts.action"
> value="drop-and-create" />
> <property name="javax.persistence.schema-generation.scripts.create-target"
> value="D:/mvera/crawl-runtime-pu-create.sql" />
> <property name="javax.persistence.schema-generation.scripts.drop-target"
> value="D:/mvera/crawl-runtime-pu-drop.sql" />
> </properties>
> </persistence-unit>
> {code}
> I thought for a moment that all was working right. My data was persisted and I could read it from within an EJB using this datasource. But then I discovered that my data was not persisted at all in the database "crawlRuntimeDS" specified on the jdbc URL of the datasource but in the database "postgres" (a default database created during install of postgres).
> This is a real problem as my application uses serveral databases (several persistence units). The workaround today is to put all entities in the same "postgres" database.
> In the datasource, I can put any name as the database name, it is ignored, even if the database doesn't exist.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-6804) Where to define thread-factory for thread-pool in ejb3 subsystem
by Claudio Miranda (JIRA)
Claudio Miranda created WFLY-6804:
-------------------------------------
Summary: Where to define thread-factory for thread-pool in ejb3 subsystem
Key: WFLY-6804
URL: https://issues.jboss.org/browse/WFLY-6804
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Claudio Miranda
Priority: Minor
There is an attribute "thread-factory" in /subsystem=ejb3/thread-pool=default.
Looking at jboss-as-ejb3_2_0.xsd it references jboss-as-threads.xsd, but there is no jboss-as-threads subsystem, it was removed in Wildfly 10.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months