[rules-users] WorkingMemoryFileLogger question
Am I totally missing something or is there not a way to stop logging of a stateful ks once you start doing so via the WorkingMemoryFileLogger (at least in Drools 5.2)? The Event Listeners that get registered when the file logger get created don't seem to ever be unregistered, and calling classes don't even have the visibility into the internals of the file logger in order to do so themselves. The use case for this is if you have a long running stateful session and you want to turn on logging just for a short period of time to collect some information, then turn logging off again. The only way I know of doing this currently is to reload the whole session. -- View this message in context: http://drools.46999.n3.nabble.com/WorkingMemoryFileLogger-question-tp3591898p3591898.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Implementation of not conditional expression
Any thoughts on using not CE's for gate facts? -- View this message in context: http://drools.46999.n3.nabble.com/Implementation-of-not-conditional-expression-tp3131856p3144732.html Sent from the Drools: User forum 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] Implementation of not conditional expression
How is the not conditional expression implemented? I am using it as a gate expression - I can't remember if that's the correct technical term or not, basically I'm using that expression to prevent the rules engine from having to evaluate additional expressions on the same rule which I know to be somewhat expensive and potentially frequently evaluated and added to the agenda, but only infrequently executed (due to highly dynamic facts). In the testing I have done, it seems to work well, but I'm not sure if there's a certain number of facts where the not CE calculation will outweigh the thing it's preventing. Is the not CE something that's optimized, or does the rules engine have to look through all the facts of that type to determine if the not CE is true? In my case there could be 10's of thousands of the fact on which I have the not CE. -- View this message in context: http://drools.46999.n3.nabble.com/Implementation-of-not-conditional-expression-tp3131856p3131856.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] M1 Vs CR1
http://docs.jboss.org/drools/release/5.2.0.CR1/droolsjbpm-introduction-docs/html_single/index.html#d0e47 has the highlights -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-M1-Vs-CR1-tp3067640p3069532.html Sent from the Drools: User forum 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] Evals in 5.2
Should evals be supported in 5.2 with the same syntax that was used in 5.1? I commented on https://issues.jboss.org/browse/JBRULES-3055, but I'm wondering if this is a bug or just an undocumented change due to the parser work in 5.2...? I haven't tested to see what usage of evals break in 5.2 that worked in 5.1, I just know that I had multiple compile errors using 5.2.0CR1 on rules that worked in 5.1 (and even in 5.2.0M2) that had a standalone eval pattern. The jira mentions the usage of && in the eval as the thing that causes it to break, but I haven't confirmed that. -- View this message in context: http://drools.46999.n3.nabble.com/Evals-in-5-2-tp3043452p3043452.html Sent from the Drools: User forum 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] 5.2CR1
Any idea when 5.2CR1 will be out? I started testing our app against 5.2M2 today.. no problems so far other than the performance test I did took about 2x as long using 5.2M2 as it did using 5.1. I know there are some performance regressions in 5.2M2 that were fixed in CR1 so I don't want to try troubleshooting something that have already been fixed. -- View this message in context: http://drools.46999.n3.nabble.com/5-2CR1-tp2967218p2967218.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Best performing way to process facts in a particular order?
Yes, I definitely do have to account for the min/max changing due to facts updating. How does drools handle the exists constraint internally? Is it able to take advantage of caching and the rete network or does it have to look through all the facts each time that rule is being evaluated? If that's the case, writing my own min/max accumulate might be more efficient that the approach of using an exists constraint to find the min/max fact. -- View this message in context: http://drools.46999.n3.nabble.com/Best-performing-way-to-process-facts-in-a-particular-order-tp2935847p2940505.html Sent from the Drools: User forum 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] Best performing way to process facts in a particular order?
I've been trying to optimize our stateful rules to run a bit faster, currently they can't quite keep up with the events coming into the session. A lot of our rules have to find the fact whose attribute is the smallest/largest value of all the facts of that type in working memory. I had originally written the rules to do a min accumulate to find the min value of the attribute, then a regular pattern to find the actual fact with that min value. Some of the fact types actually have two fields that must be used to find the min - think of them as a category and a score. For those I did two accumulate mins, one to find the lowest category, one to find the lowest score in that category, and then a third rule to find the fact with that min category and min score. I recently refactored all the rules to use the paradigm of one rule that matches the fact type I'm interested in, and a second rule that uses the not operator to express that there be no facts whose attribute is a higher value than the fact I just matched. In the contrived test I wrote, this seemed to perform better, but it's hard to tell if they are performing better or not with production data flowing through them. I know of a third option - writing my own accumulate functions - which I will probably try next. This should allow me to find the min/max fact with just one iteration over the facts, vs multiple iterations like my first approach. I don't know how it will compare to using the exists method though. Any feedback on these three different approaches? Any other ideas on the best way to do this? -- View this message in context: http://drools.46999.n3.nabble.com/Best-performing-way-to-process-facts-in-a-particular-order-tp2935847p2935847.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] 5.2.0.M2 issue using import functions
I remember reading some stuff about changes in 5.2 regarding a new strict mode - http://docs.jboss.org/drools/release/5.2.0.M2/drools-introduction-docs/html_single/index.html#d0e354 So it might be a compile warning/issue... which you could fix, or I think just turn off strict mode? -- View this message in context: http://drools.46999.n3.nabble.com/5-2-0-M2-issue-using-import-functions-tp2865621p2891587.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Drools Performance
Someone already mentioned writing "good" rules versus "bad" rules which is definitely critical - things like avoiding things like eval when possible. For our stateful rules session we took a lot of time in designing the architecture, facts, etc to avoid having to do any non-rules processing (db queries, updates, etc) in our rules session. Stateless rules sessions you can perhaps get away with a little more inefficiency since each request can operate in it's own thread independent of other requests. Regardless of stateless vs stateful you just have to be very conscious of how you write the LHS of your rules and avoiding time consuming activities in the RHS of your rules. -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Drools-Performance-tp2869875p2879354.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] accumulate min over java.util.Date
Ok so the take-away I get is that the docs could be updated since I'm sure many others like myself have assumed that the min or max accumulate functions will work for anything comparable. And yes, it would certainly be easy to write your own minDate accumulate function, or implement the min functionality just inside the accumulate (rather than using a accumulate function that does it for you). It would be more of a nice to have to have a pre-built accumulate function that works on comparable objects - making rules cleaner and easier especially for new rules writers - but certainly accomplishing the same task without them is no problem. Thanks again for the tips and discussion. -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/accumulate-min-over-java-util-Date-tp2726081p2736315.html 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
Re: [rules-users] accumulate min over java.util.Date
A couple things.. Regarding not being able to write constraints against what's returned from accumulate functions like min and max - in one particular use case (mine for example) this would not be a big deal. You are just trying to find the min/max of a collection of objects that are comparable. Not being able to do things like match based on intValue > someValue for the returned Number the way it currently does certainly would be a problem in some cases. I don't know enough yet about how drools does the object type pattern matching - so sorry if this is a dumb question =) , but if the accumulate functions just return something of type Object or Comparable, is there any way to do the from pattern matching like you can right now? Could you explicitly cast it somewhere? The fact that you could do this (the min/max type functionality across any comparable objects) with a custom accumulate function makes me think there has got to be a generic way of doing it without writing custom accumulation methods for each type... right? Although, even though min and max would technically apply to Dates, things like sum and average would not. So maybe we could have a couple generic min/max accumulate methods for anything comparable (which would allow you to get the min/max if you don't care about any of the details), then ones specific to Number (what exists right now), and possibly some more if there are other types that have commonly used accumulate actions. In one particular use Wolfgang Laun-2 wrote: > > 2011/3/25 Swindells, Thomas <tswinde...@nds.com> > > > I thought from was effectively typeless (as it’s operating against a > List > > it can’t always know the type of the members anyway) and so it allows > any > > type on teh left – giving a runtime class cast exception if it can’t > do the > > conversion. Therefore if you know they type you are expecting you can > still > > use it on the LHS with whatever constraints you want? > > > > Sure, "from" doesn't care what it produces, but accumulate > functions have to > return an object of some type. Currently. min and max return > java.lang.Double; therefore you can use java.lang.Number as a portmanteau > type. If min and max should include Data (and all other Comparable's), the > actual result type will have to be Comparable (or Object). > > -W > > > > > > > > Thomas > > > > > > > > *From:* rules-users-boun...@lists.jboss.org [mailto: > > rules-users-boun...@lists.jboss.org] *On Behalf Of *Wolfgang Laun > > *Sent:* 25 March 2011 09:23 > > *To:* Rules Users List > > *Subject:* Re: [rules-users] accumulate min over java.util.Date > > > > > > > > Now don't be hasty with a JIRA. Using Comparable for the arguments of > the > > min and max accumulate functions will give you a result that is -- > > Comparable. So: > > > > $min: Comparable() from accumulate( Schedule( $d: date ), min( $d ) > ) > > > > OK, this will give you the minimum data, bound to $min, although it > won't > > let you write any constraint for the "Comparable" result > fact. But, what's > > worse, it will not let you write > > > > $min: Number( intValue > 100 ) from accumulate( X( $y: y ), min( > $y ) ) > > > > any more (unless I'm very much mistaken). > > > > -W > > > > > > On 25 March 2011 03:56, Greg Barton <greg_bar...@yahoo.com> > wrote: > > > > Well, if it can work that way it should. I'd say open a JIRA and > request > > that feature. It works with the "principle of least > confusion." :) > > > > > > --- On Thu, 3/24/11, jkrupka <jkru...@gmail.com> wrote: > > > > > From: jkrupka <jkru...@gmail.com> > > > > > Subject: Re: [rules-users] accumulate min over java.util.Date > > > > > To: rules-users@lists.jboss.org > > > > > Date: Thursday, March 24, 2011, 8:26 PM > > > > > Yea the docs weren't really clear > > > about it, so I just thought it would work > > > for anything that implemented Comparable =) > > > > > > Yep, used the long from getTime() - not the prettiest way > > > of doing it, but > > > it works great. > > > > > > Thanks! > > > > > > -- > > > View this message in context: > > > http://drools-java-rules-engine.46999.n3.nabble.com/accumulate-min-over-java-util-Date-tp2726081p2728477.html > > > Sent from the Drools - User mailing list archive at > > > Nabble.com. > > > ___
Re: [rules-users] accumulate min over java.util.Date
Yea the docs weren't really clear about it, so I just thought it would work for anything that implemented Comparable =) Yep, used the long from getTime() - not the prettiest way of doing it, but it works great. Thanks! -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/accumulate-min-over-java-util-Date-tp2726081p2728477.html 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] accumulate min over java.util.Date
Should I be able to do an accumulate min over java.util.Date objects? Like this: $minDate : Date() from accumulate(MyFact ($startDate : startDate), min($startDate)) I would have thought so, but when I try it, I'm getting: Caused by: java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.Number at org.drools.base.accumulators.MinAccumulateFunction.accumulate(MinAccumulateFunction.java:76) If it should work, then it's possible I'm doing something else wrong, but everything looks correct to me. I can always work around it by getting the milliseconds from the Date object and doing the min over that... it's just not as clean looking. -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/accumulate-min-over-java-util-Date-tp2726081p2726081.html 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
Re: [rules-users] Best approach for handling parallel requests for a stateful rules session
Took a look... thanks. I'm not sure that they will help me though - do the async methods actually look to see if fireAllRules is already running somewhere else and synchronize the calls? Or do they just wrap a Callable around it so that if your rules take a long time to run you can do something else while they run? -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Best-approach-for-handling-parallel-requests-for-a-stateful-rules-session-tp2651617p2652011.html 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] Best approach for handling parallel requests for a stateful rules session
We've been over multiple ways of handling multiple parallel requests for a stateful rules session and I want to make sure the approach we have settled on makes sense. We will be getting multiple requests at a time to run some score calculation rules for various products. In the past we used stateless rules sessions to do this and it worked fine. In the newer version of our application we are using significantly more data to do our calculation and are pretty sure stateful is the way to go. That being said, can we use the same session in multiple threads? Based on our understanding, a session isn't inherently thread safe, so we are thinking we will need to do one of two things: 1. Synchronize all updates to facts and the calling of fireAllRules so that only one thread is doing this at a time. Is this the best (or only safe) approach in this situation? Since all fact updates and rules running in done in one thread, when is throughput a concern (obviously depends on hardware, # of rules, # of facts, etc)? 2. Ensure that only one thread updates the facts related to a given product at a time. Multiple threads could still call fireAllRules at the same time, but after the rules finish, the calling class would grab the facts that would have been updated for just the product that it's interested in. That way, it doesn't matter if the rules were technically matched in a different thread, as long as I'm grabbing just the data I'm interested in. Is this a safe approach? Does it end up offering more throughput capability than approach #1? Josh -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Best-approach-for-handling-parallel-requests-for-a-stateful-rules-session-tp2651617p2651617.html 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
