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.
10 years, 9 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, 10 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, 10 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
10 years, 10 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.
10 years, 10 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, 10 months
Startup KIE Workbench without network connection
by Sandjaja, Dominik
Hello,
I try to setup KIE Workbench (6.1.0.BetaX) on Tomcat 7 on a Windows 2012 Server without connection to the internet.
When starting up, the KIE-WB does not start up. I get the following errors in localhost.log (cut for better readability):
Mai 15, 2014 5:08:18 PM org.apache.catalina.core.StandardContext listenerStart
Schwerwiegend: Exception sending context initialized event to listener instance of class org.jboss.weld.environment.servlet.Listener
org.jboss.weld.exceptions.DeploymentException: Exception List with 1 exceptions:
[...]
Caused by: java.lang.RuntimeException: https://github.com/guvnorngtestuser1/guvnorng-playground.git: cannot open git-upload-pack
[...]
Caused by: java.net.ConnectException: Connection time out: github.com
This happens because the initial demo repository is downloaded - I do not want and need those repositories!
I could work around this by copying the TOMCAT_HOME/bin/.niogit directory to that server and have it start up then.
BUT: IMHO it is an inconvenience, maybe even a bug, that an internet connection is needed to set up the Drools KIE Workbench. How are we supposed to tell our infrastructure team that we need an open connection to "some website with code" to setup an editing system for internal knowledge ...
Should I file a bug for that? Is there a way to deactivate the downloading of the initial demo repository? Could it somehow be delivered with the KIE-WB package?
Thanks
Dominik
...........................................................................
mit freundlichen Gr??en / kind regards
Dominik Sandjaja
Fon: +49 (0) 203 60878 183
Fax: +49 (0) 203 60878 222
e-mail: dominik.sandjaja(a)it-motive.de
it-motive AG
Zum Walkm?ller 6
47269 Duisburg
info(a)it-motive.de
http://www.it-motive.de
..............................................................................
Vorsitzender des Aufsichtsrats: Dr.-Ing. J?rgen Sturm
Vorstand: Horst-Dieter Deelmann (Vors.), Matthias Heming, Christoph Tim Klose
HRB 9207, Amtsgericht Duisburg
10 years, 10 months
