January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-959) Investigate performance delta with MR3 and 3.0.6

by Michael Neale (JIRA)

Investigate performance delta with MR3 and 3.0.6 ------------------------------------------------ Key: JBRULES-959 URL: http://jira.jboss.com/jira/browse/JBRULES-959 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: All Affects Versions: 4.0.0.MR3 Reporter: Michael Neale Assigned To: Michael Neale // Rule execution time test // I give the DRL one fact of class BOBOMessage (made final due to Michael's suggestion) // The "message" member of my BOBOMessage fact contains a random combination of the keywords the rule is designed to match // A random BOBOMessage like that is generated before every execution // MR3's performance: 11:43:01,135 INFO [RuleLoadBean] Average rule execution time in ms: 2.3991 // What is measured: ruleBase = rsl.getGroupRuleBase(group); // That retrieves the RuleBase from the cache StatelessSession session = ruleBase.newStatelessSession(); session.execute(toBeAsserted.get(group.getId()).toArray()); // 3.0.6's performance: 12:09:40,446 INFO [RuleLoadBean] Average rule execution time in ms: 0.7726 // What is measured: ruleBase = rsl.getGroupRuleBase(group); // That retrieves the RuleBase from the cache WorkingMemory wm = ruleBase.newWorkingMemory(); for (Iterator j = toBeAsserted.get(group.getId()).iterator(); j.hasNext();) wm.assertObject(j.next()); wm.fireAllRules(); // The DRL: package com.smsc.mitto.rules import com.smsc.mitto.rules.client.BOBOMessage; import java.lang.String; rule "14" salience 0 activation-group "14" when m : BOBOMessage( message matches ".*BOBO.*") then System.out.println( "BOBO WAS SEEN" ); System.out.println( "BOBO WAS REALLY SEEN, DUDE" ); drools.setFocus( "17" ); end rule "17" salience -20 agenda-group "17" activation-group "17" when m : BOBOMessage( message matches ".*CACA.*") then System.out.println( "CACA WAS SEEN" ); drools.setFocus( "19" ); end rule "19" salience -10 agenda-group "19" activation-group "19" when m : BOBOMessage( message matches ".*BABA.*") then System.out.println( "BABA WAS SEEN" ); drools.setFocus( "21" ); end rule "19false" salience -20 agenda-group "19" activation-group "19" when eval(true) then drools.setFocus( "21" ); end rule "21" salience -20 agenda-group "21" activation-group "21" when m : BOBOMessage( message matches ".*BIBI.*") then System.out.println( "BIBI WAS SEEN" ); drools.setFocus( "23" ); end rule "21false" salience -30 agenda-group "21" activation-group "21" when eval(true) then drools.setFocus( "23" ); end rule "17false" salience -30 agenda-group "17" activation-group "17" when eval(true) then drools.setFocus( "23" ); end rule "23" salience -30 agenda-group "23" activation-group "23" when m : BOBOMessage( message matches ".*POOP.*") then System.out.println( "POOP WAS SEEN" ); drools.setFocus( "25" ); end rule "23false" salience -40 agenda-group "23" activation-group "23" when eval(true) then drools.setFocus( "25" ); end rule "14false" salience -10 agenda-group "14" activation-group "14" when eval(true) then drools.setFocus( "25" ); end rule "25" salience -10 agenda-group "25" activation-group "25" when m : BOBOMessage( message matches ".*SUPER.*") then System.out.println( "SUPER WAS SEEN" ); end -- 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

18 years, 5 months

4
8
0 / 0

[JBoss JIRA] Created: (JGRP-444) RequestCorrelator does not respect FLUSH.FlushHeader.BYPASS_FLUSH

by Michael Newcomb (JIRA)

RequestCorrelator does not respect FLUSH.FlushHeader.BYPASS_FLUSH ----------------------------------------------------------------- Key: JGRP-444 URL: http://jira.jboss.com/jira/browse/JGRP-444 Project: JGroups Issue Type: Bug Affects Versions: 2.5 Environment: 2.5 alpha 2 Reporter: Michael Newcomb Assigned To: Bela Ban private void handleRequest(Message req, Header hdr) { ... rsp=req.makeReply(); if(rsp_buf != null) rsp.setBuffer(rsp_buf); rsp_hdr=new Header(Header.RSP, hdr.id, false, name); rsp.putHeader(name, rsp_hdr); // *************** patch ***************** // can't check for FLUSH.FlushHeader.BYPASS_FLUSH because it has package protection, so just check for FLUSH header // if (req.getHeader(org.jgroups.protocols.pbcast.FLUSH.NAME) != null) { rsp.putHeader(org.jgroups.protocols.pbcast.FLUSH.NAME, new org.jgroups.protocols.pbcast.FLUSH.FlushHeader(org.jgroups.protocols.pbcast.FLUSH.FlushHeader.FLUSH_BYPASS)); } // *************** patch ***************** if(log.isTraceEnabled()) log.trace(new StringBuffer("sending rsp for ").append(rsp_hdr.id).append(" to ").append(rsp.getDest())); ... } -- 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

