Re: [rules-users] documentation site
afaik, the right url is http://labs.jboss.com/drools On 9/4/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hello, the site http://labs.jboss.com/jbossrules/docs returns a 404. Anybody knoqws who to contact about this? ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] programmatic manipulation of 4.0 salience?
Scott, not sure if it fits your problem, but you may also consider using dynamic saliences. Yesterday I was able to convert 3.x rules to use it worked very well. In my case, I have facts of different sizes (some are collections of other facts, some are individual facts) and in some rules I need to find first MxN pairs (collection facts on both sides), then Mx1 or 1xN pairs, and only then 1x1 pairs. In other rules I need to find first 1x1 pairs, then Mx1 or 1xN pairs and only then MxN. Instead of writting a custom ConflictResolver, what I did was to use one dynamic salience: salience (1000 / (c.size * t.size)) for finding smallest pairs first, and salience (-1000 / (c.size * t.size) for finding the largest pairs first. The 1000 is to get around the fact that saliences are integers and not float/double (afaik) Hope it helps, -- yuri On 8/17/07, Manjax23 [EMAIL PROTECTED] wrote: Salience salience = new SalienceInteger( Integer.parseInt( salienceText ) ); rule.setSalience( salience ); Cheers, manjax23 Scott Reed-4 wrote: My 3.1 app has a mechanism that allowed the user to change the salience of some rules before running them, before loading up WorkingMemory. This was quite simple, rule.getSalience() returned a rule's int salience value and rule.setSalience(int) set it. Now in 4.0 I see salience is no longer just an int, but a Salience object with a simple constructor and complicated getValue(Tuple,WorkingMemory) method to access the int value. It appears to be still easy to set the salience of a rule: rule.setSalience( new SalienceInteger(int)) but getting the int salience from a Salience object seems to have been removed from joe-blow coder's reach. I would be very grateful if someone would provide me with an example that gets the int salience associated with a rule. I have no idea where or why I need to get the Tuple and WorkingMemory. Can I just pass nulls in for those two arguments? Thanks, Scott ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users -- View this message in context: http://www.nabble.com/programmatic-manipulation-of-4.0-salience--tf4283735.html#a12194345 Sent from the drools - user mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Fwd: Performance Tuning
second try... -- Forwarded message -- From: Yuri de Wit [EMAIL PROTECTED] Date: Aug 3, 2007 9:26 PM Subject: Performance Tuning To: Rules Users List rules-users@lists.jboss.org I am trying to improve performance on a Large DataSet, few Rules app and came accross these two properties, which by default is false: RuleBaseConfiguration.PROPERTY_INDEX_LEFT_BETA_MEMORY RuleBaseConfiguration.PROPERTY_HASH_ALPHA_NODES What do they mean actually? How and when should I use them? I am trying to chase a O(n^2) performance problem that I understand it is probably caused by the way I coded the rules, but it seems that I need to deepen my understanding to actually find the hotspots. Are there any techniques (that I probably dont know) that can help me find what rule(s) is causing the issue? As always thanks for previous answers - Yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Performance Tuning
I am trying to improve performance on a Large DataSet, few Rules app and came accross these two properties, which by default is false: RuleBaseConfiguration.PROPERTY_INDEX_LEFT_BETA_MEMORY RuleBaseConfiguration.PROPERTY_HASH_ALPHA_NODES What do they mean actually? How and when should I use them? I am trying to chase a O(n^2) performance problem that I understand it is probably caused by the way I coded the rules, but it seems that I need to deepen my understanding to actually find the hotspots. Are there any techniques (that I probably dont know) that can help me find what rule(s) is causing the issue? As always thanks for previous answers - Yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] correlating two collects
I am finally having some time to use collects. What I basically need to do is to collect items from a list using a specific criteria, then collect items from a diff list using another criteria, and finally compare the groups collected using a 3rd criteria Here is what I am thinking: i : Item(type==A) ig : ItemGroup(size1) collect Item(a==i.a, b==i.b, ... n==i.n) i2: Item(type==B) ig2 : ItemGroup( size1, ga==ig.ga, gb==i.gb, ) collect Item(a==i.a, b==i.b, ... n==i.n) 1) It is quite nice that any implementation of java.util.Collection can be the resut of collect. ItemGroup here not only keeps hold of all Items returned but has some aggregate properties (afaik, I cannot use the aggregate functions with accumulate since I have multiple column aggregation). 2) Am I on the right track? Or is there a better way? 3) Is the collect recomputed from scratch or incrementally every time a new fact is asserted or updated? thanks ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Fwd: Few rules, many facts
I am working on a drools application with few rules and large number of facts. In my first design I tried to avoid excessive joins thinking I was helping improve performance but didnt realized that I was actually shooting myself in the foot. I was basically creating a single facade-fact that would contain two or three diff concerns joined under the same interface. The problem I am seeing is that for simple things like changing the status of one of many facts would cause that fact to be reevaluated against all the other facts. I then realized that thinking relationally about the problem would not only simplify my solution but also probably make a lot faster. However, in this new and relational solution I will need to make use of many not CE. My question is: is there any cost in using nots that I should be awae of? Any other words of wisdom re: improving the performance in small rules x many facts? thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Few rules, many facts
I am working on a drools application with few rules and large number of facts. In my first design I tried to avoid excessive joins thinking I was helping improve performance but didnt realized that I was actually shooting myself in the foot. I was basically creating a single facade-fact that would contain two or three diff concerns joined under the same interface. The problem I am seeing is that for simple things like changing the status of one of many facts would cause that fact to be reevaluated against all the other facts. I then realized that thinking relationally about the problem would not only simplify my solution but also probably make a lot faster. However, in this new and relational solution I will need to make use of many not CE. My question is: is there any cost in using nots that I should be awae of? Any other words of wisdom re: improving the performance in small rules x many facts? thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Fwd: [rules-users] Predicate expression effect on performance
(there is definetely a problem posting to this list) -- Forwarded message -- From: Yuri de Wit [EMAIL PROTECTED] Date: Jul 20, 2007 7:22 AM Subject: Fwd: [rules-users] Predicate expression effect on performance To: Rules Users List rules-users@lists.jboss.org forgive the (possible) double posting, but often posts take a while to show up -- Forwarded message -- From: Yuri de Wit [EMAIL PROTECTED] Date: Jul 20, 2007 1:17 AM Subject: Re: [rules-users] Predicate expression effect on performance To: Rules Users List rules-users@lists.jboss.org (sorry, the OR was not part of the sample rule: I was just considering the same rule written in two different ways) I am seeing a considerable performance problem with my rules and I am trying to narrow down why. I have a small number or rules but hundreds of thousands of facts. At first the assertion goes very fast but it quickly degrades as more facts are asserted. I already reordered the predicates (I have between 8-12 predicates in most rules and reordered them more restrictive first) and saw some improvements, but not nearly enough. Then thought about to what extent predicate expressions where hitting me. Per what you say that cant be the reason. If Check is updated (as you mentioned) would that be equivalent to reasserting it into memory? I keep a status as a property of Check that get updated somewhat often. thanks, On 7/20/07, Michael Neale [EMAIL PROTECTED] wrote: In a sense, yes - but its the result of the comparison that is cached really. In the case you described, it is subrule generation. So either side of the or is like a separate rule. In version 3, the result of isSameAmount (ie if it was true or false) is cached. Things will only be re-checked if the Check fact changes (and the engine knows about the change). Note that this checking happens as you are asserting objects, not when you fireAllRules necessarily. On 7/20/07, Yuri de Wit [EMAIL PROTECTED] wrote: What is the extent of the performance impact caused by using predicate expressions? Check( amount == $amount ) or Check( $amt : amount - (isSameAmount($amt, $amount) ) My understanding is that once asserted the amount property will be cached in the shadow fact, is the result of isSameAmount(...) also cached? thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Fwd: [rules-users] Predicate expression effect on performance
(well, I'll keep trying) -- Forwarded message -- From: Yuri de Wit [EMAIL PROTECTED] Date: Jul 20, 2007 1:17 AM Subject: Re: [rules-users] Predicate expression effect on performance To: Rules Users List rules-users@lists.jboss.org (sorry, the OR was not part of the sample rule: I was just considering the same rule written in two different ways) I am seeing a considerable performance problem with my rules and I am trying to narrow down why. I have a small number or rules but hundreds of thousands of facts. At first the assertion goes very fast but it quickly degrades as more facts are asserted. I already reordered the predicates (I have between 8-12 predicates in most rules and reordered them more restrictive first) and saw some improvements, but not nearly enough. Then thought about to what extent predicate expressions where hitting me. Per what you say that cant be the reason. If Check is updated (as you mentioned) would that be equivalent to reasserting it into memory? I keep a status as a property of Check that get updated somewhat often. thanks, On 7/20/07, Michael Neale [EMAIL PROTECTED] wrote: In a sense, yes - but its the result of the comparison that is cached really. In the case you described, it is subrule generation. So either side of the or is like a separate rule. In version 3, the result of isSameAmount (ie if it was true or false) is cached. Things will only be re-checked if the Check fact changes (and the engine knows about the change). Note that this checking happens as you are asserting objects, not when you fireAllRules necessarily. On 7/20/07, Yuri de Wit [EMAIL PROTECTED] wrote: What is the extent of the performance impact caused by using predicate expressions? Check( amount == $amount ) or Check( $amt : amount - (isSameAmount($amt, $amount) ) My understanding is that once asserted the amount property will be cached in the shadow fact, is the result of isSameAmount(...) also cached? thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Predicate expression effect on performance
What is the extent of the performance impact caused by using predicate expressions? Check( amount == $amount ) or Check( $amt : amount - (isSameAmount($amt, $amount) ) My understanding is that once asserted the amount property will be cached in the shadow fact, is the result of isSameAmount(...) also cached? thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Predicate expression effect on performance
(sorry, the OR was not part of the sample rule: I was just considering the same rule written in two different ways) I am seeing a considerable performance problem with my rules and I am trying to narrow down why. I have a small number or rules but hundreds of thousands of facts. At first the assertion goes very fast but it quickly degrades as more facts are asserted. I already reordered the predicates (I have between 8-12 predicates in most rules and reordered them more restrictive first) and saw some improvements, but not nearly enough. Then thought about to what extent predicate expressions where hitting me. Per what you say that cant be the reason. If Check is updated (as you mentioned) would that be equivalent to reasserting it into memory? I keep a status as a property of Check that get updated somewhat often. thanks, On 7/20/07, Michael Neale [EMAIL PROTECTED] wrote: In a sense, yes - but its the result of the comparison that is cached really. In the case you described, it is subrule generation. So either side of the or is like a separate rule. In version 3, the result of isSameAmount (ie if it was true or false) is cached. Things will only be re-checked if the Check fact changes (and the engine knows about the change). Note that this checking happens as you are asserting objects, not when you fireAllRules necessarily. On 7/20/07, Yuri de Wit [EMAIL PROTECTED] wrote: What is the extent of the performance impact caused by using predicate expressions? Check( amount == $amount ) or Check( $amt : amount - (isSameAmount($amt, $amount) ) My understanding is that once asserted the amount property will be cached in the shadow fact, is the result of isSameAmount(...) also cached? thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Dynamic JavaBeans
I am not talking about assert, but modify. I have a dynamic fact already asserted but now I need to perform N changes on N different properties on the same object on the same consequence. Drools is going to traverse the RETE network N times once for each time the PropertiesListener is called (each setProperty called). -- yuri On 6/28/07, Mark Proctor [EMAIL PROTECTED] wrote: Why would doing the assert work at the end of the consequence be any quicker than doing it during the consequence? Mark Yuri de Wit wrote: I noticed that changes performed on facts asserted dynamically causes the fact to be modified right away and therefore triggering a RETE network traversal and rule schedulings. For apps with a large number of facts this could be a significant scalability problem. At least in my case, I would like to be able to use dynamic facts and perform any number of updates and have those updates commited to working memory only when the rule consequence is completed. Looking at the code, it seems that it would not be a major effort to collect the facts received by the ReteooWorkingMemory.propertyChange and perform the actual modifyObject() only when the consequence evaluation is actually completed. Does that makes sense? Or are there side effects I am not seeing? Is this a problem that 4.0 already resolves? thanks in advance, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Dynamic JavaBeans
Sure. The solution I am taking right now is dont use dynamic properties, which is not optimal (depending on the problem property changes not being batched defeats the purpose of dynamic beans). The bottom line is that I was hoping that this feature would (1) either already be taken care of in 4.0 or (2) become a feature request for future releases. -- yuri On 6/28/07, Mark Proctor [EMAIL PROTECTED] wrote: No we don't do anything to batch property change listener results. But maybe you can do this yourself. instead of calling modify, add it to a transaction list (that you make available in the current context). Then at the end of the consequence you can iterate that list and call modify on each object. Or alternatively don't use dynamic properties. Mark Yuri de Wit wrote: I am not talking about assert, but modify. I have a dynamic fact already asserted but now I need to perform N changes on N different properties on the same object on the same consequence. Drools is going to traverse the RETE network N times once for each time the PropertiesListener is called (each setProperty called). -- yuri On 6/28/07, Mark Proctor [EMAIL PROTECTED] wrote: Why would doing the assert work at the end of the consequence be any quicker than doing it during the consequence? Mark Yuri de Wit wrote: I noticed that changes performed on facts asserted dynamically causes the fact to be modified right away and therefore triggering a RETE network traversal and rule schedulings. For apps with a large number of facts this could be a significant scalability problem. At least in my case, I would like to be able to use dynamic facts and perform any number of updates and have those updates commited to working memory only when the rule consequence is completed. Looking at the code, it seems that it would not be a major effort to collect the facts received by the ReteooWorkingMemory.propertyChange and perform the actual modifyObject() only when the consequence evaluation is actually completed. Does that makes sense? Or are there side effects I am not seeing? Is this a problem that 4.0 already resolves? thanks in advance, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Dynamic JavaBeans
I noticed that changes performed on facts asserted dynamically causes the fact to be modified right away and therefore triggering a RETE network traversal and rule schedulings. For apps with a large number of facts this could be a significant scalability problem. At least in my case, I would like to be able to use dynamic facts and perform any number of updates and have those updates commited to working memory only when the rule consequence is completed. Looking at the code, it seems that it would not be a major effort to collect the facts received by the ReteooWorkingMemory.propertyChange and perform the actual modifyObject() only when the consequence evaluation is actually completed. Does that makes sense? Or are there side effects I am not seeing? Is this a problem that 4.0 already resolves? thanks in advance, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Fwd: Dynamic JavaBeans
Sorry if this gets second posted, but it seems that the first one didnt go through... -- Forwarded message -- From: Yuri de Wit [EMAIL PROTECTED] Date: Jun 27, 2007 8:29 PM Subject: Dynamic JavaBeans To: Rules Users List rules-users@lists.jboss.org I noticed that changes performed on facts asserted dynamically causes the fact to be modified right away and therefore triggering a RETE network traversal and rule schedulings. For apps with a large number of facts this could be a significant scalability problem. At least in my case, I would like to be able to use dynamic facts and perform any number of updates and have those updates commited to working memory only when the rule consequence is completed. Looking at the code, it seems that it would not be a major effort to collect the facts received by the ReteooWorkingMemory.propertyChange and perform the actual modifyObject() only when the consequence evaluation is actually completed. Does that makes sense? Or are there side effects I am not seeing? Is this a problem that 4.0 already resolves? thanks in advance, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] ClassCastException using WorkingMemoryFileLogger (3.0.6)
I got a ClassCastException once I ran my app with the WorkingMemoryFileLogger attached to it. After a bit of debugging the CCE is being thrown because for an unknown reason the column of a Declaration is wrong: it should have been 0 like all the other declarations on the same Fact, but it is 0 instead. It seems that column is wrongly set when building the rule package, even before evaluating. What I dont understand is why this is happening and why I dont see the problem when I remove the WorkingMemoryFileLogger from the picture. The rules goes a bit like this: rule when Fact1(var1: a, var2: b, var3: c) c : ( Setting( x==1, y==2, z==3) or Setting( x==1, y==2, z==ANY) or Setting( x==1, y==ANY, z==ANY) or Setting( x==ANY, y==ANY, z==ANY) ) not Fact2( a == var1, b== var2, c==var3) then ... end The declarations for a and b, for instance are referring to the right column, but c doesnt. BTW: Does any one know of a better pattern for implementing cascading settings? The biggest problem I am facing is that I need to replicate the long list or OR Settings for each rule that needs to check for them (the actual settings depend on fact properties). Here is the exception: org.drools.spi.ConsequenceException: java.lang.ClassCastException: com at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:441) at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:407) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:268) at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:255) ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Managing Collection Facts
Hi, I have to create a set of rules that group facts together based on a dynamic criteria X basd on fact data. So I created a rule to create a first collection for the criteria X when no collection exist. I created a second rule to add a fact to an existing collection, but I cant get my head around how to create a rule that takes facts out of the collection if a fact is updated and no longer satisfies X. Note that the criteria X is a combination of 7-10 field equality. rule when f:Fact1(var1: a, var2:b) not FactCollection( a == var1, b == var2, fs:facts - (fs.contains(f) == true) ) then ... assert(new FactCollection(f)); end rule when f:Fact1(var1: a) c:FactCollection( a == var1 ) then c.add(f); modify(c); modify(f); end rule when f:Fact1(id:id, type=UPDATE, var1: a) f2:Fact1(id == id, a == var1, b == var2) fs:FactCollection( not(a == var1, b == var2), fs:facts - (fs.contains(f2) == true) then fs.remove(f2); modify(fs); end Since I dont want to create a rule for each combination of a != var1, b == var2, a == var1, b != var2 (I have 7-10 individual conditions), but I do want to check whether the collection contains f2 what else to do? any ideas? ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Debugging Rule Activations and Cancellations
I am working on an appication that does not have many rules 40-50 rules but each rule has between 1 to 2 pages of columns and predicates, but have thousands of facts. Even though by using the DefaultAgendaListener I can figure the rules that were added or removed from the agenda while fact are asserted it is sometimes time consuming to figure out among those 1 or 2 pages of predicates on each rule why some one did or did not activate. I was wondering if there is a better way to know why a rule was added or removed from the agenda. Maybe a report or a callback showing the precicates evaluated and the one that failed with the fact that cause it to fail. Forgive me if there is already a way or procedure I should follow to accomplish the above. thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Inspecting Working Memory
I usually have thousands of facts in Working memory and at some points I need to figure out why this or that wasnt activated or sometime I just want to know (ad-hoc) if such and such fact is already asserted into memory. It would be great if I could at any point in time use a JBoss rules console attached to a given working memory and issue ad hoc queries. Just a thought. thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Operators
Great. thanks, -- yuri On 6/16/07, Mark Proctor [EMAIL PROTECTED] wrote: We've have plans for pluggeable operators, just no time to implement them, maybe in the next release :) Mark Yuri de Wit wrote: I am using JBoss Rules 3.0.6 and in many situations I was forced to use a Java snipped predicates ( p.property - ( fn.doSomething(p, a)) which clutters the rules quite a bit ) to override or correct the behaviour of some of the operators such as ==, !=, etc. It would be nice if there was an easy way for me to override them by providing my own implementation. I could then subclass the default one provided by JBoss Rules and customized the ones I need. I know that this sugestiong would allow us to modify the semantic of the rules language operators but it at least would provide a nice way out of issues (such as using == between a Short and a Integer) we come accross, could help debugging predicate evaluations (I guess I could always add a breakpoint to a specific class from the rules engine - which class?). On the same topic would it be possible to add new operators to the language? thanks, -yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Inspecting Working Memory
Afaik, the query api (1) does not accept parameters (this is an ad-hoc query with inputs coming ) and (2) there is no way to issue dynamic queries against an existing working memory. yuri On 6/16/07, Mark Proctor [EMAIL PROTECTED] wrote: There is a query api, you can use that to find out what is currently in the working memory. Mark Yuri de Wit wrote: I usually have thousands of facts in Working memory and at some points I need to figure out why this or that wasnt activated or sometime I just want to know (ad-hoc) if such and such fact is already asserted into memory. It would be great if I could at any point in time use a JBoss rules console attached to a given working memory and issue ad hoc queries. Just a thought. thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Inspecting Working Memory
Ideally, It would be great to be able to use a command line tool that connects to a running process and issues query ... end queries sends it to the server, evaluates it and come back with the results. I would be tremendously useful in my case and I was just wondering if other people had the same need. thanks, -- yuri On 6/16/07, Yuri de Wit [EMAIL PROTECTED] wrote: Afaik, the query api (1) does not accept parameters (this is an ad-hoc query with inputs coming ) and (2) there is no way to issue dynamic queries against an existing working memory. yuri On 6/16/07, Mark Proctor [EMAIL PROTECTED] wrote: There is a query api, you can use that to find out what is currently in the working memory. Mark Yuri de Wit wrote: I usually have thousands of facts in Working memory and at some points I need to figure out why this or that wasnt activated or sometime I just want to know (ad-hoc) if such and such fact is already asserted into memory. It would be great if I could at any point in time use a JBoss rules console attached to a given working memory and issue ad hoc queries. Just a thought. thanks, -- yuri ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
