]
Mario Fusco resolved DROOLS-1567.
---------------------------------
Resolution: Rejected
Hi [~arkadys], I investigated your reproducer but again I don't think that I can do
anything about this. The problem you found is quite specific of your app and I don't
want to pollute the ProjectClassLoader with configurable filter that (if misused) could
also lead to very weird and difficult to track behaviours. Moreover the ProjectClassLoader
already has a cache of non existing classes and this allow it to avoid the lookup more
than once. Using your reproducer I verified that this cache is working as expected.
The only suggestion to hugely alleviate this problem that I can give you is avoid using
the mvel dialect. In this way you'll avoid mvel's ParseTool to keep invoking the
ClassLoader because the consequences will be internally implemented in pure Java. I hope
this helps.
Threads in BLOCKED state in ProjectClassLoader and ParseTools
-------------------------------------------------------------
Key: DROOLS-1567
URL:
https://issues.jboss.org/browse/DROOLS-1567
Project: Drools
Issue Type: Enhancement
Components: core engine
Affects Versions: 6.5.0.Final
Reporter: Arkady Syamtomov
Assignee: Mario Fusco
Building the knowledge bases in parallel threads does not scale due to the recurrent
synchronised call of Class.forName, detected in ProjectClassLoader and
org.mvel2.util.ParceTools.
While in the org.drools.core.common.ProjectClassLoader the classes, if not found, are
blacklisted, in the org.mvel2.util.ParceTools there is no blacklist logic implemented at
all.
Nevertheless, even with org.drools.core.common.ProjectClassLoader the issue remains,
since the internal DRL conditions query are submitted as class names to resolve and with
the number of rules growing in the system, the blacklisting of invalid class names is not
enough any more: it would be desirable to have an internal hook to filter the names
matching a configurable pattern.