Rules compilation error with OSGi integration (6.1.0.Beta3)
by Ephemeris Lappis
Hello.
We have a very simple rules file that works as expected when running as a
JUnit test in Eclipse with Maven dependencies, but fails when it is
executing in ServiceMix with OSGi integration.
The code is just like :
raw>
Map<String, Object> dialog = new LinkedHashMap<>();
KieSession kieSession = kieContainer.newKieSession("MyKSession");
kieSession.setGlobal("dialog", dialog);
kieSession.insert(problem);
kieSession.fireAllRules();
kieSession.dispose();
The rules file :
And the kmodule.xml :
The compilation error is about Java 7 syntax elements (as generics or
thousand separators in number literals for example), and seems to indicate
that in this case the compiler is not the same, and it expects another Java
syntax. No error is reported when the KieContainer is created from the
KModule.xml, but the following error occurs when using it for KSession
creation.
This occurs both with the prepackaged feature
(http://repo1.maven.org/maven2/org/drools/drools-karaf-features/6.1.0.Beta...),
or with an adapted one. For example, the Maven dependancies classpath in
eclipse mentions newer versions of the Eclipse's ECJ. But changing the
version of bundles has no effect...
What is missing in the feature to activate the correct rules compiler ?
Thanks for your help ?
Regards.
--
View this message in context: http://drools.46999.n3.nabble.com/Rules-compilation-error-with-OSGi-integ...
Sent from the Drools: User forum mailing list archive at Nabble.com.
11 years, 7 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.
11 years, 7 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.
11 years, 7 months
Drools and GPU
by Anton Hughes
Hi all
We have finding drools to be very resource hungry - and we are looking at
having to have very many servers just to satisfy our drools requirements.
So I am wondering, has anyone experimented with running drools on a GPU
server?
Thanks and regards
Anton
11 years, 7 months
newbie question about KnowledgeBuilder
by kenatnielsen
Hi,
I'm inheriting Drools 6.0 application where all rules are in one huge drl
file. Would behavior be different if I broke rules into multiple files and
loaded with multiple calls to KnowledgeBuilder.add()?
Also, KnowledgeBuilder is being created with each session:
KnowledgeBuilder.newKnowledgeBuilder() and then knowledgeBuilder.add().
Since rules don't change, any reason why can't create KnowledgeBuilder at
startup and share it? Is it thread safe and can it be re-used?
Thanks,
Ken
--
View this message in context: http://drools.46999.n3.nabble.com/newbie-question-about-KnowledgeBuilder-...
Sent from the Drools: User forum mailing list archive at Nabble.com.
11 years, 7 months