18 years, 5 months

3
10
0 / 0

[JBoss JIRA] Created: (JBAS-4242) Port Hibernate depoyer to VDF

by Scott M Stark (JIRA)

Port Hibernate depoyer to VDF ----------------------------- Key: JBAS-4242 URL: http://jira.jboss.com/jira/browse/JBAS-4242 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Deployment services, Hibernate service Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Scott M Stark Assigned To: Steve Ebersole Fix For: JBossAS-5.0.0.Beta3 The current hibernate integration tests are broken in jboss5 trunk, and the deployer needs to be ported to the VDF (http://wiki.jboss.org/wiki/Wiki.jsp?page=JBoss5DeploymentFramework). This really should be done in concert with the ejb3 deployer refactoring as there should be minimal duplication of the various deployment aspects related to persistence. -- 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

18 years, 5 months

4
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1307) Update and expand documentation for decision tables to show actual uses for all keywords

by John Scott (JIRA)

Update and expand documentation for decision tables to show actual uses for all keywords ---------------------------------------------------------------------------------------- Key: JBRULES-1307 URL: http://jira.jboss.com/jira/browse/JBRULES-1307 Project: JBoss Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.2 Environment: Drools 4.0.3, Rational Application Developer 7.0.0, XP SP2, Reporter: John Scott Priority: Minor I'm trying to implement a decision table for implementing some very simple rules. Currently I apparently am getting into what I believe is an infinite loop as the call never comes back from the fireAllRules method. I had this happen when I implemented the same rules as a DRL, but reading the documentation for the UNLOOP keyword, this is the only description: "Indicates that if there cell values in this column, the no-loop attribute should be set" In addition to the missing words (i.e. "If there ??? cell values..."), this is not very descriptive. Which column? What values? The no-loop attribute SHOULD be set? Would it be possible to show an example of where and how each of these keywords would be used? These keywords can exist at multiple levels of the XLS doc (i.e. the rule set, the rule, individual columns, etc.) so it's quite confusing as to the actual syntax of these. I haven't seen an example yet that uses UNLOOP, and the documentation (as stated above) is not very helpful as to how to implement this. Thanks -- 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

18 years, 6 months

4
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1174) Refactor EJB 3 onto ejb3-interceptors

by Carlo de Wolf (JIRA)

Refactor EJB 3 onto ejb3-interceptors ------------------------------------- Key: EJBTHREE-1174 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1174 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Assigned To: Carlo de Wolf -- 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

18 years, 6 months

2
17
0 / 0

[JBoss JIRA] Created: (JBRULES-1415) Certain uses of from causes NullPointerException in WorkingMemoryLogger

by Mattias Nilsson (JIRA)

Certain uses of from causes NullPointerException in WorkingMemoryLogger ----------------------------------------------------------------------- Key: JBRULES-1415 URL: http://jira.jboss.com/jira/browse/JBRULES-1415 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Reporter: Mattias Nilsson This rule causes a NullPointerException when WorkingMemoryFileLogger is activated. Without the logger the rule works fine. rule "TestRule" when A( theList : list ) B( theName : name ) from theList then System.out.println( "ok" ); end Seems to be the assigning of variable theName that causes the problem. If i remove "theName : name" there is no NullPointerException. Here is the stack trace: java.lang.NullPointerException at org.drools.base.com.sample.DroolsTest$B15799300$getName.getValue(Unknown Source) at org.drools.base.ClassFieldExtractor.getValue(ClassFieldExtractor.java:127) at org.drools.rule.Declaration.getValue(Declaration.java:197) at org.drools.audit.WorkingMemoryLogger.extractDeclarations(WorkingMemoryLogger.java:267) at org.drools.audit.WorkingMemoryLogger.activationCreated(WorkingMemoryLogger.java:201) at org.drools.event.AgendaEventSupport.fireActivationCreated(AgendaEventSupport.java:75) at org.drools.reteoo.RuleTerminalNode.assertTuple(RuleTerminalNode.java:331) . . . -- 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

18 years, 6 months

2
6
0 / 0

[JBoss JIRA] Created: (JGRP-662) max_bundle_size checks should only happen when bundling is enabled (either via conf file or JMX)

by Galder Zamarreno (JIRA)

