[jboss-jira] [JBoss JIRA] (DROOLS-2278) Parallel rules compiling does not take into account JVM container security policy

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 ?