May 2011 - jboss-jira - Jboss List Archives

[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

13 years, 8 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

13 years, 8 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

13 years, 8 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

13 years, 8 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

13 years, 8 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

13 years, 8 months

3
10
0 / 0

[JBoss JIRA] Created: (AS7-857) JMX related exception when starting OSGi subsystem

by David Bosschaert (JIRA)

JMX related exception when starting OSGi subsystem -------------------------------------------------- Key: AS7-857 URL: https://issues.jboss.org/browse/AS7-857 Project: Application Server 7 Issue Type: Bug Components: OSGi Affects Versions: 7.0.0.CR1 Reporter: David Bosschaert Assignee: Jason Greene Very often when the OSGi subsystem comes up, I'm seeing the following exception: 08:32:43,709 INFO [org.jboss.osgi.framework.internal.HostBundleState] (MSC service thread 1-1) Bundle started: org.apache.aries.jmx:0.1.0.incubating 08:32:43,710 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.compendium:service=cm,version=1.3 08:32:43,711 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.framework.BundleStateMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.core:type=bundleState,version=1.5 08:32:43,724 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.framework.ServiceStateMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.core:type=serviceState,version=1.5 08:32:43,725 INFO [org.apache.aries.jmx] (Thread-14) Registering org.osgi.jmx.service.cm.ConfigurationAdminMBean to MBeanServer org.jboss.as.jmx.tcl.TcclMBeanServer@7d093a with name osgi.compendium:service=cm,version=1.3 08:32:43,726 ERROR [org.apache.aries.jmx] (Thread-14) MBean is already registered: org.apache.felix.log.LogException: javax.management.InstanceAlreadyExistsException: osgi.compendium:service=cm,version=1.3 at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) [:1.6.0_23] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1484) [:1.6.0_23] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:963) [:1.6.0_23] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) [:1.6.0_23] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) [:1.6.0_23] at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [:1.6.0_23] at org.jboss.as.jmx.tcl.TcclMBeanServer.registerMBean(TcclMBeanServer.java:238) at org.apache.aries.jmx.agent.JMXAgentImpl.registerMBeans(JMXAgentImpl.java:129) at org.apache.aries.jmx.agent.JMXAgentContext.registerMBeans(JMXAgentContext.java:58) at org.apache.aries.jmx.MBeanServiceTracker$1.run(MBeanServiceTracker.java:61) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_23] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) [:1.6.0_23] at java.util.concurrent.FutureTask.run(FutureTask.java:138) [:1.6.0_23] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_23] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_23] at java.lang.Thread.run(Thread.java:662) [:1.6.0_23] -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[JBoss JIRA] Created: (JBRULES-2500) soundslike throws NullPointerException when one argument contains no consonants

by Steve Ronderos (JIRA)

soundslike throws NullPointerException when one argument contains no consonants ------------------------------------------------------------------------------- Key: JBRULES-2500 URL: https://jira.jboss.org/jira/browse/JBRULES-2500 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.0.1.FINAL Environment: mvel2-2.0.12 Reporter: Steve Ronderos Assignee: Mark Proctor When using soundslike, if one argument can't be handled by Soundex an Exception is thrown. My exact situation is that the 1st parameter (before the soundslike operator) resolves to a string that soundex does not support. It could be a string with only vowels, numbers and spaces. I would expect soundslike to simply return false. The stacktrace: java.lang.NullPointerException at org.drools.base.evaluators.SoundslikeEvaluatorsDefinition$StringSoundsLikeEvaluator.evaluate(SoundslikeEvaluatorsDefinition.java:148) at org.drools.rule.LiteralRestriction.isAllowed(LiteralRestriction.java:92) at org.drools.rule.LiteralConstraint.isAllowed(LiteralConstraint.java:109) at org.drools.rule.OrConstraint.__AW_isAllowed(OrConstraint.java:51) at org.drools.rule.OrConstraint.isAllowed(OrConstraint.java) at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:143) at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:42) at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:185) at org.drools.reteoo.EntryPointNode.__AW_assertObject(EntryPointNode.java:146) at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:1046) at org.drools.common.AbstractWorkingMemory.__AW_insert(AbstractWorkingMemory.java:1001) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java) at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:788) at org.drools.impl.StatelessKnowledgeSessionImpl.__AW_execute(StatelessKnowledgeSessionImpl.java:259) at org.drools.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java) I checked out the code and found that when soundex can not parse a string it returns null. I think this could be avoided by doing the Soundex.soundex(String) and checking for null before calling equals. I'll try to submit a patch if I have the time. -- 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

13 years, 8 months

4
5
0 / 0

[JBoss JIRA] Created: (JBRULES-2991) Operator soundslike is broken

by Tomáš Schlosser (JIRA)

Operator soundslike is broken ----------------------------- Key: JBRULES-2991 URL: https://issues.jboss.org/browse/JBRULES-2991 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Tomáš Schlosser Assignee: Mark Proctor Fix For: 5.2.0.M1 When trying to use soundslike operator in rule: rule "Soundslike1" agenda-group "Soundslike" when PetPerson( name soundslike "foobar" ) then #consequence end I get exception: Evaluator 'soundslike' does not support type 'ValueType = 'Object' : [Rule name='Soundslike1'] name is a String -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

4
6
0 / 0

[JBoss JIRA] Created: (JBRULES-2933) Problems adding a package with a collect statement after an OR'd group to a rulebase.

by Chris DeLashmutt (JIRA)

Problems adding a package with a collect statement after an OR'd group to a rulebase. ------------------------------------------------------------------------------------- Key: JBRULES-2933 URL: https://issues.jboss.org/browse/JBRULES-2933 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: drools-core Affects Versions: 5.2.0.M2 Reporter: Chris DeLashmutt Assignee: Mark Proctor When trying to use a rule with a collect statement after an OR'd group the compile of the package seems to work fine but when adding the compiled package to a RuleBase dynamically, the source for the collect statement seems to be lost. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
8
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2011