May 2011 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-2821) Race condition in MVELDialect

by Doug Pedrick (JIRA)

Race condition in MVELDialect ----------------------------- Key: JBRULES-2821 URL: https://jira.jboss.org/browse/JBRULES-2821 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-compiler Affects Versions: 5.1.1.FINAL Environment: JDK 1.6.0_20 Mac OS X 10.6.5 Reporter: Doug Pedrick Assignee: Mark Proctor Multiple threads loading different rulesets (each having local copies of KnowledgeBuilderConfiguration, KnowledgeBuilder, KnowledgeBaseConfiguration, and KnowledgeBase) can result in a race condition with the AbstractParser.OPERATIONS hash map in MVEL. MVELDialect and MVELExprAnalyzer both invoke ExpressionCompiler.compile. MVELDialect.compile calls AbstractParser.setLanguageLevel which clears and reloads the OPERATIONS static HashMap. It does so while holding COMPILER_LOCK. MVELExprAnalyzer calls ExpressionCompiler.compile without holding COMPILER_LOCK, resulting in OPERATIONS sometimes being empty when called, causing an NPE when attempting to autobox an Operator Integer to primitive. There are other areas in Drools code that ultimately depend on OPERATIONS and should be protected as well. java.lang.NullPointerException at org.mvel2.compiler.ExpressionCompiler._compile(ExpressionCompiler.java:250) at org.mvel2.compiler.ExpressionCompiler.compile(ExpressionCompiler.java:68) at org.drools.rule.builder.dialect.mvel.MVELExprAnalyzer.analyzeExpression(MVELExprAnalyzer.java:86) at org.drools.rule.builder.dialect.mvel.MVELDialect.analyzeExpression(MVELDialect.java:461) at org.drools.rule.builder.dialect.mvel.MVELDialect.analyzeExpression(MVELDialect.java:446) at org.drools.rule.builder.dialect.mvel.MVELPredicateBuilder.build(MVELPredicateBuilder.java:50) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:654) at org.drools.rule.builder.PatternBuilder.rewriteToEval(PatternBuilder.java:482) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:340) at org.drools.rule.builder.PatternBuilder.buildConstraint(PatternBuilder.java:264) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:213) at org.drools.rule.builder.PatternBuilder.build(PatternBuilder.java:108) at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69) at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:43) at org.drools.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:69) at org.drools.rule.builder.RuleBuilder.build(RuleBuilder.java:79) at org.drools.compiler.PackageBuilder.addRule(PackageBuilder.java:1154) at org.drools.compiler.PackageBuilder.addPackage(PackageBuilder.java:636) at org.drools.compiler.PackageBuilder.addPackageFromDrl(PackageBuilder.java:266) at org.drools.compiler.PackageBuilder.addKnowledgeResource(PackageBuilder.java:458) at org.drools.builder.impl.KnowledgeBuilderImpl.add(KnowledgeBuilderImpl.java:28) -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-3008) MVEL improvements: IndexedVariableResolverFactory updated and ParserConfiguration is now shared

by Mark Proctor (JIRA)

MVEL improvements: IndexedVariableResolverFactory updated and ParserConfiguration is now shared ----------------------------------------------------------------------------------------------- Key: JBRULES-3008 URL: https://issues.jboss.org/browse/JBRULES-3008 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assignee: Mark Proctor -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

1
2
0 / 0

[JBoss JIRA] Created: (AS7-804) SecurityException when DriverService stops

by Carlo de Wolf (JIRA)

SecurityException when DriverService stops ------------------------------------------ Key: AS7-804 URL: https://issues.jboss.org/browse/AS7-804 Project: Application Server 7 Issue Type: Bug Components: JCA Reporter: Carlo de Wolf Assignee: Stefano Maestri Attachments: org.jboss.as.test.surefire.servermodule.ServerInModuleDeploymentTestCase-output.txt {noformat} 23:37:46,128 WARN [org.jboss.msc.service.fail] MSC00004: Failure during stop of service jboss.jdbc-driver."org.h2.Driver".1.2: java.lang.SecurityException at java.sql.DriverManager.deregisterDriver(DriverManager.java:332) [:1.6.0_24] at org.jboss.as.connector.registry.DriverService.stop(DriverService.java:93) at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1779) [jboss-msc-1.0.0.Beta8.jar:1.0.0.Beta8] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24] at java.lang.Thread.run(Thread.java:662) [:1.6.0_24] {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

