[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Marco Rietveld closed DROOLS-987.
---------------------------------
Resolution: Rejected
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Marco Rietveld commented on DROOLS-987:
---------------------------------------
Hi [~jcavieres],
I noticed this in the test:
{code:java}
RuleRuntimeEventManager ruleRuntimeEventManager = (RuleRuntimeEventManager) kSession;
ruleRuntimeEventManager.addEventListener(new DefaultAgendaEventListener() {
@Override
public void afterRuleFlowGroupActivated(RuleFlowGroupActivatedEvent event) {
kSession.fireAllRules();
}
});
{code}
Could you explain why you're calling {{fireAllRules()}} inside of a listener? You should never do this -- that is the cause of this problem.
When you add an explanation, please feel free to reopen this Jira.
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1008:
-------------------------------------
I am not sure of what you're asking here. I guess you're talking about the maven default behaviour of only fetching SNAPSHOTS once per day, but if this is the case I think you can configure maven to enforce of checking SNAPSHOTs at each request. Please let me know if this is case or try to better clarify this ticket.
> KieServer to update container for SNAPSHOT kjar
> -----------------------------------------------
>
> Key: DROOLS-1008
> URL: https://issues.jboss.org/browse/DROOLS-1008
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.2.0.Final, 6.3.0.Final
> Reporter: Andrew Collins
> Assignee: Mario Fusco
> Attachments: snapshot_kjar_reproducer.patch
>
>
> When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
by Miroslav Pavleski (JIRA)
Miroslav Pavleski created WFLY-6076:
---------------------------------------
Summary: CLI deployment of WAR exploded JSF2.2 applications fails with exceptions
Key: WFLY-6076
URL: https://issues.jboss.org/browse/WFLY-6076
Project: WildFly
Issue Type: Bug
Components: JSF
Affects Versions: 10.0.0.CR5
Reporter: Miroslav Pavleski
Assignee: Farah Juma
Attachments: cli.log, console.log
In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save.
The problem occurs probably due JSF initialization, see the attachments.
Deployment using mvn wildfly:deploy works fine.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-987:
------------------------------------
Marco, I'm giving a second look at this and in reality what is reentrant is this line in the DefaultSignalManager
org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74)
I suspect this is wrong anyway even if I cannot be sure that this is also causing the reported error.
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Marco Rietveld
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 11 months