December 2006 - jboss-jira - Jboss List Archives

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

by Michael Neale (JIRA)

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 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

19 years, 3 months

6
9
0 / 0

[JBoss JIRA] Created: (JBAOP-313) Better error messages in AspectXmlLoader

by Kabir Khan (JIRA)

Better error messages in AspectXmlLoader ---------------------------------------- Key: JBAOP-313 URL: http://jira.jboss.com/jira/browse/JBAOP-313 Project: JBoss AOP Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.0.0.alpha2 Reporter: Kabir Khan Fix For: 2.0.0.alpha3 -- 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

19 years, 3 months

2
3
0 / 0

[JBoss JIRA] Created: (JBRULES-571) Export-Import from XML (for backup and migration)

by Michael Neale (JIRA)

Export-Import from XML (for backup and migration) ------------------------------------------------- Key: JBRULES-571 URL: http://jira.jboss.com/jira/browse/JBRULES-571 Project: JBoss Rules Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Michael Neale Assigned To: Michael Neale -- 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

19 years, 3 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-449) Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory

by Juergen none (JIRA)

Logical dependency bug, justifier tuple contains retracted handles, logically depend object stays in working memory ------------------------------------------------------------------------------------------------------------------- Key: JBRULES-449 URL: http://jira.jboss.com/jira/browse/JBRULES-449 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.4 Environment: jdk 1.4.2_10 Reporter: Juergen none Assigned To: Mark Proctor A rather complicated, intertwined set of rules leads to a logically asserted fact, that remains in working memory, even after its justifiers have been retracted. Sadly I have no unit-test, but I can outline the rules and execution sequence as reported by a listener (a ... assert, al ... assert logical, r ... retract) Its a buggy (R5 twice) implementation of a accumulating set of rules I posted in the user list some time ago. FFF(A), FFF(B) are of same class but not equal, @... is systemHashCode, so different instances, but possible equal (as mentioned) classes without @ have only one instance in working memory a XXX R0: XXX -> al DDD a AAA (external assert) Sequence of rules fired R1: AAA -> al GGG R2: DDD, GGG -> al CCC R3: GGG -> al EEE R4: EEE, DDD, CCC -> a BBB@15737ca, al FFF@b2d75c(A) (BBB@15737ca contributes to hash/equals of FFF@b2d75c) R5: BBB, CCC, FFF(A), not FFF(B) -> mod CCC (hashcodes changes, but all rules are still fulfilled as before), a FFF@b274de(B) R5 again (modify triggered): EEE, DDD, CCC -> a BBB@16d8ba (but equals(BBB@15737ca) is true), (+ my guess, object created and assert called but no listener info: al FFF@2aefe3(A) (equals FFF@b2d75c, backing its logical dependency) (BBB@16d8ba contributes to Hash/equals)) --- r AAA (external retract) -> (according to listener): r AAA r GGG r EEE r CCC breakpoint, screenshot --> justifier list is invalid, contains retracted handles PoolCondition would be DDD, the only valid handle in the (EEE, DDD, CCC) tuple r XXX (retract of XXX has no consequence, just the last handle, still valid in the screenshot, becomes invalid too) -> r XXX r DDD workingMemory.getObjects() lists FFF@b2d75c(A) and FFF@b274de(B) for Rulebase-properties: - RuleBaseConfiguration.PROPERTY_ASSERT_BEHAVIOR -> RuleBaseConfiguration.WM_BEHAVIOR_IDENTITY - empty Major lead could be that after commenting out "mod CCC", FFF(A) is retracted (+ R5 not fired a second time) + problem with changed hashcode of CCC ? + problem with second instances of BBB and FFF(A) being asserted + FFF(B) being assert normally, not logically -- 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

19 years, 3 months

4
12
0 / 0

[JBoss JIRA] Created: (JBPM-708) Version control of the process definition

by Aravind Kumar (JIRA)

Version control of the process definition ----------------------------------------- Key: JBPM-708 URL: http://jira.jboss.com/jira/browse/JBPM-708 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM 3.1.1 Reporter: Aravind Kumar Assigned To: Tom Baeyens When working with jBPM in developement environment, there is no control over the version of the process-definition. Each time the server is restarted, a new version is deployed. The work around that I did: <boolean name="update-definition" value="false"/> this tag is included in the jbpm.cfg.xml & a check at JbpmContext.java: public void deployProcessDefinition(ProcessDefinition processDefinition) { if(JbpmConfiguration.Configs.getBoolean("update-definition")) { getGraphSession().deployProcessDefinition(processDefinition); } } This works fine for a single process defifnition. In case, there are multiple process definitions and some needs to be updates and some need not be. -- 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

19 years, 3 months

4
3
0 / 0

[JBoss JIRA] Created: (JBRULES-375) "?" doesn't seem to be recognized in the excel spreadsheet.

by wen Lin (JIRA)