2
2
0 / 0

[JBoss JIRA] Created: (JBRULES-2139) Metaheuristic solver: research and development

by Geoffrey De Smet (JIRA)

Metaheuristic solver: research and development ---------------------------------------------- Key: JBRULES-2139 URL: https://jira.jboss.org/jira/browse/JBRULES-2139 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-solver Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Bilgin reported better results with metaheuristics on the PAS problem then tabu search, so it will probably be a good idea to implement a metaheuristics solver. -- 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

14 years, 12 months

1
8
0 / 0

[JBoss JIRA] Created: (JBRULES-1232) [solver] Selector refactor: configurable subset selections, topList usage etc

by Geoffrey De Smet (JIRA)

[solver] Selector refactor: configurable subset selections, topList usage etc ----------------------------------------------------------------------------- Key: JBRULES-1232 URL: http://jira.jboss.com/jira/browse/JBRULES-1232 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Currently all moves are evaluated at every step (with a MaxAllForager at least) if you use the basic cached move factory selector. This doesn't scale well, especially for big data problems where in the beginning, just about every moves improves. The neighbourhood size (= amount of selected moves) could for example increase block-wise or timeGradient-wise until an improving solution is found. Notice the difference with the usage of FirstImprovingForager. -- 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

14 years, 12 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-9356) Move the ejb3-async-deployer-jboss-beans.xml out of the jar so that it can be configured by users

by jaikiran pai (JIRA)

Move the ejb3-async-deployer-jboss-beans.xml out of the jar so that it can be configured by users -------------------------------------------------------------------------------------------------- Key: JBAS-9356 URL: https://issues.jboss.org/browse/JBAS-9356 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: EJB Affects Versions: 6.0.0.Final Reporter: jaikiran pai Assignee: jaikiran pai Fix For: 6.1.0 Currently the number of threads used by the ExecutorService for Async invocations on EJBs is configured within a jar JBOSS_HOME/server/<servername>/deployers/jboss-ejb3-async-deployer.jar/META-INF/ejb3-async-deployer-jboss-beans.xml making it difficult for users to configure (see the referenced forum thread for details). It would be better to move it outside the jar so that it can easily be configured by users. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2738) osgi-bundles: the slf4j and the ant version differ from the ones in the main drools build

by Geoffrey De Smet (JIRA)

osgi-bundles: the slf4j and the ant version differ from the ones in the main drools build ----------------------------------------------------------------------------------------- Key: JBRULES-2738 URL: https://jira.jboss.org/browse/JBRULES-2738 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Components: All Affects Versions: 5.1.1.FINAL Reporter: Geoffrey De Smet Assignee: Mark Proctor Priority: Minor Fix For: 5.2.0.M1 Since I am upgrading ant from 1.6.5 to 1.8.1 (to get the build working in maven 3), I noticed that osgi-bundles uses a totally different version: 1.71 <dependency> <groupId>org.apache.ant</groupId> <artifactId>com.springsource.org.apache.tools.ant</artifactId> <version>1.7.1</version> </dependency> Also, slf4j is 1.6 in drools, but 1.5.10 for the osgi-bundles. That could cause an ugly MethotNotFoundError at runtime (if someone on trunk start using the 1.6 new methods), or bugs with the osgi users which we can't reproduce in the non-osgi bundles. Mark, I am not sure how the osgi-bundles build works, but if you explain it's purpose to me, I can handle this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

2
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2555) Update slf4j to version 1.6.0

by Pablo Nussembaum (JIRA)

Update slf4j to version 1.6.0 ----------------------------- Key: JBRULES-2555 URL: https://jira.jboss.org/browse/JBRULES-2555 Project: Drools Issue Type: Task Security Level: Public (Everyone can see) Reporter: Pablo Nussembaum Assignee: Mark Proctor Update all references to slf4j to version 1.6.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

3
3
0 / 0

[JBoss JIRA] Created: (JBRULES-2758) matrix sytle decision tables do not have documentation

by kioto m (JIRA)

matrix sytle decision tables do not have documentation ------------------------------------------------------ Key: JBRULES-2758 URL: https://jira.jboss.org/browse/JBRULES-2758 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-api Affects Versions: 5.1.1.FINAL Reporter: kioto m Assignee: Mark Proctor Fix For: 5.1.1.FINAL We need to use matrix style decision table feature of Drools but it does not have any documentation. Below there exists related files but they are almost useless. If you still support this feature, then it will be great if you can supply documentation and examples for it. http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-decision... http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-decision... testLoadCustomListener() http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-decision.... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 12 months

