[JBoss JIRA] Closed: (JBRULES-255) Dynamic index priorization
by Edson Tirelli (JIRA)
[ http://jira.jboss.com/jira/browse/JBRULES-255?page=all ]
Edson Tirelli closed JBRULES-255.
---------------------------------
Resolution: Rejected
New codebase makes this issue obsolete.
> Dynamic index priorization
> --------------------------
>
> Key: JBRULES-255
> URL: http://jira.jboss.com/jira/browse/JBRULES-255
> Project: JBoss Rules
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Reteoo
> Reporter: Edson Tirelli
> Assigned To: Edson Tirelli
> Priority: Minor
> Fix For: 3.1-m3
>
>
> All,
> Follows some thoughts about the current and future solutions for beta node memory indexing. Suggestions and opinions are welcome. Sorry for the long e-mail.
> I think a good way to discuss that is making an analogy to databases systems. As we all know, indexing is a great mechanism for performance improvements on database queries, but also represent a general overhead on other operations like insert, updates and deletes. Also, there is a memory consumption cost involved. A well planned set of indexes is essential for most enterprise applications and the responsibles for defining them are usually the DBAs. Once indexes are defined, when a query is executed against that database, a query planner component is used by database systems to estimate the best plan to run the query with the best performance, sometimes using the index, sometimes not.
> Well, working memory has the same issues and same thoughts are valid here. Drools 3 implemented an automatic indexing strategy to index beta node memories in order to boost performance. Just to have some data to understand the consequences of it, lets use Manners 64 benchmark test results on a Pentium IV 3Ghz HT machine with 1,0 Gb memory. This is not really a detailed benchmark test, but simply some rough numbers in order to every one understand what happened, what is happening, and possibly suggest some paths for the future. (times in milliseconds)
> Manners 64 without indexes: 135000 millisec to run
> Manners 64 with beta node indexes: 10500 millisec to run
> So, I think it is obviouse that indexes overall benefits pays off the overhead to keep them, at least in terms of performance. I'm not discussing limited memory enviroments here.
> During the last few days I started to play with indexing again and find some odd results. To understand them, let me first explain that a beta node memory might be indexed by one or more indexes. It all depends on how many BoundVariableConstraints that beta node will have. For instance:
> MyClass1( $myVal1 : attr1, $myVal2 : attr2 )
> MyClass2( attr1 == $myVal1, attr2 != $myVal2, attr3 == "bla", attr4 == 5 )
> The above rule would have a join node with two indexed constraints: attr1 == $myVal1, attr2 != $myVal2.
> What happens is that the engine is capable of indexing none of them, one of them, or both of them. The way it is today, it will always index by both of them.
> Just to investigate what are the indexing effects, I tried to make a code change to turn off multi-index for right beta memories. So, if a beta node has more than one constraint, I would elect one (arbitrarily) and index only that column. The result:
> Manners 64 with indexing without multi-index on RIGHT memories: 12000 millisec to run
> So, multi-index on right memories are good for manners. Then I turned on multi-index for right memories and turned off multi-index for left memories:
> Manners 64 with indexing without multi-index on LEFT memories: 9500 millisec to run
> So, basically, keeping multi-indexes for left memory on manners does not pay off the overhead.
> As you can realize by now, this is TOTALLY dependent on rules AND data asserted into memory. For a different ruleset, the results could be totally different.
> Besides that, somedays ago, a drools user reported an odd problem, that some may remember. He wrote a rule with the following column:
> 1. alarmdefine(alarmreason==reason, alarmlevel!=level)
> The rule was running very slowly for an average dataset (about 20 seconds). I sugested inverting the constraints to:
> 2. alarmdefine(alarmlevel!=level, alarmreason==reason)
> And the rule ran very fast (about 0.6 seconds). And the reason for this is because Drools has a fixed index ordering from last to first. So, for the first case above, where two indexes will be used (alarmreason and alarmlevel), drools will index the join node memory by [alarmlevel + alarmreason]. Nothing wrong so far, except that the data asserted into memory had all the same alarmlevel, so the index was adding overhead, but was completelly useless, as it was indexing the same value in all objects. (for more details on this subject, please look into list archive).
> Thinking about that, I devised a strategy to do dynamic indexing priorization. The idea is that at run time, when a new object or tuple reaches a beta node and looks for matches, the engine will dynamically elect and order indexes to that specific match. So in the above case, it would always elect alarmreason as the primary index, but if someone asserts a fact where the alarmlevel becomes the most restrictive index, for that instance only, the primary index would be alarmlevel.
> The result is that the rule runs in about 0.8 seconds for all cases, does not matter the way it is written.
> Manners 64 with indexing priorization: 12000 millisec
> As you can see, this dynamic indexing priorization has an overhead cost that allows one to not worry about how it is writing the rule, as long as he can accept a slowdown on performance.
> Thinking in all that, I see only 2 ways for drools to follow:
> 1. The first way is to allow users to fine tune their rules for best performance. This can be achieved making indexes as fast as possible and allowing the user to enable/disable/prioritize individual indexes on their rules. This is easier to implement, as only some syntax sugar needs to be supported by the parser, and the index factory needs access to the user definitions.
> 2. The second way would be to develop a so smart optimizer that it can decide when to use and when not to use indexes as well as which index to use in a similar way some databases do.The index priorization strategy I developed might be a rough start, but it is miles away from being the solution.
> Well, this is how things are on this area of development. My suggestion is, based on the results, not commit the index priorization stuff. I will just make a backup of it for future reference, but right now I think the overhead does not pay off. Better to educate users on how to write better rules for now.
> If anyone has or knows about good material on this area of knowledge, I would really appreciate links or suggestions.
> Let me know what you think.
--
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, 6 months
[JBoss JIRA] Created: (JGRP-299) NotificationBusDemo problem with 2.4CR2
by Christian Pekeler (JIRA)
NotificationBusDemo problem with 2.4CR2
---------------------------------------
Key: JGRP-299
URL: http://jira.jboss.com/jira/browse/JGRP-299
Project: JGroups
Issue Type: Bug
Affects Versions: 2.4
Environment: MacOSX, Java 1.5
Reporter: Christian Pekeler
Assigned To: Bela Ban
[/Users/christian/Projects/JGroups-2.4CR2.src]> java -cp dist/jgroups-all.jar:lib/commons-logging.jar:lib/concurrent.jar:lib/xalan.jar org.jgroups.demos.NotificationBusDemo
Starting NotificationBus with name BusDemo
Sep 5, 2006 4:56:53 PM org.jgroups.JChannel init
INFO: JGroups version: 2.4CR2
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
INFO: sockets will use interface 192.168.5.142
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
WARNING: traffic class of 8 could not be set, will be ignored
java.net.SocketException: Invalid argument
at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
at org.jgroups.protocols.UDP.createSockets(UDP.java:456)
at org.jgroups.protocols.UDP.start(UDP.java:383)
at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
at org.jgroups.stack.DownHandler.run(Protocol.java:118)
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
WARNING: traffic class of 8 could not be set, will be ignored
java.net.SocketException: Invalid argument
at java.net.PlainDatagramSocketImpl.socketSetOption(Native Method)
at java.net.PlainDatagramSocketImpl.setOption(PlainDatagramSocketImpl.java:299)
at java.net.DatagramSocket.setTrafficClass(DatagramSocket.java:1052)
at org.jgroups.protocols.UDP.createSockets(UDP.java:527)
at org.jgroups.protocols.UDP.start(UDP.java:383)
at org.jgroups.stack.Protocol.handleSpecialDownEvent(Protocol.java:589)
at org.jgroups.stack.DownHandler.run(Protocol.java:118)
Sep 5, 2006 4:56:53 PM org.jgroups.protocols.UDP createSockets
--
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, 6 months
[JBoss JIRA] Created: (JBRULES-481) LeftInputAdater.updateNewNode does incorrect propagation
by Mark Proctor (JIRA)
LeftInputAdater.updateNewNode does incorrect propagation
--------------------------------------------------------
Key: JBRULES-481
URL: http://jira.jboss.com/jira/browse/JBRULES-481
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 3.0.4
Reporter: Mark Proctor
Assigned To: Edson Tirelli
Fix For: 3.0.5, 3.1-m1
// Get the newly attached TupleSink
final TupleSink sink = (TupleSink) getTupleSinks().get( getTupleSinks().size() - 1 );
// Iterate the memory and assert all tuples into the newly attached TupleSink
final Map memory = (Map) workingMemory.getNodeMemory( this );
for ( final Iterator it = memory.values().iterator(); it.hasNext(); ) {
final LinkedList list = (LinkedList) it.next();
for ( LinkedListNode node = list.getFirst(); node != null; node = node.getNext() ) {
sink.assertTuple( (ReteTuple) ((LinkedListObjectWrapper) node).getObject(),
context,
workingMemory );
}
}
We get the last Sink but then we send through ALL tuples in the list to that single sink. yet we know that each tuple is for a specific sink. we instead should grab the handle and create a new tuple which we add to the list.
--
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, 6 months
[JBoss JIRA] Created: (JBRULES-542) Drools core 3.0.4 - Drools does not remove itself as a listener when Facts are Retracted
by Edson Tirelli (JIRA)
Drools core 3.0.4 - Drools does not remove itself as a listener when Facts are Retracted
----------------------------------------------------------------------------------------
Key: JBRULES-542
URL: http://jira.jboss.com/jira/browse/JBRULES-542
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Reteoo
Affects Versions: 3.0.4
Reporter: Edson Tirelli
Assigned To: Edson Tirelli
Fix For: 3.0.5
REPORTED BY TOM GONZALEZ:
---------------------------------------------
We are asserting facts that support property change listeners and found that Drools added itself as a listener just fine but failed to remove itself when the facts were retracted.
We have fixed the stated problem by modifying org.drools.common.AbstractWorkingMemory as follows:
Starting at line number 582:
protected void removePropertyChangeListener(final FactHandle handle) throws NoSuchFactObjectException {
Object object = null;
try {
object = getObject( handle );
final Method method = object.getClass().getMethod( "removePropertyChangeListener",
AbstractWorkingMemory.ADD_REMOVE_PROPERTY_CHANGE_LISTENER_ARG_TYPES );
method.invoke( object,
this.addRemovePropertyChangeListenerArgs );
Regards,
Tom G
--
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, 6 months
[JBoss JIRA] Created: (JBAS-3759) MalformedURLException for "jndi" protocol
by PickATrail (JIRA)
MalformedURLException for "jndi" protocol
-----------------------------------------
Key: JBAS-3759
URL: http://jira.jboss.com/jira/browse/JBAS-3759
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Web (Tomcat) service
Affects Versions: JBossAS-4.0.4.GA
Environment: Liinux (SuSE 10)
JVM: Java HotSpot(TM) Client VM (build 1.4.2_11-b06, mixed mode)
Reporter: PickATrail
Assigned To: Remy Maucherat
I am getting a MalformedURLException when I instantiate a URL with the "jndi" protocol. Here's some example JSP code:
final ServletContext ctx = session.getServletContext();
final String resourcePath = "/WEB-INF/web.xml";
final URL url = ctx.getResource(resourcePath);
final String externalForm = url.toExternalForm();
// The value of externalForm is something like
// "jndi:/localhost/problem/WEB-INF/web.xml".
// The following line fails under some specifi situation
// -- read on :)
new URL(externalForm);
This code usually works as expected. However, if I deploy and access the BIRT WebViewerExample application (BIRT
is an Eclipse.org project), the 'new URL("jndi:....")' line fails with the following stack trace:
java.net.MalformedURLException: unknown protocol: jndi
at java.net.URL.(URL.java:544)
at java.net.URL.(URL.java:434)
at java.net.URL.(URL.java:383)
at org.apache.jsp.index_jsp._jspService(...)
...
This is really puzzling because the URL class remembers theprotocol handlers, and I have already instantiated a URL for
"jndi" successfully.
I have tried to reproduce the problem on Tomcat 5.5.20 and 5.0.28, without success. So it seems to be a JBoss specific
problem. I'm using JBoss 4.0.4 GA on Linux; JVM build is 1.4.2_11-b06. The version of BIRT I use is 2.1.1.
-- Patrick Lai
--
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, 6 months
[JBoss JIRA] Created: (EJBTHREE-708) Bundled jboss-ejb3-all.jar is invalid in embeddable container
by Adrian Pillinger (JIRA)
Bundled jboss-ejb3-all.jar is invalid in embeddable container
-------------------------------------------------------------
Key: EJBTHREE-708
URL: http://jira.jboss.com/jira/browse/EJBTHREE-708
Project: EJB 3.0
Issue Type: Bug
Affects Versions: EJB 3.0 RC9 - FD
Environment: Linux, Maven, Java 5.
Reporter: Adrian Pillinger
Priority: Blocker
The classes that were bundled together to form the jboss-ejb3-all.jar of the embeddable container are not compatible.
I am calling the following code...
{code}
EJB3StandaloneBootstrap.boot(null);
Collection<URL> deployDirs = getDeployDirURLs();
Collection<URL> persistenceArchives = getPersistenceArchiveURLs();
deployer = EJB3StandaloneBootstrap.createDeployer();
.... get deploy dirs ..
deployer.getDeployDirs().addAll(deployDirs);
deployer.create();
deployer.start();
{code}
When the code gets to deployer.create(); it fails with the following stack trace
{noformat}
java.lang.NoSuchMethodError: org/jboss/ejb3/Ejb3Deployment.<init>(Lorg/jboss/ejb3/DeploymentUnit;Lorg/jboss/ejb3/EAR;)V
at org.jboss.ejb3.embedded.EJB3StandaloneDeployment.<init>(EJB3StandaloneDeployment.java:49)
at org.jboss.ejb3.embedded.EJB3StandaloneDeployer.create(EJB3StandaloneDeployer.java:438)
at com.dolby.pics.test.AbstractEJBTestCase.startupEmbeddedJboss(AbstractEJBTestCase.java:84)
at com.dolby.pics.test.TestSetupWrapper.setUp(TestSetupWrapper.java:32)
at junit.extensions.TestSetup$1.protect(TestSetup.java:22)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.extensions.TestSetup.run(TestSetup.java:27)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:210)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:135)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:122)
at org.apache.maven.surefire.Surefire.run(Surefire.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:615)
at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:225)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:747)
{noformat}
The error as you can see is an incompatability between
{noformat}
org.jboss.ejb3.embedded.EJB3StandaloneDeployment
{noformat}
and
{noformat}
org.jboss.ejb3.Ejb3Deployment
{noformat}
I'm guessing that these are from different jars and have been bundled into the same jar without a compile any tests to check that they are compatible.
My code worked absolutely fine with alpha 8 of the embeddable container.
--
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, 6 months
Mail delivery Error
by david
The received letter contained some errors. It is delivered as an attachment.
------
Mail server note.
19 years, 6 months
[JBoss JIRA] Resolved: (JBCACHE-13) Lazy loading: PojoCache and CacheLoader
by Ben Wang (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-13?page=all ]
Ben Wang resolved JBCACHE-13.
-----------------------------
Resolution: Done
Yes, the current "flat-space" mapping would mean when a POJO is passivated, then a user do:
pojo.getName();
only the pojo node will be loaded but not the other composite fields (e.g., Address). And if a user do:
pojo.getAddress().getCity();
only that composite field is loaded.
> Lazy loading: PojoCache and CacheLoader
> ---------------------------------------
>
> Key: JBCACHE-13
> URL: http://jira.jboss.com/jira/browse/JBCACHE-13
> Project: JBoss Cache
> Issue Type: Task
> Affects Versions: 1.2.4SP1
> Reporter: Bela Ban
> Assigned To: Ben Wang
> Fix For: 2.0.0.GA
>
> Original Estimate: 3 weeks
> Remaining Estimate: 3 weeks
>
> Idea is to have a configurable option that can be set either to eager or lazy loading. This can apply to whether it is with or without cache loader as well. For example, we may as well do the initial mapping lazily.
> Example:
> Person p = cache.getObject("/person");
> p.getName(); only primitive fields get loaded (not Address, e.g.)
--
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, 6 months
