[jboss-jira] [JBoss JIRA] Assigned: (JBRULES-2271) Thread-deadlock when Negation Was Used

[Edson Tirelli (JIRA)]

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

Edson Tirelli reassigned JBRULES-2271:
--------------------------------------

    Assignee: Edson Tirelli  (was: Mark Proctor)


> Thread-deadlock when Negation Was Used
> --------------------------------------
>
>                 Key: JBRULES-2271
>                 URL: https://jira.jboss.org/jira/browse/JBRULES-2271
>             Project: Drools
>          Issue Type: Bug
>      Security Level: Public(Everyone can see) 
>    Affects Versions: 5.0.1.FINAL
>         Environment: Drools version: 5.0.1
> JDK version: 1.5.0_6 
>            Reporter: freddy andersen
>            Assignee: Edson Tirelli
>
> A sever thread dead-lock was discovered when the Package instances were serialized/de-serialized, and then added to the RuleBase for execution. In the attached unit test, the thread-lock would occur in a few seconds. It seems the dead-lock would occur for conditions such as "rateTypeId not in (11,5)", and "rateTypeId != 11, rateTypeId != 5", while runs file with "rateTypeId in (11,5)" and "rateTypeId == 11 || rateTypeId == 5". 
> The attached unit test will not run without the "fix" from JBRULES-2267
> Our Fix:
> Removing the synchronized declaration in 2 places:
> 1. CompositeClassLoader.loadClass at line 54.
> 2. JavaDialectRuntimeData. PackageClassLoader.loadClass at line 451.
> Rational: The thread-deadlock happens when one rule execution thread is competing with one package merging thread. For class loading purpose, custom class loader objects are shared when the same Package objects are used in different RuleBuilders. Although no instance attributes were changed for those class loader objects, a common cause to share the objects, they do share the thread locks. When the object is locked, it's state changes, meaning it may not be a good idea to share those objects between threads. On the other hand, there seems no need to synchronize those "loadClass" methods. Thread lock is automatic when JVM's creates new classes. The issue seems fixed after our change. 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira