[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/22/16 12:08 PM:
---------------------------------------------------------------------
Paul has proposed a simpler, less intrusive fix based on the same idea. It involves injecting the TransactionSynchronizationRegistry directly into the Batcher and using that as a repository for Batch associated with a wrapping transaction. The code looks like this:
{noformat}
@Override
public V get(K id) {
Batcher<Batch> batcher = this.manager.getBatcher();
boolean tx = (this.tsr.getTransactionKey() != null);
// Leverage TSR to propagate Batch reference across calls to Cache.get(...) by different threads for the same tx
try (BatchContext context = batcher.resumeBatch(tx ? (Batch) this.tsr.getResource(this.manager) : null)) {
// Batch is not closed here - it will be closed during release(...) or discard(...)
@SuppressWarnings("resource")
Batch batch = batcher.createBatch();
try {
Bean<K, V> bean = this.manager.findBean(id);
if (bean == null) {
batch.close();
return null;
}
V result = bean.acquire();
result.setCacheContext(batch);
if (tx) {
this.tsr.putResource(this.manager, batch);
}
return result;
} catch (RuntimeException | Error e) {
batch.discard();
batch.close();
throw e;
}
}
}
{noformat}
In other words, when we want to do a get(), check to see if it is being called within the context of a transaction by checking the (server transaction manager's) tsr. If it is, retrieve any existing Batch associated with that transaction (via the tsr) *and* the SFSBs bean manager (via the resource in the tsr) and resume it, as opposed to any Batch simply associated with the current thread (and associated with the ISPN transaction manager). When we have finished creating the batch, store the updated batch in the transaction / bean manager resource so that it can be accessed the next time.
I have noticed that when accessing nested beans, the bean managers for the outer bean and the nested bean are different, so the same Batch is not used for both beans. This leads to failures.
I think i'm unclear on which batch is supposed to be used for which work:
- one per-UserTransaction Batch for all work performed within the scope of a user transaction?
- one per-Bean Batch for all work done on one bean within the scope of a transaction?
- something else?
was (Author: rachmato):
Paul has proposed a simpler, less intrusive fix based on the same idea. It involves injecting the TransactionSynchronizationRegistry directly into the Batcher and using that as a repository for Batch associated with a wrapping transaction. The code looks like this:
{noformat}
@Override
public V get(K id) {
Batcher<Batch> batcher = this.manager.getBatcher();
boolean tx = (this.tsr.getTransactionKey() != null);
// Leverage TSR to propagate Batch reference across calls to Cache.get(...) by different threads for the same tx
try (BatchContext context = batcher.resumeBatch(tx ? (Batch) this.tsr.getResource(this.manager) : null)) {
// Batch is not closed here - it will be closed during release(...) or discard(...)
@SuppressWarnings("resource")
Batch batch = batcher.createBatch();
try {
Bean<K, V> bean = this.manager.findBean(id);
if (bean == null) {
batch.close();
return null;
}
V result = bean.acquire();
result.setCacheContext(batch);
if (tx) {
this.tsr.putResource(this.manager, batch);
}
return result;
} catch (RuntimeException | Error e) {
batch.discard();
batch.close();
throw e;
}
}
}
{noformat}
In other words, when we want to do a get(), check to see if it is being called within the context of a transaction by checking the (server transaction manager's) tsr. If it is, retrieve any existing Batch associated with that transaction and resume it, as opposed to any Batch associated with the current thread (and associated with the ISPN transaction manager).
> 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/22/16 12:02 PM:
---------------------------------------------------------------------
Paul has proposed a simpler, less intrusive fix based on the same idea. It involves injecting the TransactionSynchronizationRegistry directly into the Batcher and using that as a repository for Batch associated with a wrapping transaction. The code looks like this:
{noformat}
@Override
public V get(K id) {
Batcher<Batch> batcher = this.manager.getBatcher();
boolean tx = (this.tsr.getTransactionKey() != null);
// Leverage TSR to propagate Batch reference across calls to Cache.get(...) by different threads for the same tx
try (BatchContext context = batcher.resumeBatch(tx ? (Batch) this.tsr.getResource(this.manager) : null)) {
// Batch is not closed here - it will be closed during release(...) or discard(...)
@SuppressWarnings("resource")
Batch batch = batcher.createBatch();
try {
Bean<K, V> bean = this.manager.findBean(id);
if (bean == null) {
batch.close();
return null;
}
V result = bean.acquire();
result.setCacheContext(batch);
if (tx) {
this.tsr.putResource(this.manager, batch);
}
return result;
} catch (RuntimeException | Error e) {
batch.discard();
batch.close();
throw e;
}
}
}
{noformat}
In other words, when we want to do a get(), check to see if it is being called within the context of a transaction by checking the (server transaction manager's) tsr. If it is, retrieve any existing Batch associated with that transaction and resume it, as opposed to any Batch associated with the current thread (and associated with the ISPN transaction manager).
was (Author: rachmato):
Paul has proposed a simpler, less intrusive fix based on the same idea. It involves injecting the TransactionSynchronizationRegistry directly into the Batcher and using that as a repository for Batch associated with a wrapping transaction. The code looks like this:
{noformat}
@Override
public V get(K id) {
Batcher<Batch> batcher = this.manager.getBatcher();
boolean tx = (this.tsr.getTransactionKey() != null);
// Leverage TSR to propagate Batch reference across calls to Cache.get(...) by different threads for the same tx
try (BatchContext context = batcher.resumeBatch(tx ? (Batch) this.tsr.getResource(this.manager) : null)) {
// Batch is not closed here - it will be closed during release(...) or discard(...)
@SuppressWarnings("resource")
Batch batch = batcher.createBatch();
try {
Bean<K, V> bean = this.manager.findBean(id);
if (bean == null) {
batch.close();
return null;
}
V result = bean.acquire();
result.setCacheContext(batch);
if (tx) {
this.tsr.putResource(this.manager, batch);
}
return result;
} catch (RuntimeException | Error e) {
batch.discard();
batch.close();
throw e;
}
}
}
{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] (JASSIST-262) Class compilation error
by Alexey Kuznetsov (JIRA)
Alexey Kuznetsov created JASSIST-262:
----------------------------------------
Summary: Class compilation error
Key: JASSIST-262
URL: https://issues.jboss.org/browse/JASSIST-262
Project: Javassist
Issue Type: Bug
Affects Versions: 3.20.0-GA
Environment: org.javassist:javassist:3.20.0-GA
java version "1.8.0_74"
Java(TM) SE Runtime Environment (build 1.8.0_74-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.74-b02, mixed mode)
Linux 3.13.0-37-generic #64-Ubuntu SMP x86_64 GNU/Linux
Reporter: Alexey Kuznetsov
Assignee: Shigeru Chiba
{code:java}
package com.company;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtMethod;
public class Main {
public static void main(String[] args) {
CtClass badClass = ClassPool.getDefault().makeClass("badClass");
String src = String.join(System.getProperty("line.separator"),
"public void eval () {",
" if (true) {",
" double t=0;",
" } else {",
" double t=0;",
" }",
" for (int i=0; i < 2; i++) {",
" int a=0;",
" int b=0;",
" int c=0;",
" int d=0;",
" if (true) {",
" int e = 0;",
" }",
" }",
"}");
System.out.println(src);
try {
badClass.addMethod(CtMethod.make(src, badClass));
Class clazzz = badClass.toClass();
Object obj = clazzz.newInstance(); // <-- falls here
} catch (Exception e) {
e.printStackTrace();
}
}
}
{code}
After running that i get output:
{noformat}
public void eval () {
if (true) {
double t=0;
} else {
double t=0;
}
for (int i=0; i < 2; i++) {
int a=0;
int b=0;
int c=0;
int d=0;
if (true) {
int e = 0;
}
}
}
Exception in thread "main" java.lang.VerifyError: Inconsistent stackmap frames at branch target 41
Exception Details:
Location:
badClass.eval()V @41: iinc
Reason:
Type top (current frame, locals[4]) is not assignable to integer (stack map, locals[4])
Current Frame:
bci: @35
flags: { }
locals: { 'badClass', top, top, top, top, integer, integer, integer, integer, integer }
stack: { integer }
Stackmap Frame:
bci: @41
flags: { }
locals: { 'badClass', top, top, top, integer, integer, integer, integer, integer }
stack: { }
Bytecode:
0x0000000: 0499 0009 0387 48a7 0006 0387 4a03 3605
0x0000010: 1505 05a2 001c 0336 0603 3607 0336 0803
0x0000020: 3609 0499 0006 0336 0a84 0501 a7ff e4b1
0x0000030:
Stackmap Table:
same_frame(@10)
same_frame(@13)
full_frame(@16,{Object[#2],Top,Top,Top,Top,Integer},{})
full_frame(@41,{Object[#2],Top,Top,Top,Integer,Integer,Integer,Integer,Integer},{})
full_frame(@47,{Object[#2],Top,Top,Top,Top,Integer},{})
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
at java.lang.Class.getConstructor0(Class.java:3075)
at java.lang.Class.newInstance(Class.java:412)
at com.company.Main.main(Main.java:31)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
Process finished with exit code 1
{noformat}
--
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/22/16 11:58 AM:
---------------------------------------------------------------------
Paul has proposed a simpler, less intrusive fix based on the same idea. It involves injecting the TransactionSynchronizationRegistry directly into the Batcher and using that as a repository for Batch associated with a wrapping transaction. The code looks like this:
{noformat}
@Override
public V get(K id) {
Batcher<Batch> batcher = this.manager.getBatcher();
boolean tx = (this.tsr.getTransactionKey() != null);
// Leverage TSR to propagate Batch reference across calls to Cache.get(...) by different threads for the same tx
try (BatchContext context = batcher.resumeBatch(tx ? (Batch) this.tsr.getResource(this.manager) : null)) {
// Batch is not closed here - it will be closed during release(...) or discard(...)
@SuppressWarnings("resource")
Batch batch = batcher.createBatch();
try {
Bean<K, V> bean = this.manager.findBean(id);
if (bean == null) {
batch.close();
return null;
}
V result = bean.acquire();
result.setCacheContext(batch);
if (tx) {
this.tsr.putResource(this.manager, batch);
}
return result;
} catch (RuntimeException | Error e) {
batch.discard();
batch.close();
throw e;
}
}
}
{noformat}
was (Author: rachmato):
Paul has proposed a simpler, less intrusive fix based on the same idea. It involves injecting the TransactionSynchronizationRegistry directly into the Batcher and using that as a repository for Batch associated with a wrapping transaction.
> 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-5400) Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
by Phil Festoso (JIRA)
[ https://issues.jboss.org/browse/WFLY-5400?page=com.atlassian.jira.plugin.... ]
Phil Festoso resolved WFLY-5400.
--------------------------------
Resolution: Done
> Failover of standalone JMS client fails with netty (blocking/non-blocking) connector
> ------------------------------------------------------------------------------------
>
> Key: WFLY-5400
> URL: https://issues.jboss.org/browse/WFLY-5400
> Project: WildFly
> Issue Type: Bug
> Components: Documentation, JMS
> Affects Versions: 10.0.0.CR1
> Reporter: Miroslav Novak
> Assignee: Phil Festoso
> Attachments: standalone-full-ha-backup.xml, standalone-full-ha-live.xml
>
>
> Failover of standalone JMS client fails if netty (blocking/non-blocking) connector is used. There are 2 EAP 7.0.0.DR10 (Artemis 1.1.0) servers configured in dedicated topology with shared store.
> If live server is killed then backup activates but client does not failover to it:
> {code}
> ent message with property count: 110867, messageId:ID:20310150-62a0-11e5-ada8-b3332c72af23
> Sent message with property count: 110868, messageId:ID:20310151-62a0-11e5-ada8-b3332c72af23
> Sep 24, 2015 11:39:27 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:40 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:39:55 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> Sep 24, 2015 11:40:10 AM org.apache.activemq.artemis.core.client.impl.ClientProducerCreditsImpl acquireCredits
> WARN: AMQ212054: Destination address=jms.queue.testQueue0 is blocked. If the system is configured to block make sure you consume messages on this configuration.
> {code}
> Attaching live/backup configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1138) Exclude the javax.mail jar from the kie-server war
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1138?page=com.atlassian.jira.plugi... ]
Edson Tirelli reassigned DROOLS-1138:
-------------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> Exclude the javax.mail jar from the kie-server war
> --------------------------------------------------
>
> Key: DROOLS-1138
> URL: https://issues.jboss.org/browse/DROOLS-1138
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final, 6.4.0.Final, 7.0.0.Final
> Reporter: Marco Rietveld
> Assignee: Maciej Swiderski
>
> As far as I can tell, the `javax.mail` specification is part of the JEE 6 (and higher) specifications.
> However, we do *not! exclude the `javax.mail:mail` jar from the `kie-server` wars: See https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.3.x/kie-serve...
> (`javax.mail:mail` is being included via the `jbpm-human-task-core` jar, which the `kie-server-services-jbpm` jar depends on.)
> Community users have reported running into classpath problems, which seem to be due to the inclusion of the `javax.mail:mail` jar
> In the JSR-316 (JEE 6 Specification) PDF, I found the following:
> {quote}
> EE.2.7.10JavaMail™
> Many Internet applications require the ability to send email notifications, so the Java EE platform includes the JavaMail API along with a JavaMail service provider that allows an application component to send Internet mail. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface used at the Java EE SPI level."
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1138) Exclude the javax.mail jar from the kie-server war
by Marco Rietveld (JIRA)
Marco Rietveld created DROOLS-1138:
--------------------------------------
Summary: Exclude the javax.mail jar from the kie-server war
Key: DROOLS-1138
URL: https://issues.jboss.org/browse/DROOLS-1138
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.4.0.Final, 6.3.0.Final, 7.0.0.Final
Reporter: Marco Rietveld
Assignee: Edson Tirelli
As far as I can tell, the `javax.mail` specification is part of the JEE 6 (and higher) specifications.
However, we do *not! exclude the `javax.mail:mail` jar from the `kie-server` wars: See https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.3.x/kie-serve...
(`javax.mail:mail` is being included via the `jbpm-human-task-core` jar, which the `kie-server-services-jbpm` jar depends on.)
Community users have reported running into classpath problems, which seem to be due to the inclusion of the `javax.mail:mail` jar
In the JSR-316 (JEE 6 Specification) PDF, I found the following:
{quote}
EE.2.7.10JavaMail™
Many Internet applications require the ability to send email notifications, so the Java EE platform includes the JavaMail API along with a JavaMail service provider that allows an application component to send Internet mail. The JavaMail API has two parts: an application-level interface used by the application components to send mail, and a service provider interface used at the Java EE SPI level."
{quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6024) The management console cannot display more than 5 runtime datasources
by Laurent Pereira (JIRA)
[ https://issues.jboss.org/browse/WFLY-6024?page=com.atlassian.jira.plugin.... ]
Laurent Pereira commented on WFLY-6024:
---------------------------------------
Nevermind. It is resolved in wildfly 10.
> The management console cannot display more than 5 runtime datasources
> ---------------------------------------------------------------------
>
> Key: WFLY-6024
> URL: https://issues.jboss.org/browse/WFLY-6024
> Project: WildFly
> Issue Type: Bug
> Components: Web Console
> Affects Versions: 9.0.2.Final
> Reporter: Laurent Pereira
> Assignee: Heiko Braun
> Priority: Minor
> Attachments: wildfly-console-runtime-datasource.PNG
>
>
> From the runtime tab of the management console : I cannot display more than 5 datasources although more than 6 have been defined.
> As a consequence, it is not possible to manage the missing datasources.
> Sample screenshot :
> !wildfly-console-runtime-datasource.PNG|thumbnail!
> 5 datasources of 7 are displayed. 2 datasources are always hidden. No scroll available.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years