[JBoss JIRA] (DROOLS-1135) NullPointerExceptions when using multiple concurrent KieSessions
by Eli Israel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugi... ]
Eli Israel commented on DROOLS-1135:
------------------------------------
Oh, thanks!
I missed that note in Github. Thanks for setting me straight. :)
> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
> Key: DROOLS-1135
> URL: https://issues.jboss.org/browse/DROOLS-1135
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
> while (true) {
> work = getItemsFromQueue();
> addAndRemoveFacts(kieSession, work);
> kieSession.fireAllRules();
> }
> } finally {
> kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$104/975722152.run(Unknown Source)
> 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)
> {code}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$162/1410998625.run(Unknown Source)
> 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)
> {code}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$99/1591140286.run(Unknown Source)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1883) Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1883:
----------------------------------------
Summary: Post-boot transition to/from acting as a master or slave HC must be done with management op execution locked out
Key: WFCORE-1883
URL: https://issues.jboss.org/browse/WFCORE-1883
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
As part of WFCORE-338, a Candidate Domain Controller can shift between acting a master or acting as slave without requiring a reload or reboot.
However, after initial boot, a DCC can be handling management requests. Any transition between acting as a master or slave to the other role must ensure that in-process management requests are not disrupted and that no new management requests are able to access the management model or runtime services until the transition is complete. As a practical matter this likely means that the transition task(s) must acquire the exclusive management lock and hold it until the transition is complete.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1881) Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1881?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1881:
------------------------------------------
Note that the design of this needs to consider the issues raised in WFCORE-1882.
> Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
> --------------------------------------------------------------------------------------
>
> Key: WFCORE-1881
> URL: https://issues.jboss.org/browse/WFCORE-1881
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Ken Wills
>
> The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC.
> I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable.
> Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster():
> 1) ProfileCloneHandler
> 2) IgnoredDomainResourceRegistry
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1882) Deal with WFCORE-1052 functionality in the HA DC case
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1882:
----------------------------------------
Summary: Deal with WFCORE-1052 functionality in the HA DC case
Key: WFCORE-1882
URL: https://issues.jboss.org/browse/WFCORE-1882
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
WFCORE-1052 adds the ability to reload a process to a different config file from what it is currently running. That includes the domain-wide config file if the reloading process is a master HC.
I don't think we want to support this in a WFCORE-338 scenario, as it amounts to a mechanism to force a different domain-wide config into the domain. I think we should have a more specific, controlled mechanism for that.
Once WFCORE-1881 is implemented HostProcessReloadHandler can check LocalHostControllerInfo to see if its running in a CDC. Note that this issue may have implications on the design of WFCORE-1881. That is, it may not be the case that if LHCI.isMaster() is true then LHCI.isCandidateDomainController() is true. Perhaps an HC configured in the EAP 7.0 and earlier style could be a master but not a CDC. For such an HC the WFCORE-1052 functionality could be available.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1845) Logging subsystem scans the CWD on server boot
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1845?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1845:
---------------------------------------
[~heiko.braun] I looked at this a bit yesterday. I'll be talking to Brian more about it today. Hopefully by the end of the week or early next week we'll have something sorted out.
> Logging subsystem scans the CWD on server boot
> ----------------------------------------------
>
> Key: WFCORE-1845
> URL: https://issues.jboss.org/browse/WFCORE-1845
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 2.0.10.Final
> Environment: OSX El Capitan, Oracle JDK 1.8.0_92 && 101, swarm 2016.8.1, WF 10.0.0.Final, WF-CORE 2.0.10.Final
> Reporter: Brent Douglas
> Assignee: James Perkins
>
> When booting the server from a directory where the subtree is large the server hangs for a long time. JStack shows that the logging subsystem is scanning the CWD.
> Booting the server from the root dir of a maven parent project containing 2 subprojects, a swarm project and a small NPM subproject added 33s to the server boot time compared to stepping into the swarm project and booting it.
> Stacktrace while the server is booting:
> {noformat}
> Thread 25859: (state = IN_NATIVE)
> - sun.nio.fs.UnixNativeDispatcher.lstat0(long, sun.nio.fs.UnixFileAttributes) @bci=0 (Compiled frame; information may be imprecise)
> - sun.nio.fs.UnixNativeDispatcher.lstat(sun.nio.fs.UnixPath, sun.nio.fs.UnixFileAttributes) @bci=10, line=300 (Compiled frame)
> - sun.nio.fs.UnixFileAttributes.get(sun.nio.fs.UnixPath, boolean) @bci=22, line=72 (Compiled frame)
> - sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes() @bci=15, line=52 (Compiled frame)
> - sun.nio.fs.UnixFileSystemProvider.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=57, line=144 (Compiled frame)
> - java.nio.file.Files.readAttributes(java.nio.file.Path, java.lang.Class, java.nio.file.LinkOption[]) @bci=7, line=1737 (Compiled frame)
> - java.nio.file.FileTreeWalker.getAttributes(java.nio.file.Path, boolean) @bci=56, line=219 (Compiled frame)
> - java.nio.file.FileTreeWalker.visit(java.nio.file.Path, boolean, boolean) @bci=3, line=276 (Compiled frame)
> - java.nio.file.FileTreeWalker.next() @bci=134, line=372 (Compiled frame)
> - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.util.Set, int, java.nio.file.FileVisitor) @bci=256, line=2706 (Compiled frame)
> - java.nio.file.Files.walkFileTree(java.nio.file.Path, java.nio.file.FileVisitor) @bci=9, line=2742 (Interpreted frame)
> - org.jboss.as.logging.LoggingResource.findFiles(java.lang.String, org.jboss.dmr.ModelNode, boolean) @bci=47, line=251 (Interpreted frame)
> - org.jboss.as.logging.LoggingResource.getChildrenNames(java.lang.String) @bci=37, line=157 (Interpreted frame)
> - org.jboss.as.logging.LoggingResource.getChildren(java.lang.String) @bci=11, line=171 (Interpreted frame)
> - org.jboss.as.controller.registry.AbstractModelResource$DelegateResource.getChildren(java.lang.String) @bci=5, line=362 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=99, line=289 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.PathAddress, org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=189, line=291 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int, org.jboss.as.controller.registry.ResourceFilter) @bci=19, line=276 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource, int) @bci=5, line=262 (Interpreted frame)
> - org.jboss.as.controller.registry.Resource$Tools.readModel(org.jboss.as.controller.registry.Resource) @bci=2, line=250 (Interpreted frame)
> - org.jboss.as.controller.ModelControllerImpl.writeModel(org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl, java.util.Set) @bci=19, line=769 (Interpreted frame)
> - org.jboss.as.controller.OperationContextImpl.createPersistenceResource() @bci=17, line=519 (Interpreted frame)
> - org.jboss.as.controller.AbstractOperationContext.executeDoneStage(org.jboss.dmr.ModelNode) @bci=22, line=708 (Interpreted frame)
> - org.jboss.as.controller.AbstractOperationContext.processStages() @bci=277, line=680 (Interpreted frame)
> - org.jboss.as.controller.AbstractOperationContext.executeOperation() @bci=27, line=370 (Interpreted frame)
> - org.jboss.as.controller.OperationContextImpl.executeOperation() @bci=20, line=1344 (Interpreted frame)
> - org.jboss.as.controller.ModelControllerImpl.boot(java.util.List, org.jboss.as.controller.client.OperationMessageHandler, org.jboss.as.controller.ModelController$OperationTransactionControl, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider, boolean, boolean) @bci=410, line=485 (Interpreted frame)
> - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean, boolean, org.jboss.as.controller.extension.MutableRootResourceRegistrationProvider) @bci=16, line=387 (Interpreted frame)
> - org.jboss.as.controller.AbstractControllerService.boot(java.util.List, boolean) @bci=7, line=349 (Interpreted frame)
> - org.jboss.as.server.ServerService.boot(java.util.List, boolean) @bci=22, line=392 (Interpreted frame)
> - org.jboss.as.server.ServerService.boot(org.jboss.as.controller.BootContext) @bci=907, line=365 (Interpreted frame)
> - org.jboss.as.controller.AbstractControllerService$1.run() @bci=12, line=299 (Interpreted frame)
> - java.lang.Thread.run() @bci=11, line=745 (Interpreted frame)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1135) NullPointerExceptions when using multiple concurrent KieSessions
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1135:
-------------------------------------
[~eliasisrael] For what I can see that commit has been already cherry-picked to 6.5.x branch and then will be included in 6.5.0.Final https://github.com/droolsjbpm/drools/commit/88bee808d439276cc3fda808e8f95...
> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
> Key: DROOLS-1135
> URL: https://issues.jboss.org/browse/DROOLS-1135
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
> while (true) {
> work = getItemsFromQueue();
> addAndRemoveFacts(kieSession, work);
> kieSession.fireAllRules();
> }
> } finally {
> kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$104/975722152.run(Unknown Source)
> 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)
> {code}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$162/1410998625.run(Unknown Source)
> 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)
> {code}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$99/1591140286.run(Unknown Source)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1881) Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1881:
----------------------------------------
Summary: Add isCandidateDomainController() to LocalHostControllerInfo and use it where possible
Key: WFCORE-1881
URL: https://issues.jboss.org/browse/WFCORE-1881
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Ken Wills
The WFCORE-338 work is going to add the notion of an HC being configured as a Candidate Domain Controller, which is a separate thing from being "master". There are a number of places where LocalHostControllerInfo.isMaster() is being called to make decisions that with WFCORE-338 should really depend on whether the HC is a CDC, not whether it is master. So, we want LHCI to expose whether the HC is a CDC.
I think initially we can have isCandidateDomainController() just return the result of isMaster(). We can add a setter to LocalHostControllerInfoImpl later when we actually make the CDC status independently configurable.
Places that should be updated as part of this task to use isCandidateDomainController() instead of isMaster():
1) ProfileCloneHandler
2) IgnoredDomainResourceRegistry
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1135) NullPointerExceptions when using multiple concurrent KieSessions
by Eli Israel (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1135?page=com.atlassian.jira.plugi... ]
Eli Israel commented on DROOLS-1135:
------------------------------------
Any chance of a backport of this fix to 6.5.0 before it goes final? I know it's probably asking a lot, but I'm hitting this problem often and would rather not have do something ugly like a global lock around calls to rule engine execution.
I'm assuming that 7.0.0.Final is still some ways off and I'm looking for the safest, quickest way to fix this up for our production usage. Thanks for considering this.
> NullPointerExceptions when using multiple concurrent KieSessions
> ----------------------------------------------------------------
>
> Key: DROOLS-1135
> URL: https://issues.jboss.org/browse/DROOLS-1135
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 7.0.0.Beta1
>
>
> A number of worker threads is running simultaneously in a thread pool. Each thread is initialised with the same KieContainer from which they extract a KieBase using KieContainer.getKieBase("name"). Each worker thread obtains a KieSession from its KieBase, and then executes a simple loop, taking instructions from a queue, inserting and removing facts based on those instructions, and then firing all rules:
> {code}
> kieSession = kieBase.newKieSession();
> try {
> while (true) {
> work = getItemsFromQueue();
> addAndRemoveFacts(kieSession, work);
> kieSession.fireAllRules();
> }
> } finally {
> kieSession.dispose();
> }
> {code}
> This causes the following exceptions:
> {code}
> Exception in thread "Worker-1" java.lang.NullPointerException at org.drools.core.reteoo.NodeTypeEnums.isLeftTupleSource(NodeTypeEnums.java:84)
> at org.drools.core.phreak.SegmentUtilities.updateRiaAndTerminalMemory(SegmentUtilities.java:380)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:171)
> at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:205)
> at org.drools.core.phreak.SegmentUtilities.processQueryNode(SegmentUtilities.java:192)
> at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:115)
> at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:166)
> at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:63)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:300)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$104/975722152.run(Unknown Source)
> 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)
> {code}
> {code}
> Exception in thread "Worker-6" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:416)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$162/1410998625.run(Unknown Source)
> 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)
> {code}
> {code}
> Exception in thread "Worker-7" java.lang.NullPointerException at org.drools.core.reteoo.ObjectTypeNode.updateTupleSinkId(ObjectTypeNode.java:410)
> at org.drools.core.reteoo.ObjectTypeNode.checkDirty(ObjectTypeNode.java:274)
> at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:294)
> at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:78)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:73)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:2017)
> at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1334)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1306)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1297)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1278)
> at com.X.processRequests(X.java:86)
> at com.X$$Lambda$99/1591140286.run(Unknown Source)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (DROOLS-1337) A FQN inline cast followed by a method invocation causes an ArrayIndexOutOfBoundsException
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1337:
-----------------------------------
Summary: A FQN inline cast followed by a method invocation causes an ArrayIndexOutOfBoundsException
Key: DROOLS-1337
URL: https://issues.jboss.org/browse/DROOLS-1337
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
An inline cast using a fully qualified name followed by a method invocation causes an ArrayIndexOutOfBoundsException as in the following test case:
{code}
@Test
public void testInlineCastWithFQNAndMethodInvocation() throws Exception {
String str =
"import org.drools.compiler.Person;\n" +
"global java.util.List list;\n" +
"rule R1 when\n" +
" Person( name == \"mark\", $x : address#org.drools.compiler.LongAddress.country.substring(1) )\n" +
"then\n" +
" list.add($x);" +
"end\n";
KnowledgeBase kbase = loadKnowledgeBaseFromString(str);
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
List<String> list = new ArrayList<String>();
ksession.setGlobal( "list", list );
Person mark1 = new Person("mark");
mark1.setAddress(new LongAddress("uk"));
ksession.insert(mark1);
assertEquals(1, ksession.fireAllRules());
assertEquals(1, list.size());
assertEquals("k", list.get(0));
ksession.dispose();
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1880) Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1880:
----------------------------------------
Summary: Extension add operation handling should check that the slave HCs are not running later versions of the subsystem management API
Key: WFCORE-1880
URL: https://issues.jboss.org/browse/WFCORE-1880
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Ken Wills
Conceptually related to WFCORE-1879, but here the case is a slave that is already registered handling an /extension=foo:add operation sent by the master. It's theoretically possible that the slave might be running an earlier or equal version of all extensions that were configured when it registered, but for this new "foo" extension it has a newer version. If this happens the add operation should fail. The extension cannot be configured while the domain topology is like this.
Note if the slave is ignoring the extension add op, that is fine.
It's possible this is already somewhat handled. If an extension is added, for transformation to work properly the slave has to send back management API information that the master can use going forward. It's possible though that even that is not being done, which would be a bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months