]
Mario Fusco updated DROOLS-2278:
--------------------------------
Sprint: 2020 Week 10-12 (from Mar 2)
Parallel rules compiling does not take into account JVM container
security policy
---------------------------------------------------------------------------------
Key: DROOLS-2278
URL:
https://issues.redhat.com/browse/DROOLS-2278
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 7.5.0.Final
Environment: Linux 2.6.32-696.13.2.el6.x86_64
OpenJDK Runtime Environment (build 1.8.0_151-b12)
OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
Reporter: Dorin Opris
Assignee: Mario Fusco
Priority: Major
We deployed Drools 7.5.0.Final libraries in a java container (commercial product) which
specifies a security manager and a policy.
When running the container with small Drools packages (i.e. number of rules is less than
10) processing goes very well. When it comes to more rules the following exception is
issued:
SEVERE Failed to instantiate <container_unit>; Caused by:
org.jini.rio.core.JSBInstantiationException:
java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "createClassLoader")
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
at java.lang.ClassLoader.<init>(ClassLoader.java:316)
at
org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.<init>(JavaDialectRuntimeData.java:573)
at
org.drools.core.rule.JavaDialectRuntimeData.makeClassLoader(JavaDialectRuntimeData.java:555)
at
org.drools.core.rule.JavaDialectRuntimeData.onAdd(JavaDialectRuntimeData.java:238)
at
org.drools.compiler.rule.builder.dialect.java.JavaDialect.<init>(JavaDialect.java:189)
at
org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.newDialect(JavaDialectConfiguration.java:88)
at
org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectRegistry(KnowledgeBuilderConfigurationImpl.java:377)
at
org.drools.compiler.compiler.PackageRegistry.<init>(PackageRegistry.java:51)
at
org.drools.compiler.builder.impl.KnowledgeBuilderImpl.createPackageRegistry(.java:1051)
at
org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$getOrCreatePackageRegistry$0(KnowledgeBuilderImpl.java:1026)
at
java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
at
org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getOrCreatePackageRegistry(KnowledgeBuilderImpl.java:1026)
at
org.drools.compiler.builder.impl.TypeDeclarationCache.createTypeDeclarationForBean(TypeDeclarationCache.java:262)
at
org.drools.compiler.builder.impl.TypeDeclarationCache.getAndRegisterTypeDeclaration(TypeDeclarationCache.java:90)
at
org.drools.compiler.builder.impl.TypeDeclarationBuilder.getAndRegisterTypeDeclaration(TypeDeclarationBuilder.java:69)
at
org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getAndRegisterTypeDeclaration(KnowledgeBuilderImpl.java:1781)
at
org.drools.compiler.rule.builder.PatternBuilder.processClassObjectType(PatternBuilder.java:306)
at
org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:181)
at
org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:151)
at
org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:133)
at
org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:105)
at
org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1202)
at
org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$compileRulesLevel$3(KnowledgeBuilderImpl.java:1163)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
at
java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1380)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
It seems Drools 7.* version has introduced parallel compilation of rules using Java
platform forkJoin threads that, according to its spec, are a bit security restrictive in
the sense that container security policy or container class loader access control context
is ignored.
"If a SecurityManager is present and no factory is specified, then the default pool
uses a factory supplying threads that have no Permissions enabled. The system class loader
is used to load these classes."
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPo...
Could Drools fix this serial-parallel asymmetric output of rules compilation logic? Or
it's just a Java issue like
https://bugs.java.com/view_bug.do?bug_id=8184335 ?