]
Edson Tirelli commented on JBRULES-2276:
----------------------------------------
Re-posting comment from JBRULES-2271 here.
===========================
JBRULES-2225 contains a slightly different change in the composite classloader to use a
copy-on-write array list and no locking on the loadClAss method. No locking at all nor a
concurrent collection might introduce ConcurrentModificationExceptions.
JBRULES-2263 contains changes in the locking of the reload data to avoid mainly a
potential bottle neck when rules are modified constantly.
Could you retest your issue with those patches, please?
==========================
Thread-deadlock when Negation Was Used
--------------------------------------
Key: JBRULES-2276
URL:
https://jira.jboss.org/jira/browse/JBRULES-2276
Project: Drools
Issue Type: Bug
Security Level: Public(Everyone can see)
Components: drools-core
Affects Versions: 5.0.1.FINAL
Environment: Drools version: 5.0.1
JDK version: 1.5.0_6
Reporter: Freddy Andersen
Assignee: Edson Tirelli
Attachments: DroolsTest.java, TestFact.java
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".
Please note that this test would not run without out fix in the previous submitted ticket
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
this simple change.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: