Drools worker Thread taking too much time, throwing sun.nio.fs.UnixException

Question

I have an application where in which I use drools workbench(KIE) for rule validations in Java. Now I am facing something odd with this drool worker thread which gets created while firing rules. On an average, response time for the rule execution is less than 500ms in my application. Recently, I could observe that occasionally it is taking more time to return the rules response. This is happening very rarely, but it is happening. Recently it took around 29 minutes for the expected response. This ultimately crashed my application. I need to handle this "special case".

Using Dynatrace application, I had inspected the processes happening in code level. I could see that

 Asynchronous invocation
                 |
                 |___ JRE | java.util.concurrent.FutureTask

is just repeating and taking too much time in each execution. I had attached the screenshot of the same.. And I could observe few errors as well.

Exception: sun.nio.fs.UnixException

Message: No such file or directory

Stacktrace: sun.nio.fs.UnixNativeDispatcher.access0(UnixNativeDispatcher.java) sun.nio.fs.UnixNativeDispatcher.access(UnixNativeDispatcher.java:449) sun.nio.fs.UnixFileSystemProvider.checkAccess(UnixFileSystemProvider.java:306) java.nio.file.Files.exists(Files.java:2385) org.jboss.modules.PathResourceLoader.lambda$ org.jboss.modules.PathResourceLoader$$Lambda$.run org.jboss.modules.PathResourceLoader.doPrivilegedIfNeeded(PathResourceLoader.java:227) org.jboss.modules.PathResourceLoader.getResource(PathResourceLoader.java:139) org.jboss.modules.ModuleClassLoader.loadResourceLocal(ModuleClassLoader.java:349) org.jboss.modules.ModuleClassLoader$1.loadResourceLocal(ModuleClassLoader.java:96) org.jboss.modules.Module.getResourceAsStream(Module.java:784) org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:556) org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:370) java.lang.Class.getResourceAsStream(Class.java:2223) org.drools.core.util.asm.ClassFieldInspector.(ClassFieldInspector.java:80) org.drools.core.util.asm.ClassFieldInspector.(ClassFieldInspector.java:72) org.drools.core.base.ClassFieldAccessorFactory.getClassFieldReader(ClassFieldAccessorFactory.java:107) org.drools.core.base.ClassFieldAccessorCache$CacheEntry.getReadAccessor(ClassFieldAccessorCache.java:166) org.drools.core.base.ClassFieldAccessorCache.getReadAcessor(ClassFieldAccessorCache.java:99) org.drools.core.base.ClassFieldAccessorStore.wire(ClassFieldAccessorStore.java:460) org.drools.core.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:126) org.drools.core.base.ClassFieldAccessorStore.getReader(ClassFieldAccessorStore.java:103) org.drools.compiler.rule.builder.PatternBuilder.getFieldReadAccessor(PatternBuilder.java:1677) org.drools.compiler.rule.builder.PatternBuilder.addConstraintToPattern(PatternBuilder.java:856) org.drools.compiler.rule.builder.PatternBuilder.buildRelationalExpression(PatternBuilder.java:811) org.drools.compiler.rule.builder.PatternBuilder.buildExpression(PatternBuilder.java:735) org.drools.compiler.rule.builder.PatternBuilder.buildCcdDescr(PatternBuilder.java:719) org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:670) org.drools.compiler.rule.builder.PatternBuilder.processConstraintsAndBinds(PatternBuilder.java:524) org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:329) org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:138) org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66) org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:89) org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1652) org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:968) org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:844) org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:279) org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:103) org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:91)

I think this error might be the cause for the same.

In ideal case, I am not seeing

Asynchronous invocation ---- >JRE | java.util.concurrent.FutureTask

while I am inspecting through Dynatrace and no errors as well. I had attached screenshot as well.

My java code which fires the rule is as follows :

final KieContainer kContainerTubes = loadRulesBean.getKieContainerMap().get(ConfiguratorConstants.TUBES.toUpperCase());
final StatelessKieSession kSessionProduct = kContainerTubes.newStatelessKieSession();
kSessionProduct .execute(products);

What worries here is the occurance of this issue. Very rare !!.

I think it's going to be related to your input and your rules. Possibly an infinite loop or a recursive structure or something. — Roddy of the Frozen Peas, May 07 '21 at 15:41
This happens very rarely. Same rules works in other time. Mentioned error trace could be the reason as I am not seeing the same when getting proper response — Jince Martin, May 09 '21 at 07:15
The error trace is why I suggested it. You're failing down into the underlying filesystem. The fact that it happens very rarely is also evidence for it being related to specific rules and inputs. — Roddy of the Frozen Peas, May 09 '21 at 15:35

score 1 · Answer 1 · answered May 10 '21 at 20:44

The stacktrace proves that your KnowledgeBase is re-build at runtime, i.e. your rule definitions are parsed and converted to Java classes at runtime. Ideally the compiled rules are already deployed with your application or loaded by your application (e.g. from a Maven repository).

The mentioned exception is caused by a call of Files.exists(Path) when resources are loaded to compile the rules. This method catches the exception internally when it checks for the existense of a file. In Java 8 this takes around ten times longer than File.exists() when a file does not exist (See here for details). But we are talking here about milliseconds and not minutes. Code that makes excessive use of Files.exists(Path) may be negatively impacted but in your case the actual reading of the resources and its compilation takes definitely much longer. As long as you don't see any errors about missing resources in the log, there shouldn't be any real issue with this error. While searching for a resource the module/class loading code may search in multiple locations for the file until it finds it in one of the locations.

Drools worker Thread taking too much time, throwing sun.nio.fs.UnixException

1 Answers1