"?" doesn't seem to be recognized in the excel spreadsheet. ------------------------------------------------------------- Key: JBRULES-375 URL: http://jira.jboss.com/jira/browse/JBRULES-375 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Decision tables Affects Versions: 3.0.1 Environment: window xp, eclipses-3.1.2 Reporter: wen Lin Assigned To: Mark Proctor In the action cell, I have int score = (i.getMyScore()< $param)? i.getMyScore(): $param; c.setAdjustScore(score); c.setFlag(false); modify( c ); and got the following errors: [mTokens]: line 25:39 state 0 (decisionfiltered=16) no viable alt line 25:39; char='?' [mTokens]: line 37:39 state 0 (decisionfiltered=16) no viable alt line 37:39; char='?' [mTokens]: line 49:39 state 0 (decisionfiltered=16) no viable alt line 49:39; char='?' [mTokens]: line 61:39 state 0 (decisionfiltered=16) no viable alt line 61:39; char='?' [mTokens]: line 73:39 state 0 (decisionfiltered=16) no viable alt line 73:39; char='?' [mTokens]: line 85:39 state 0 (decisionfiltered=16) no viable alt line 85:39; char='?' [mTokens]: line 97:39 state 0 (decisionfiltered=16) no viable alt line 97:39; char='?' Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token Rule Compilation error Syntax error on token ")", ? expected after this token ------------------------------------------------------------------ but the problem disappears while I use the following instead: c.setAdjustScore(Math.min(i.getMyScore (), $param)); --------------------------------------------------------------------------------------- It seems to me that either "?" is not recognized or "(a>b)? a:b" doesn't work ... -- 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

19 years, 3 months

4
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-607) Update the Messaging Lab page

by Ovidiu Feodorov (JIRA)

Update the Messaging Lab page ----------------------------- Key: JBMESSAGING-607 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-607 Project: JBoss Messaging Issue Type: Task Reporter: Ovidiu Feodorov Assigned To: Tim Fox Priority: Critical Fix For: 1.2.0.Alpha2 Update the content of the main lab page (http://labs.jboss.com/portal/jbossmessaging/) so it is consistent with the latest advances in the architecture. Damon offered to help with this. He will provide formatting and "look-and-feel" support. Tim will generate the content. -- 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

19 years, 3 months

7
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-643) Revise Empty Failed Queues

by Clebert Suconic (JIRA)

Revise Empty Failed Queues -------------------------- Key: JBMESSAGING-643 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-643 Project: JBoss Messaging Issue Type: Sub-task Reporter: Clebert Suconic Assigned To: Ovidiu Feodorov After we get the basics working, we will have to think about when/how to delete a queue without consumers. Router will still deliver messages to FailedOverQueues, even after there are no more clients on that queue. We will take care some of this with redelivery policies but we could just delete a queue after some time (+ transfering data to another LocalQueue) -- 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

19 years, 3 months

4
6
0 / 0

[JBoss JIRA] Created: (JBBUILD-323) JBossBuild needs to be able to calculate component version using highest common denominator algorithm

by Alex Pinkin (JIRA)

JBossBuild needs to be able to calculate component version using highest common denominator algorithm ----------------------------------------------------------------------------------------------------- Key: JBBUILD-323 URL: http://jira.jboss.com/jira/browse/JBBUILD-323 Project: JBoss Build System Issue Type: Feature Request Affects Versions: JBossBuild-1.1 DR2 Reporter: Alex Pinkin We've already had this discussion, and thought that it's not easy to implement. However, I do think we need this done since I don't want all projects to enumerate all their 3rd party dependencies in build-thirdparty.xml. Example: these products include the following javassist versions 1. aop 1.5.0.GA: javassist 3.2.0.CR1, 3.2.0.CR2, 3.3.0.GA 2. ws 1.0.0.GA: javassist 3.2.0.CR1, 3.2.0.CR2, 3.3.0.GA 3. ejb3 1.0.0.CR8: javassist 3.2.0.CR1, 3.2.0.CR2, 3.2.0.GA JBossBuild needs to be able to determine that javassist 3.2.0.CR2 is the highest common denominator. Current behaviour is that JBossBuild takes the highest version of the component whenever it runs into it for the first time during the dependency graph traversal. Does Maven already support this? It seems like this should be one of the core maven features. Could you please look more info feasibility of implementing this in JBossBuild? -- 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

19 years, 3 months

2
2
0 / 0

[JBoss JIRA] Created: (JBPM-788) [Identity component] ExpressionAssigmentHandler assigning group to pooled actors assigns group name not actors

by Luk Zdobylak (JIRA)

[Identity component] ExpressionAssigmentHandler assigning group to pooled actors assigns group name not actors -------------------------------------------------------------------------------------------------------------- Key: JBPM-788 URL: http://jira.jboss.com/jira/browse/JBPM-788 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Reporter: Luk Zdobylak Assigned To: Tom Baeyens FIle ExpressionAssigmentHandler.java from package org.jbpm.identity.assignment lines from 91-94 } else if (entity instanceof Group) { // put the group in the pool assignable.setPooledActors(new String []{entity.getName()}); } It seems that in line : assignable.setPooledActors(new String []{entity.getName()}); should be put not entity name but there should be code that retreives all actors assigned to group and prepares String[] array of their ids. -- 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

19 years, 3 months

3
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2006