[JBoss JIRA] (DROOLS-1139) Incomplete cloning of the EvalCondition evaluator
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1139:
-----------------------------------
Summary: Incomplete cloning of the EvalCondition evaluator
Key: DROOLS-1139
URL: https://issues.jboss.org/browse/DROOLS-1139
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
An EvalCondition evaluator needs to be cloned when 2 eval nodes have the same condition, but not the same parent and then cannot be shared. This cloning process is currently incomplete because the eval invoker (generated via ASM) remains the same (same instance) for the 2 evaluators thus resulting in an evaluation with wrong params.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1499) logging custom-handler does not load module with slot
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1499?page=com.atlassian.jira.plugi... ]
James Perkins moved WFLY-6547 to WFCORE-1499:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1499 (was: WFLY-6547)
Component/s: Logging
(was: Logging)
Affects Version/s: (was: JBoss AS7 7.2.0.Final)
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFCORE-1499
> URL: https://issues.jboss.org/browse/WFCORE-1499
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Erwan Lacoste
> Assignee: James Perkins
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1497) RBAC roles scoped to addresses that match a regex
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1497?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1497:
-------------------------------------
Description:
Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
{code}
<pattern-scoped-role name="log-maintainer" base-role="Maintainer>
<patterns>
<pattern value="(/profile=[^/]+)?/subsystem=logging(/.*)?"/>
</patterns>
</pattern-scoped-role>
{code}
I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
was:
Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
{code}
<pattern-scoped-role name="log-maintainer" base-role="Maintainer>
<patterns>
<!-- For domain controller -->
<pattern value="/profile={1}.*/subsystem=logging{1}.*"/>
<!-- For servers -->
<pattern value="/subsystem=logging{1}.*"/>
</patterns>
</pattern-scoped-role>
{code}
I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
> RBAC roles scoped to addresses that match a regex
> -------------------------------------------------
>
> Key: WFCORE-1497
> URL: https://issues.jboss.org/browse/WFCORE-1497
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Host scoped roles and server group scoped roles work via a constraint that checks the address being manipulated against a calculated group of allowed addresses. That calculation is complex in the server group and host cases to account for the complex semantics of those kinds of scoping while requiring very little config from the user, but we could also have a similar kind of scoping that requires more config from the user but is also more flexible. The user configures one or more regex strings, and any address (or canonical mbean object name) that matches meets the constraint.
> Example, a "log-maintainer" role that gets Maintainer privileges for the logging subsystem but is Monitor for everything else:
> {code}
> <pattern-scoped-role name="log-maintainer" base-role="Maintainer>
> <patterns>
> <pattern value="(/profile=[^/]+)?/subsystem=logging(/.*)?"/>
> </patterns>
> </pattern-scoped-role>
> {code}
> I use logging as an example as it's a use case I can imagine easily enough -- a server is largely locked down but tweaks to logging are allowed to allow diagnostic data to be gathered.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6547) logging custom-handler does not load module with slot
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6547?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6547:
-------------------------------------
What does your {{module.xml}} contents look like?
> logging custom-handler does not load module with slot
> -----------------------------------------------------
>
> Key: WFLY-6547
> URL: https://issues.jboss.org/browse/WFLY-6547
> Project: WildFly
> Issue Type: Bug
> Components: Logging
> Affects Versions: JBoss AS7 7.2.0.Final
> Reporter: Erwan Lacoste
> Assignee: James Perkins
>
> Tested on EAP 6.4
> when creating a module for a custom *loghandler*, everything works fine if the module is package in default main slot, e.g.
> my/loghandler/main
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler">
> {code}
> Nevertheless I want to version the module, therefore package my module with a given slot:
> my/loghandler/1.0
> - module.xml
> - my.jar
> {code:xml}
> <custom-handler name="4H" class="my.handler.Periodic4HFileHandler" module="my.loghandler:1.0">
> {code}
> But this fails with following stacktrace:
> {code}
> 11:53:50,458 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014612: Operation ("add") failed - address: ([
> ("subsystem" => "logging"),
> ("custom-handler" => "4H")
> ]): java.lang.IllegalArgumentException: JBAS011532: Failed to load module 'my.loghandler:1.0' for handler '4H'
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:320) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.performRuntime(HandlerOperations.java:255) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.logging.LoggingOperations$LoggingAddOperationStepHandler$1.execute(LoggingOperations.java:206) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:702) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:537) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:338) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:314) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1144) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.ModelControllerImpl.boot(ModelControllerImpl.java:416) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService.boot(AbstractControllerService.java:301) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:355) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.ServerService.boot(ServerService.java:330) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.controller.AbstractControllerService$1.run(AbstractControllerService.java:263) [jboss-as-controller-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_65]
> Caused by: org.jboss.modules.ModuleNotFoundException: my.loghandler:1.0:main
> at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:240) [jboss-modules.jar:1.3.6.Final-redhat-1]
> at org.jboss.as.logging.HandlerOperations$HandlerAddOperationStepHandler.createHandlerConfiguration(HandlerOperations.java:295) [jboss-as-logging-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 13 more
> {code}
> why is the module not found being *my.loghandler:1.0:main* ?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6540) Batch thread pool keepAlive setting seems to be ignored
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-6540?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-6540:
-------------------------------------
I've sent a PR to fix the bug in jboss-threads https://github.com/jbossas/jboss-threads/pull/20.
This is fairly common behavior for thread pools. If you were to increase the threads to 20, run some jobs and then decrease back down to 10 you'd see 10 of the threads go away.
Maybe in some ways it doesn't make sense to allow the keep-alive timeout to be configured in unbounded queues. Overall I'm not sure what would be expected here. I suppose it should at least be documented better on the resource.
> Batch thread pool keepAlive setting seems to be ignored
> -------------------------------------------------------
>
> Key: WFLY-6540
> URL: https://issues.jboss.org/browse/WFLY-6540
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Final
> Reporter: Martin Kouba
> Assignee: James Perkins
>
> Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce.
> Snippet from the default config file:
> {code}
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> {code}
> Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used.
> Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> setAllowCoreThreadTimeout(allow);
> }
> {code}
> should be replaced with:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> allowCoreThreadTimeOut(allow);
> }
> {code}
> Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well.
--
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:10 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, despite different bean accesses?
- 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 (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?
> 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