[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1130:
-------------------------------------
Reproduced with the following test case
{code}
@Test(timeout=10000)
public void testCascadingTimedRule() throws Exception {
String drl =
"package org.simple \n" +
"import " + AtomicInteger.class.getCanonicalName() + "\n" +
"rule R1 \n" +
" timer (int:30s) " +
"when \n" +
" $i : AtomicInteger(get() == 1)" +
"then \n" +
" modify($i) { set(2) }; \n" +
"end \n" +
"rule R2 \n" +
"when \n" +
" $i : AtomicInteger(get() == 2)" +
"then \n" +
" modify($i) { set(3) }; \n" +
"end \n";
KieSessionConfiguration conf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
conf.setOption( ClockTypeOption.get( "pseudo" ) );
conf.setOption( TimedRuleExectionOption.YES );
KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
.build()
.newKieSession( conf, null );
PseudoClockScheduler timeService = ( PseudoClockScheduler ) ksession.<SessionClock>getSessionClock();
timeService.advanceTime( new Date().getTime(), TimeUnit.MILLISECONDS );
AtomicInteger i = new AtomicInteger( 1 );
ksession.insert( i );
ksession.fireAllRules();
timeService.advanceTime( 35, TimeUnit.SECONDS );
assertEquals(3, i.get());
}
{code}
> Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1130
> URL: https://issues.jboss.org/browse/DROOLS-1130
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: timer-rule-bug.zip
>
>
> I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of:
> http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht...
> _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_
> Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase.
> *DRL:*
> {code}
> import java.util.logging.Logger
> import bug.timedrules.Table
> rule "table with 1 player"
> timer( int: 3s)
> no-loop true
> when
> $table : Table( getCounter() == 1)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 1");
> modify($table){
> setCounter(2)
> }
> end
> rule "Table upgrade to 2 player"
> no-loop true
> when
> $table : Table( getCounter() == 2)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 2");
> modify($table){
> setCounter(3)
> }
> end
> {code}
> *java code:*
> {code}
> @Test
> public void executeNewRuleAfterTimedRuleExecution() throws Exception {
> KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();
> ksconf.setOption(TimedRuleExectionOption.YES);
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL);
> if (kbuilder.hasErrors()) {
> throw new IllegalStateException(kbuilder.getErrors().toString());
> }
> kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null);
> Table table = new Table(1234, 1);
> statefulKnowledgeSession.insert(table);
> statefulKnowledgeSession.fireAllRules();
> Thread.sleep(TimeUnit.SECONDS.toMillis(5));
> statefulKnowledgeSession.dispose();
> Assert.assertThat(table.getCounter(), CoreMatchers.is(3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6808.
------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
Fixed by WFLY-6878.
> DistributableSession validate method throw misleading exception message
> -----------------------------------------------------------------------
>
> Key: WFLY-6808
> URL: https://issues.jboss.org/browse/WFLY-6808
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final, 11.0.0.Alpha1
>
>
> In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
> {code}
> public class DistributableSession implements io.undertow.server.session.Session {
> private static void validate(Session<LocalSessionContext> session) {
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
> }
> }
> }
> {code}
> The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
> I would recommend we do instead:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
> }
> {code}
> or even better:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
> }
> {code}
> but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-4186) Improve Infinispan module compatibility with older releases
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4186?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-4186.
------------------------------
Resolution: Out of Date
> Improve Infinispan module compatibility with older releases
> -----------------------------------------------------------
>
> Key: WFLY-4186
> URL: https://issues.jboss.org/browse/WFLY-4186
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
> I suggest we either:
> 1. Export org.infinispan.commons from the org.infinispan module
> 2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1684) Empty lines between tab completion suggestions on Windows
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1684?page=com.atlassian.jira.plugi... ]
Petr Kremensky moved JBEAP-5478 to WFCORE-1684:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1684 (was: JBEAP-5478)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.DR1)
> Empty lines between tab completion suggestions on Windows
> ---------------------------------------------------------
>
> Key: WFCORE-1684
> URL: https://issues.jboss.org/browse/WFCORE-1684
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> I noticed that CLI put empty lines between lines with suggested values once the Windows terminal is set to maximal width. Issue appears *only of the CLI is connected to the EAP running in domain* mode.
> *reproduce*
> \- start EAP in domain mode
> \- open a new terminal window, manually set the terminal width to maximal allowed value, but do not maximize the window
> \- connect CLI to the running server and pres the Tab key
> {noformat}
> [domain@localhost:9990 /]
> : clear data-source echo if pwd reload shutdown unset
> alias command deploy echo-dmr jdbc-driver-info quit rollout-plan try version
> batch connect deployment-info help ls read-attribute run-batch unalias xa-data-source
> cd connection-info deployment-overlay history patch read-operation set undeploy
> {noformat}
> I was able to reproduce the issue on W2K8 and W2K12 servers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-747) declared window, type length(1), do actually contain more than 1 object (with reteoo)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-747?page=com.atlassian.jira.plugin... ]
Mario Fusco closed DROOLS-747.
------------------------------
Resolution: Out of Date
> declared window, type length(1), do actually contain more than 1 object (with reteoo)
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-747
> URL: https://issues.jboss.org/browse/DROOLS-747
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 20150323.DROOLS-747-reproducer.zip
>
>
> h5. Premise
> I know reteoo is progressively being deprecated, but I think until is there is helpful for A/B testing of possible leaks comparing with phreak (like it happened during 610Final) so reporting this bug.
> h5. Executive summary
> Declaring a window of type length (1) should always contain 1 object.
> h5. Details
> With reference to attached reproducer.
> Given the following knowledge base:
> {code}
> global java.util.concurrent.atomic.AtomicLong globalCounter;
> declare Measurement
> @role(event)
> end
> declare window lastMeasurement
> Measurement() over window:length( 1 ) // from entry-point DEFAULT
> end
> rule "IFF the last Measurement that I know of, is of ID color, increment the counter"
> no-loop
> when
> Measurement( id == "color" ) from window lastMeasurement
> then
> globalCounter.incrementAndGet();
> end
> {code}
> The goal is: IFF the last Measurement that I know of, is of ID "color", increment the counter. Please notice you ought to separate the window being just on Measurement, in order to know the last Measurement regardless of the ID, and then you have a rule acting on the declared window, to check IFF this last Measurement, is actually of ID "color".
> Now assuming you just have created the session and the following increment/insert/fire:
> {code}
> AtomicLong globalCounter = new AtomicLong(0);
> session.setGlobal("globalCounter", globalCounter);
> session.fireAllRules();
> assertEquals("no data, still 0", 0, globalCounter.get());
> LOG.info("Now running data");
> clock.advanceTime(1, TimeUnit.MINUTES);
> Measurement mRed= new Measurement("color", "red");
> session.insert(mRed);
> Measurement mGreen= new Measurement("color", "green");
> session.insert(mGreen);
> Measurement mBlue= new Measurement("color", "blue");
> session.insert(mBlue);
> session.fireAllRules();
> LOG.info("Final checks");
> assertEquals("win lenght =1 was: ", 1, globalCounter.get());
> {code}
> At the end you should have the global counter with value = 1, because we inserted 3 events of type Measurement, but the declared window lastMeasurement should reference only {{mBlue}}, which should be later picked by the rule because the ID is "color", and increment the counter by 1.
> This works with phreak, it does not work with reteo.
> phreak globalCounter = 1 : OK
> reteoo globalCounter = 3 : FAIL.
> Could you kindly advise, please?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1683) Home and End keys doesn't work on Windows
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1683?page=com.atlassian.jira.plugi... ]
Petr Kremensky updated WFCORE-1683:
-----------------------------------
Description:
Home and End keys doesn't work properly on Windows.
*actual*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] echoαG[] test
[disconnected /] echo<END> test
[disconnected /] echoαO[] test
{noformat}
*expected*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] []echo test
[disconnected /] echo<END> test
[disconnected /] echo test[]
{noformat}
was:
Home and End keys doesn't work properly on Windows.
*actual*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] echoαG test
[disconnected /] echo<END> test
[disconnected /] echoαO test
{noformat}
*expected*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] []echo test
[disconnected /] echo<END> test
[disconnected /] echo test[]
{noformat}
> Home and End keys doesn't work on Windows
> -----------------------------------------
>
> Key: WFCORE-1683
> URL: https://issues.jboss.org/browse/WFCORE-1683
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Home and End keys doesn't work properly on Windows.
> *actual*
> {noformat}
> [disconnected /] echo<HOME> test
> [disconnected /] echoαG[] test
> [disconnected /] echo<END> test
> [disconnected /] echoαO[] test
> {noformat}
> *expected*
> {noformat}
> [disconnected /] echo<HOME> test
> [disconnected /] []echo test
> [disconnected /] echo<END> test
> [disconnected /] echo test[]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1683) Home and End keys doesn't work on Windows
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1683?page=com.atlassian.jira.plugi... ]
Petr Kremensky moved JBEAP-5476 to WFCORE-1683:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1683 (was: JBEAP-5476)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.DR1)
Affects Testing: (was: Regression)
> Home and End keys doesn't work on Windows
> -----------------------------------------
>
> Key: WFCORE-1683
> URL: https://issues.jboss.org/browse/WFCORE-1683
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Home and End keys doesn't work properly on Windows.
> *actual*
> {noformat}
> [disconnected /] echo<HOME> test
> [disconnected /] echoαG test
> [disconnected /] echo<END> test
> [disconnected /] echoαO test
> {noformat}
> *expected*
> {noformat}
> [disconnected /] echo<HOME> test
> [disconnected /] []echo test
> [disconnected /] echo<END> test
> [disconnected /] echo test[]
> {noformat}
> The issues is a regression against EAP 6.4.0
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1683) Home and End keys doesn't work on Windows
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1683?page=com.atlassian.jira.plugi... ]
Petr Kremensky updated WFCORE-1683:
-----------------------------------
Description:
Home and End keys doesn't work properly on Windows.
*actual*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] echoαG test
[disconnected /] echo<END> test
[disconnected /] echoαO test
{noformat}
*expected*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] []echo test
[disconnected /] echo<END> test
[disconnected /] echo test[]
{noformat}
was:
Home and End keys doesn't work properly on Windows.
*actual*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] echoαG test
[disconnected /] echo<END> test
[disconnected /] echoαO test
{noformat}
*expected*
{noformat}
[disconnected /] echo<HOME> test
[disconnected /] []echo test
[disconnected /] echo<END> test
[disconnected /] echo test[]
{noformat}
The issues is a regression against EAP 6.4.0
> Home and End keys doesn't work on Windows
> -----------------------------------------
>
> Key: WFCORE-1683
> URL: https://issues.jboss.org/browse/WFCORE-1683
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> Home and End keys doesn't work properly on Windows.
> *actual*
> {noformat}
> [disconnected /] echo<HOME> test
> [disconnected /] echoαG test
> [disconnected /] echo<END> test
> [disconnected /] echoαO test
> {noformat}
> *expected*
> {noformat}
> [disconnected /] echo<HOME> test
> [disconnected /] []echo test
> [disconnected /] echo<END> test
> [disconnected /] echo test[]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-6898) ConcurrentModificationException when returning from JMS onMessage() MBean
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-6898?page=com.atlassian.jira.plugin.... ]
Tomas Remes commented on WFLY-6898:
-----------------------------------
Hi [~traivor]
Do you have some reproducer please?
> ConcurrentModificationException when returning from JMS onMessage() MBean
> -------------------------------------------------------------------------
>
> Key: WFLY-6898
> URL: https://issues.jboss.org/browse/WFLY-6898
> Project: WildFly
> Issue Type: Feature Request
> Components: CDI / Weld
> Affects Versions: 10.1.0.CR1
> Reporter: Harold Campbell
> Assignee: Stuart Douglas
>
> I receive the following stacktrace when an MBean's onMessage() returns. The transaction is rolled back and the message marked as undelivered. This started sometime after nightly #2280 which works fine for me.
> 2016-07-30 21:51:49,273 TRACE [com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener] (Thread-0 (ActiveMQ-client-global-threads-556320704)) Finished processing run 16819
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.handleInCallerTx(CMTTxInterceptor.java:159)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:256)
> at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 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.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:47)
> 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.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 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:67)
> 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.as.ejb3.component.messagedriven.MessageDrivenComponentDescription$5$1.processInvocation(MessageDrivenComponentDescription.java:239)
> 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:198)
> at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$view3.onMessage(Unknown Source)
> 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:497)
> at org.jboss.as.ejb3.inflow.MessageEndpointInvocationHandler.doInvoke(MessageEndpointInvocationHandler.java:139)
> at org.jboss.as.ejb3.inflow.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:73)
> at com.envestnet.ejb.winthorpe.optimizer.WinthorpeRunListener$$$endpoint1.onMessage(Unknown Source)
> at org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:310)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1018)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:48)
> at org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1145)
> at org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:103)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:160)
> at org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:58)
> at org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
> at org.jboss.weld.context.ejb.EjbRequestContextImpl.deactivate(EjbRequestContextImpl.java:47)
> at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:76)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months