[JBoss JIRA] (DROOLS-1115) IndexOutOfBoundException when using conditional break + query
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1115?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1115:
-------------------------------------
I managed to make this fix to be part of Drools 6.4.0.Final :)
> IndexOutOfBoundException when using conditional break + query
> -------------------------------------------------------------
>
> Key: DROOLS-1115
> URL: https://issues.jboss.org/browse/DROOLS-1115
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 6.4.0.Final, 7.0.0.Final
>
>
> I got an java.lang.ArrayIndexOutOfBoundsException when I use conditionnal breaking and queries.
> I face this issue since 6.4.0.CR2 and not before this.
> Following the stack trace :
> java.lang.ArrayIndexOutOfBoundsException: 2
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:304)
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:311)
> at org.drools.core.phreak.PhreakQueryTerminalNode.checkAndTriggerQueryReevaluation(PhreakQueryTerminalNode.java:173)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftInserts(PhreakQueryTerminalNode.java:78)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:54)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at com.darty.drools.CodicCriteriaTest.price(CodicCriteriaTest.java:53)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (DROOLS-1115) IndexOutOfBoundException when using conditional break + query
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1115?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1115:
-------------------------------------------------
Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1325403|https://bugzilla.redhat.com/show_bug.cgi?id=1325403] from ASSIGNED to MODIFIED
> IndexOutOfBoundException when using conditional break + query
> -------------------------------------------------------------
>
> Key: DROOLS-1115
> URL: https://issues.jboss.org/browse/DROOLS-1115
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.4.0.CR2
> Reporter: Massinissa BOUZIAD
> Assignee: Mario Fusco
> Priority: Blocker
> Fix For: 7.0.0.Final
>
>
> I got an java.lang.ArrayIndexOutOfBoundsException when I use conditionnal breaking and queries.
> I face this issue since 6.4.0.CR2 and not before this.
> Following the stack trace :
> java.lang.ArrayIndexOutOfBoundsException: 2
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:304)
> at org.drools.core.reteoo.AbstractTerminalNode.getPathNodes(AbstractTerminalNode.java:311)
> at org.drools.core.phreak.PhreakQueryTerminalNode.checkAndTriggerQueryReevaluation(PhreakQueryTerminalNode.java:173)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doLeftInserts(PhreakQueryTerminalNode.java:78)
> at org.drools.core.phreak.PhreakQueryTerminalNode.doNode(PhreakQueryTerminalNode.java:54)
> at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:282)
> at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136)
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1003)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1346)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1284)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1303)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1293)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1274)
> at com.darty.drools.CodicCriteriaTest.price(CodicCriteriaTest.java:53)
--
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/12/16 10:14 AM:
---------------------------------------------------------------------
Another possibility might be to create a thread local ContextSelector<TransactionContext> (a mechanism that EJBClient uses to identify the current EJBClientContext or EJBClientTransactionContext associated with an invocation) and that ContextSelector could be used to lookup the current transaction context for the invocation. This could hold the transaction id, current transaction and any associated Batch and would be initialized in the EJBRemoteTransactionPropagatingInterceptor which associates EJBClient transactions with server side transactions.
When a transaction scoped invocation comes in, this gets initialized.
When the invocation accesses DistributableCache, the BatchManager gets the context to see if the invocation is wrapped in a transaction and if it is, either creates and stores the new batch (and associates it with the thread) or just gets the the existing batch and associates with the thread.
When the transaction commits / rollsback, this gets cleaned up.
This might avoid having to drag the JBossTM and SynchronizationRegistry into BatchManager. I'll think about this a little more.
was (Author: rachmato):
Another possibility might be to create a thread local ContextSelector<TransactionContext> (a mechanism that EJBClient uses to identify the current EJBClientContext or EJBClientTransactionContext associated with an invocation) and that ContextSelector could be used to lookup the current transaction context for the invocation. This could hold the transaction id, current transaction and any associated Batch and would be initialized in the EJBRemoteTransactionPropagatingInterceptor which associates EJBClient transactions with server side transactions.
When a transaction scoped invocation comes in, this gets initialized.
When the invocation accesses DistributableCache, the BatchManager gets the context to see if the invocation is wrapped in a transaction and if it is, either creates and stores the new batch (and associates it with the thread) or just gets the the existing batch and associates with the thread.
This might avoid dragging in the JBossTM into BatchManager. I'll think about this a little more.
> 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] (WFCORE-1461) LoggingPreferencesTestCase fails with security manager
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1461?page=com.atlassian.jira.plugi... ]
Ivo Studensky reassigned WFCORE-1461:
-------------------------------------
Assignee: Jan Tymel (was: Ivo Studensky)
What is the point of running WildFly Core tests with Security Manager enabled if there is no Security Manager subsystem in WF Core and thus no option to parse permission.xml of a deployment?
> LoggingPreferencesTestCase fails with security manager
> ------------------------------------------------------
>
> Key: WFCORE-1461
> URL: https://issues.jboss.org/browse/WFCORE-1461
> Project: WildFly Core
> Issue Type: Bug
> Components: Test Suite
> Reporter: Jan Tymel
> Assignee: Jan Tymel
>
> *org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase*
> {{.../WildFly_core/testsuite/manualmode/mvn test -DtestLogToFile=false -Dtest=org.jboss.as.test.manualmode.logging.LoggingPreferencesTestCase -Dsecurity.manager}}
> Fails with:
> {code}
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.util.PropertyPermission" "jboss.bind.address" "read")" in code source "(vfs:/content/logging-test.jar <no signer certificates>)" of "null")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPropertyAccess(WildFlySecurityManager.java:496)
> at java.lang.System.getProperty(System.java:717)
> at org.jboss.as.test.shared.TestSuiteEnvironment.getSystemProperty(TestSuiteEnvironment.java:50)
> at org.jboss.as.test.shared.TestSuiteEnvironment.getHttpAddress(TestSuiteEnvironment.java:162)
> at org.wildfly.test.undertow.UndertowServiceActivator.getAddress(UndertowServiceActivator.java:100)
> at org.wildfly.test.undertow.UndertowServiceActivator.activate(UndertowServiceActivator.java:66)
> at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> ... 5 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2043) Improve performance of Message#readHeader
by Sanne Grinovero (JIRA)
Sanne Grinovero created JGRP-2043:
-------------------------------------
Summary: Improve performance of Message#readHeader
Key: JGRP-2043
URL: https://issues.jboss.org/browse/JGRP-2043
Project: JGroups
Issue Type: Enhancement
Reporter: Sanne Grinovero
Assignee: Bela Ban
Priority: Minor
A CPU hot spot highlighed by profiling via JFR:
{noformat}Stack Trace Sample Count Percentage(%)
java.lang.reflect.Constructor.newInstance(Object[]) 71 2.392
java.lang.Class.newInstance() 71 2.392
org.jgroups.Message.readHeader(DataInput) 71 2.392
{noformat}
I'd have expected the reflective constructor to perform well on a recent JVM, but apparently it's not in this case. A theory is that the {{Class}} type being unknown makes this code harder to optimise; needs to be looked into.
It might be possible to patch the {{ClassConfigurator}} to provide instances of the required {{Header}} type rather than returning the class, and optimise that instead.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years