[jboss-jira] [JBoss JIRA] Closed: (JBRULES-541) Avoid WeakHashmap for tracking working memories in a RuleBase.

Mark Proctor (JIRA) jira-events at lists.jboss.org
Wed Apr 25 13:08:30 EDT 2007


     [ http://jira.jboss.com/jira/browse/JBRULES-541?page=all ]

Mark Proctor closed JBRULES-541.
--------------------------------

    Resolution: Done

no longer an issue as we no longer use weak hashmaps, working memories must not be manually disposed, or used statelessly.

> Avoid WeakHashmap for tracking working memories in a RuleBase.
> --------------------------------------------------------------
>
>                 Key: JBRULES-541
>                 URL: http://jira.jboss.com/jira/browse/JBRULES-541
>             Project: JBoss Rules
>          Issue Type: Feature Request
>      Security Level: Public(Everyone can see) 
>          Components: Rule Assemply/SPI
>    Affects Versions: 3.0.4
>            Reporter: Michael Neale
>         Assigned To: Mark Proctor
>            Priority: Critical
>             Fix For: 3.1-m2
>
>         Attachments: Engine.java, MultiThreadTest.java, rules.drl
>
>
> This comes under the heading of "I knew it would happen one day and I warned people about it but they didn't listen and Michael is always right in the long run, except when he predicted that the graphical web browser would NOT take off back in 1993 and was catastrophically wrong.
> Someone was having issues with concurrency (5 concurrent threads, but heavy load) and creating a newWorkingMemory - there are hangs/lock issues with the weak hashmap that points from the Single rule base to the spawned working memories. This is not surprising, blah blah blah....
> Anyway, one possible solution is to have a call where users who *want* to update an existing long lived working memory changes, pass in the WM to the rulebase, with say "refresh rules" - ie the methods like removeRule() on a rule base, require a working memory to be passed in.
> We can still keep the old WeakHashMap, just make it non default behaviour (it cannot scale the way it is now - with the default behaviour in my opinion). 
> STACK trace follows:
> I'm using Java 1.5_09 on Linux. The app uses 5 simultaneous threads at
> the moment. They never share WorkingMemory instances but do share the
> same RuleBase.
> A thread dump (see below) shows all threads being stuck in
> java.util.WeakHashMap, which is called from
> AbstractRuleBase.addWorkingMemory.
> Has anyone seen this before? I attempted to synchronize the method
> that's the entry point to newWorkingMemory(). That definitely made the
> problem happen less often but didn't solve it completely. Anyone knows
> any other workarounds?
> Thanks,
> Per
> "CW4" prio=1 tid=0x1a4fd7a8 nid=0xc44 runnable [0x1a2fe000..0x1a2fefb0]
>        at
> java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
>        at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
>        at java.util.WeakHashMap.put(WeakHashMap.java:394)
>        at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
> Source)
>        at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
> Source)
>        at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
> Source)
> "CW3" prio=1 tid=0x1a4fd5f0 nid=0xc43 runnable [0x1a6fe000..0x1a6fee30]
>        at java.util.WeakHashMap.put(WeakHashMap.java:397)
>        at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
> Source)
>        at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
> Source)
>        at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
> Source)
> "CW2" prio=1 tid=0x1a4fd100 nid=0xc42 runnable [0x1a8e5000..0x1a8e5eb0]
>        at
> java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
>        at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
>        at java.util.WeakHashMap.put(WeakHashMap.java:394)
>        at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
> Source)
>        at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
> Source)
>        at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
> Source)
> "CW1" prio=1 tid=0x19afca78 nid=0xc41 runnable [0x1a966000..0x1a967130]
>        at
> java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
>        at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
>        at java.util.WeakHashMap.put(WeakHashMap.java:394)
>        at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
> Source)
>        at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
> Source)
>        at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
> Source)
>        at
> "CW0" prio=1 tid=0x19afc7d8 nid=0xc40 runnable [0x1aafe000..0x1aaff1b0]
>        at
> java.util.WeakHashMap.expungeStaleEntries(WeakHashMap.java:289)
>        at java.util.WeakHashMap.getTable(WeakHashMap.java:297)
>        at java.util.WeakHashMap.put(WeakHashMap.java:394)
>        at org.drools.common.AbstractRuleBase.addWorkingMemory(Unknown
> Source)
>        at org.drools.reteoo.ReteooRuleBase.newWorkingMemory(Unknown
> Source)
>        at org.drools.common.AbstractRuleBase.newWorkingMemory(Unknown
> Source)
>        at

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

        



More information about the jboss-jira mailing list