[jboss-jira] [JBoss JIRA] (DROOLS-1567) Threads in BLOCKED state in ProjectClassLoader and ParseTools

[Mario Fusco (JIRA)]

     [ https://issues.jboss.org/browse/DROOLS-1567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.



--
This message was sent by Atlassian JIRA
(v7.2.3#72005)