3
7
0 / 0

[JBoss JIRA] Created: (JBRULES-2335) StackOverflowError on serialization of KnowledgeBase

by Justin Waugh (JIRA)

StackOverflowError on serialization of KnowledgeBase ---------------------------------------------------- Key: JBRULES-2335 URL: https://jira.jboss.org/jira/browse/JBRULES-2335 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Environment: Windows, JDK 1.6 Reporter: Justin Waugh Assignee: Mark Proctor This is a bit of a duplicate of another issue, which I will link, however I only tested against 5.0.1 and I have a proposed solution which I believe is only applicable to 5.0.1 + The problem is of course, that when serializing a KnowledgeBase with a very large amount of rules, it can potentially cause a StackOverflowError on serialization. As far as I can tell this is due to the linked lists held by ObjectSinkNodeList and LeftTupleSinkNodeList. The problem is that they recursively serialize the list, by serializing the first node, which serializes its next node, which serializes its next node.... and so on. This was a bit harder to solve in the 4.0+ case I think as it relied purely on the built in java serialization. However in 5.0+ those classes all use write/readExternal to do their own serialization. That makes it a bit easier to solve, as we can now implement an iterative serialization for the lists. The problem code looks like this: ObjectSinkNodeList (also applies to LeftTupleSinkNodeList): public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { firstNode = (ObjectSinkNode) in.readObject(); lastNode = (ObjectSinkNode) in.readObject(); size = in.readInt(); } public void writeExternal(ObjectOutput out) throws IOException { out.writeObject( firstNode ); out.writeObject( lastNode ); out.writeInt( size ); } AlphaNode (and all others implementing ObjectSinkNode, and similarly LeftTupleSinkNode): public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { super.readExternal( in ); constraint = (AlphaNodeFieldConstraint) in.readObject(); previousRightTupleSinkNode = (ObjectSinkNode) in.readObject(); nextRightTupleSinkNode = (ObjectSinkNode) in.readObject(); } public void writeExternal(ObjectOutput out) throws IOException { super.writeExternal( out ); out.writeObject( constraint ); out.writeObject( previousRightTupleSinkNode ); out.writeObject( nextRightTupleSinkNode ); } As you can see it recursively serializes the list, so the stack depth increases linearly with the list length. The solution is this: ObjectSinkNodeList (also applies to LeftTupleSinkNodeList): public void readExternal(ObjectInput in) throws IOException, ClassNotFoundException { firstNode = (ObjectSinkNode) in.readObject(); lastNode = (ObjectSinkNode) in.readObject(); size = in.readInt(); ObjectSinkNode current = firstNode; while(current != null) { ObjectSinkNode previous = (ObjectSinkNode) in.readObject(); ObjectSinkNode next = (ObjectSinkNode) in.readObject(); current.setPreviousObjectSinkNode(previous); current.setNextObjectSinkNode(next); current = next; } } public void writeExternal(ObjectOutput out) throws IOException { out.writeObject( firstNode ); out.writeObject( lastNode ); out.writeInt( size ); for (ObjectSinkNode node = firstNode; node != null; node = node.getNextObjectSinkNode()) { out.writeObject(node.getPreviousObjectSinkNode()); out.writeObject(node.getNextObjectSinkNode()); } } AlphaNode (and all others implementing ObjectSinkNode, and similarly LeftTupleSinkNode): public void writeExternal(ObjectOutput out) throws IOException { super.writeExternal( out ); out.writeObject( constraint ); } public AlphaNodeFieldConstraint getConstraint() { return this.constraint; } As you can see the responsibility for serializing the list node links is now placed into the list objects themselves, and is performed iteratively. I suppose technically the lastNode reference of the list doesn't need to be stored separately, but it was just easier code. The obvious concern here is if for some reason you had linked nodes which were not held by one of the list objects, then the links would be lost. However I checked references to the get/set of the prev/next, and they were only referenced by the list objects themselves, so I believe there is no chance for that to happen. I'll attach a test case (but it's just the one from the linked ticket) -- 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

14 years, 12 months

3
10
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 May 2011