Rules not picked when packaged inside the JAR
by ash316
I am working on DROOLS 6.0.1 application. I have my rule files (*.drl)
packaged inside a separate project which is included as a jar file as a
maven dependency. When I deploy my project, KIEModule is not able to find
the rules files (which are packaged inside the jar above). I am not getting
an error though but rules are not getting fired.If I manually place the
rules files under classpath say WEB-INF/rules/*.drl they are detected and
rules are executed.I was under impression that KIEmodules are auto
discovered from anywhere in classpath.Any pointers are appreciated. This is
general question hence I have not included the comprehensive code files.
Everything start working once I place the *.drl files in the classpath (take
them outside of jar).I have opened the JIRA issue @ Link
<https://issues.jboss.org/browse/DROOLS-466> Thanks
--
View this message in context: http://drools.46999.n3.nabble.com/Rules-not-picked-when-packaged-inside-t...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10 years, 4 months
Drools Planner: Vehicle routing problems
by davidglassborow
Hi,
as discussed the other day with Ge0ffrey on IRC, I've been trying to
get some vehicle routing done using the new TSP / chaining functionality in
drools planner.
I've written an example, but am having problems with the chaining of jobs
together. After pulling my hair out, I've put together an example into my
fork of planner, showing a simplified example of how I am approaching it,
and the problem that can be replicated.
https://github.com/davidglassborow/drools-planner/tree/vehicle_routing
It is a very simple console app along the same lines as the hello world
example for NQueens.
On running it will print out the chains, and you will see the some Jobs
appear more than once in the same list.
On the planning variable it seems to be get assigned in front of itself,
I've put some notes in the source, and checked that the same doesn't occur
in your TSP example.
I'm not sure if its a bug in the way I've setup things, or whether its an
issue in the chain move code.
Greatly appreciated if anybody in the know gets a chance to have a look.
Thanks,
David
--
View this message in context: http://drools.46999.n3.nabble.com/Drools-Planner-Vehicle-routing-problems...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10 years, 5 months
"Cannot find KieModule" with kieServices.newKieContainer() with LATEST or RELEASE instead of explicit version number (eg: 0.0.1)
by Matteo Mortari
Hello,
in the hope this could save time if someone has been experiencing same
issue. Drools 6.0.1.Final
I had message "Cannot find KieModule" with kieServices.newKieContainer()
with LATEST or RELEASE , instead of explicit version number (eg: 0.0.1) on
a application where the KIE module Rule artifact project kjar has been
locally-installed from remote Maven repository, that is the right hand side
of this diagram:
http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/...
Meaning that before launching Application, I performed
mvn org.apache.maven.plugins:maven-dependency-plugin:2.8:get
-Dartifact=com.acme:X:LATEST -DrepoUrl=
http://nexus-hostname/nexus/content/repositories/releases/
Then:
kieServices.newKieContainer() with LATEST,
kieServices.newKieContainer() with RELEASE,
failed with stack trace:
Exception in thread "main" java.lang.RuntimeException: Cannot find
KieModule: com.acme:X:RELEASE
at
org.drools.compiler.kie.builder.impl.KieServicesImpl.newKieContainer(KieServicesImpl.java:86)
at (...)
But kieServices.newKieContainer() with a fixed version, eg.: 0.0.2 did
indeed worked OK, if installed in the local .m2 repository.
To avoid this issue, I found only 3 possible workarounds
1 use mvn maven-dependency-plugin:go-offline but did not work all of the
time
2 manually ensure maven-metadata-local.xml file is generate in local .m2
repository
3 just download manually .jar and .pom of the remote maven repo, and then
install with mvn install:install-file
In this case, of workaround kieServices.newKieContainer() works OK with
all the version LATEST, RELEASE, and fixed version number.
Raise jira DROOLS-419 with more details and example projects, please don't
hate me if was just me missing something or not-Drools issue actually
=P
In my defense I had good intentions saving somebody's else time in case
same strange behavior, which is really strange because to me it worked only
with explicit fixed version number, and that was really bizarre ;)
Hope this helps,
Ciao
MM
10 years, 6 months
Upgrade to protobuf 2.5 - Prevents Upgrading to Drools 6.x
by mikerod
Note: I originally tried posting this as a reply to this
<http://drools.46999.n3.nabble.com/Upgrade-to-protobuf-2-5-and-how-to-work...>
, before I realized it was the wrong mailing list.
_____
It looks like moving from protobuf-java v.2.4.1 to v.2.5.0 has non-passive
changes that are causing more troubles preventing an upgrade to Drools
v.6.x.
Explained here <https://code.google.com/p/protobuf/issues/detail?id=493>
Our Drools rules are ran in an environment that must share a classpath with
Hadoop libs. These libs are still using protobuf-java v.2.4.1 and cannot
easily be upgraded.
The problem comes down to a runtime error:
```
2014-03-11 06:39:25,229 FATAL org.apache.hadoop.mapred.Child: Error running
child : java.lang.VerifyError: class
org.drools.compiler.kie.builder.impl.KieModuleCache$KModuleCache overrides
final method getUnknownFields.()Lcom/google/protobuf/UnknownFieldSet;
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at
org.drools.compiler.kie.builder.impl.KieBuilderImpl.createCacheBuilder(KieBuilderImpl.java:269)
at
org.drools.compiler.kie.builder.impl.KieBuilderImpl.generateKieModuleMetaInfo(KieBuilderImpl.java:224)
at
org.drools.compiler.kie.builder.impl.KieBuilderImpl.buildAll(KieBuilderImpl.java:194)
<... application level omitted ...>
```
This error makes sense given the changes in protobuf-java v.2.5.
I do not believe that our use-case of the Drools rules engine involves the
use of any of the features of the `KieModuleCache` and
marshalling/unmarshalling libs associated with it.
However, I do not see any sort of configuration that would avoid this error.
I tried to simply use the "legacy" Drools knowledge-api when upgrading to
Drools v.6.x, but this has failed us since there are several unimplemented
methods in the `org.drools.impl.adapters.KnowledgeRuntimeAdapter`, such as
`org.drools.impl.adapters.KnowledgeRuntimeAdapter#getQueryResults`.
Side note: I expected the knowledge-api to be fully-functional and
implemented in Drools v6.x for backwards compatibility and for tooling
integration
<http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html_single/...>
.
However, this does not seem to be the case at this point.
We are eager to move to Drools v6.x to avoid some performance issues we are
facing due to performance issues with eagerly evaluating `AccumulateNode`
results that are accumulating large collections
<http://drools.46999.n3.nabble.com/Object-size-impact-on-session-insertion...>
.
Do you have any suggestions?
--
View this message in context: http://drools.46999.n3.nabble.com/Upgrade-to-protobuf-2-5-Prevents-Upgrad...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10 years, 6 months
CompositiveClassLoader$CachingLoader$load method intermittently hangs
by mikerod
I cannot easily reproduce an issue that I'm seeing. This is an intermittent
issue that happens probably 3% of the time or less.
This is observed behavior in
* Drools v5.6.0.Final, using
* Janino compiler v2.5.16 && transitively Drools brings
* mvel2 v2.1.8.Final
We have an environment that loads around 10 different KnowledgeBases into a
list.
Then one-by-one a single StatefulKnowledgeSession is created for a single
KnowledgeBase, facts are inserted, and then fireAllRules is called.
Every so often, we noticed that we were getting what seemed to be ininite
looping behavior for during either insertion time or fireAllRules time.
When we subsequently re-run the *same* session with the *same* KnowledgeBase
and the *same* facts inserted, it was successful and finished in
milliseconds (the average for our successful runs). We have repeatedly seen
this behavior of 1 failure, followed by a re-run that is successful.
We were able to attach a profiler to several of these hung sessions to
determine what was happening. It turns out that in both the scenario where
we saw a hang up on fact insertion and on fireAllRules call, the thread dump
was the same.
The stack looks like:
```
"main" - Thread t@1
java.lang.Thread.State: RUNNABLE
at java.util.HashMap.getEntry(HashMap.java:347)
at java.util.HashMap.containsKey(HashMap.java:335)
at
org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:244)
at
org.drools.util.CompositeClassLoader$CachingLoader.load(CompositeClassLoader.java:237)
at
org.drools.util.CompositeClassLoader.loadClass(CompositeClassLoader.java:88)
at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at
org.mvel2.ParserConfiguration.checkForDynamicImport(ParserConfiguration.java:163)
at
org.mvel2.ParserConfiguration.hasImport(ParserConfiguration.java:191)
at org.mvel2.ParserContext.hasImport(ParserContext.java:360)
at org.mvel2.ParserContext.isVariableVisible(ParserContext.java:715)
at
org.mvel2.compiler.ExpressionCompiler.verify(ExpressionCompiler.java:394)
at
org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:250)
at
org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:62)
at org.mvel2.MVEL.compileExpression(MVEL.java:810)
at
org.drools.base.mvel.MVELCompilationUnit.compile(MVELCompilationUnit.java:417)
at
org.drools.base.mvel.MVELCompilationUnit.getCompiledExpression(MVELCompilationUnit.java:238)
at
org.drools.rule.constraint.MvelConstraint.createMvelConditionEvaluator(MvelConstraint.java:224)
at
org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:208)
at
org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:175)
at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:133)
at
org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at
org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at
org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:302)
at
org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:254)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:366)
at
org.drools.common.SimpleBeliefSystem.insert(SimpleBeliefSystem.java:38)
at
org.drools.common.TruthMaintenanceSystem.addLogicalDependency(TruthMaintenanceSystem.java:207)
at
org.drools.common.TruthMaintenanceSystem.addLogicalDependency(TruthMaintenanceSystem.java:179)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:247)
at
org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:950)
at
org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:263)
at
org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:228)
at
org.drools.base.DefaultKnowledgeHelper.insertLogical(DefaultKnowledgeHelper.java:223)
<application-stack>
at some.drools.generated.rule.package.Rule_<drools-generated2>
at some.drools.generated.rule.package.Rule_<drools-generated1>
at
org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1282)
- locked <656dd9a0> (a org.drools.common.DefaultAgenda)
at
org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1216)
- locked <656dd9a0> (a org.drools.common.DefaultAgenda)
at
org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1451)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:756)
at
org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:718)
at
org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230)
<facts-inserted-previously>
```
We were able to get the same hung thread dump prior to fireAllRules. I
think the related entry point is during one of the #assertObject calls
midway through the stack.
The CompositiveClassLoader$CachingLoader definitely seems to be the issue.
When we found this behavior consistently occurring (although rare), I found
the option of turning off the use of the caching loader by setting the
"drools.classLoaderCacheEnabled"="false" option referenced in the
ClassLoaderCacheOption class.
With this setting, we have done extensive retries to find this behavior and
it has vanished.
This CompositiveClassLoader$CachingLoader uses an internal j.u.HashMap that
is not safe for concurrent access. I have listed below several related
posts on the topic. I'm fairly sure if this used a j.u.c.ConcurrentHashMap,
this hanging thread scenario would not happen.
However, most of the posts I've seen on this subject are from use-cases
where the application is explicitly doing some sort of multithreaded access
to the Drools
KnowledgeBase and/or StatefulKnowledgeSession.
In my case, I do not know of *any* multithreaded actions taking place within
my application around the Drools KnowledgeBase or StatefulKnowledgeSession.
I am not seeing ConcurrentModificationException though. Instead I'm seeing
a, seemingly infinite, loop in the j.u.HashMap#getEntry.
Hanging in a "get" method of the j.u.HashMap would suggest to me that there
is a race condition where sometimes the j.u.HashMap#put on
the `classLoaderResultMap` field in the
CompositiveClassLoader$CachingLoader#load method is being executed at the
same time as another thread is doing the
j.u.HashMap#getEntry. If the j.u.HashMap were to resize at this point, it
could cause an infinite looping behavior.
Does Drools internally use multithreading? Is there somewhere in the MVEL
lib or the Janino compiler where it may be concurrently accessing the
CompositiveClassLoader$CachingLoader$load method?
I have been digging around a lot and I cannot find what could be the root
cause of this behavior.
I think this relates directly to these:
* http://lists.jboss.org/pipermail/rules-users/2013-July/032446.html
* http://lists.jboss.org/pipermail/rules-users/2013-July/032446.html
However, I do not see a real resolution to the problem.
I also see several related issues:
* http://lists.jboss.org/pipermail/rules-users/2013-July/032446.html
* https://issues.jboss.org/browse/JBRULES-3552
--
View this message in context: http://drools.46999.n3.nabble.com/CompositiveClassLoader-CachingLoader-lo...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10 years, 6 months
Efficiency questions about DSL
by mfalaize
Hi,
I was wondering how to use efficiently DSL with my rules and I have several
questions about it :
- First, I have the impression that we can use DSL files only in the same
package of the DSLR file. When I tried to load DSL files by the kmodule.xml
(specifying the different packages in the packages attribute of kbase) it
does not work. Do I have to load each DSL files programmatically or is there
a way to load it automatically by the kmodule.xml (and if it is the case,
how can we handle the parsing order of these files ?) ?
- An underlying question is is this a good practice to divide DSL files ? I
would like to translate all my rules in french and to put the generic
translations in a unique DSL file to reuse it in all of my different DSLR
files.
- I noted that we can use more than one DSL file for one DSLR file (it works
at the runtime) but when it is the case the DRL viewer of the DSL rule
editor does not work and I don't have autocompletion. I tried to put several
expander instructions but it fails. Is there a way to make it work ?
I think DSL stuff is underestimate at this moment by the community and for
my last question I would like to know what is the future plans about this
feature ? Maybe I could help to develop it.
Regards
--
View this message in context: http://drools.46999.n3.nabble.com/Efficiency-questions-about-DSL-tp402877...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10 years, 6 months
Drools 6 support for changeset
by wtang
I have a requirement in which when a rule is changed, the change needs to be
reflected immediately without retarting the system.
In Drools 5.x we can use the changeset.xml with the knowlegde agent. Now in
Drool 6.0 we have Kie API.
1) does Kie support changeset.xml?
2) Upper management don't want to use kie, they want to use jsr94. Does
jsr94 support changeset.xml?
--
View this message in context: http://drools.46999.n3.nabble.com/Drools-6-support-for-changeset-tp402713...
Sent from the Drools: User forum mailing list archive at Nabble.com.
10 years, 6 months
part time intern @ Red Hat
by Mark Proctor
I have a small budget for a part time intern for one year, 12K USD. The work can be 100% remote, from almost any country. This will mostly be UI work, improving our workbench.
If this interests you, email me off list.
Mark
10 years, 6 months