max_bundle_size checks should only happen when bundling is enabled (either via conf file or JMX) ------------------------------------------------------------------------------------------------ Key: JGRP-662 URL: http://jira.jboss.com/jira/browse/JGRP-662 Project: JGroups Issue Type: Bug Affects Versions: 2.4.1 SP4 Reporter: Galder Zamarreno Assigned To: Bela Ban If enable_bundling is disabled (false), why does JGroups read max_bundle_size and max_bundle_timeout values? These max values are used within TP.Blunder but this is not created if bundling is disabled. JGroups should only read and make the necessary processing for max_bundle_size and max_bundle_timeout if bundling is enabled. I@ll fill in a JIRA for this. Seems like bundling could be enabled via dynamically via JMX (TPMBean). Maybe at this point JGroups should read the values from the configuration file. Alternatively, values could have already been read even if bundling was disabled, but calls like this in TP.setProperties: if(bundle_size > max_bundle_size) { if(log.isErrorEnabled()) log.error("max_bundle_size (" + bundle_size + ") is greater than largest TP fragmentation size (" + max_bundle_size + ')'); return false; } Should only happen if bundling was enabled either statically or dynamically via the MBean, specially since max_bundle_size value comes from a attempt to guess the maximum size of a Datagram packet by sending one, which is dynamic value that could change over time. -- 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

18 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (JBFORUMS-257) Not efficient admin view

by Ryszard Kozmik (JIRA)

Not efficient admin view ------------------------ Key: JBFORUMS-257 URL: http://jira.jboss.com/jira/browse/JBFORUMS-257 Project: JBoss Forums Issue Type: Bug Components: Forum Model Layer, Forum View Layer Reporter: Ryszard Kozmik Fix For: 1.0.1 RC, 1.1.0 Alpha When having lots of forums/categories in database, admin view breaks due to model layer problems. Probably something was messed up while doing view refactoring. -- 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

18 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-1327) drools-ant task and java.lang.ClassCastException: org.drools.reteoo.ReteooRuleBase

by Brugger Antony (JIRA)

drools-ant task and java.lang.ClassCastException: org.drools.reteoo.ReteooRuleBase ------------------------------------------------------------------------------------ Key: JBRULES-1327 URL: http://jira.jboss.com/jira/browse/JBRULES-1327 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.3 Environment: Windows XP / Eclipse 3.2 Reporter: Brugger Antony Priority: Blocker I try to use the drools-ant task to generate a package file like this: <target name="rules2" > <rulebase srcdir="../src/main/rules" tofile="../rulePackage/bcpRules.rules" classpathref="bcp.classpath" > <include name="testRuleBcp.drl" /> </rulebase> </target> it is working. But when I try to use it in my Java code with this code: RuleAgent agent = RuleAgent.newRuleAgent("/ruleAgent.properties"); RuleBase ruleBase = agent.getRuleBase(); ruleAgent.properties file: ## ## RuleAgent configuration file ## dir=./rulePackage poll=30 name=MyBcpConfig I have the following exception: RuleAgent(MyBcpConfig) INFO (Thu Nov 15 16:16:20 CET 2007): Configuring with newInstance=false, secondsToRefresh=30 RuleAgent(MyBcpConfig) INFO (Thu Nov 15 16:16:20 CET 2007): Configuring package provider : DirectoryScanner scanning dir: .\rulePackage found 1 file(s). java.lang.ClassCastException: org.drools.reteoo.ReteooRuleBase at org.drools.agent.FileScanner.readPackage(FileScanner.java:109) at org.drools.agent.FileScanner.getChangeSet(FileScanner.java:79) at org.drools.agent.FileScanner.loadPackageChanges(FileScanner.java:57 Indeed when I look at the code: - in the ant task org.drools.contrib.DroolsCompilerAntTask, this is a RuleBase object that is serialized: private void serializeRulebase(RuleBase ruleBase) throws FileNotFoundException, IOException { ObjectOutputStream outstream = null; try { FileOutputStream fout = new FileOutputStream(toFile); outstream = new ObjectOutputStream(fout); outstream.writeObject(ruleBase); } finally { if (outstream != null) { outstream.close(); } } } - in the ruleAgent class org.drools.agent.FileScanner is expecting a Package object to deserialized at line 109: p1_ = (Package) in.readObject(); hence the ClassCastException... -- 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

18 years, 6 months

3
3
0 / 0

[JBoss JIRA] Created: (JBAOP-495) run-precompiled refers wrong jar

by Oleg Mikheev (JIRA)

run-precompiled refers wrong jar -------------------------------- Key: JBAOP-495 URL: http://jira.jboss.com/jira/browse/JBAOP-495 Project: JBoss AOP Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.CR1 Reporter: Oleg Mikheev Priority: Minor run-precompiled.bar always results in class not found exception b/c it refers wrong jar in the classpath. it refers ..\lib-50\jboss-container-metadata-spi.jar while it is not present in lib-50 folder. it should either refer jboss-container.jar or jboss-container-metadata-spi.jar should be present. same story with run-precompiled.sh -- 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

18 years, 6 months

3
6
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 January 2008