Re: [rules-users] fireUntilHalt and timing of rule activations
Another solution would be to have a simple rule matching an Object
that is a container of facts:
rule "synced bunch insert"
when
$fc : FactContainer( $facts : facts )
then
for( Object $f : $facts ){ insert( $f ); }
retract( $fc );
end
Threads just insert a FactContainer; so this is synced in all ways.
BTW: Having a session run continuously in a thread of its own may be a
necessity if there are timers active; thus just using fireAllRules may
not be a solution in all situations.
-W
On 6 October 2010 10:15, Swindells, Thomas wrote:
> I'd suggest that it may be simple to have a (synchronized) helper method
> which you call to insert your objects.
> This method would create a batch command containing an insert command and a
> fireAllRules command. You only need to fire the rules after you have changed
> something and this approach removes all multithread access into the working
> memory.
>
> Thomas
>
>> -Original Message-
>> From: rules-users-boun...@lists.jboss.org [mailto:rules-users-
>> boun...@lists.jboss.org] On Behalf Of Edson Tirelli
>> Sent: 06 October 2010 01:28
>> To: Rules Users List
>> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>>
>> Norman,
>>
>> What you say makes sense, but it is not implemented. It is
>> something I think would be good to have. May I suggest you open a JIRA
>> for it so we track it?
>>
>> Meanwhile, the workaround I suggest is that instead of using
>> fireUntilHalt(), you call fireAllRules() in a loop, either after each
>> X insertions of every Y seconds, depending on your system's
>> architecture.
>>
>> Edson
>>
>>
>> 2010/10/5 Norman C :
>> >
>> > Thanks for the suggestions. They all look like good ways to handle the
>> > situation I described. However, they require modifying all of the rules to
>> > check for the latch object and its state, which I would prefer not to do
>> > and
>> > doesn't seem like would be necessary.
>> >
>> > It seems to me that this is something that Drools can handle internally
>> > without the rules having to be written this way. Since the rules engine
>> > processes rules in a single thread, it's a concurrency issue.
>> > fireUntilHalt
>> > should be blocked when a fact is inserted/updated/retracted, until all
>> > activations as a result of that change in working memory are completed.
>> >
>> > Thoughts?
>> >
>> >
>> >
>> > Norman
>> >
>> >
>> > From: Wolfgang Laun
>> > To: Rules Users List
>> > Sent: Sun, October 3, 2010 10:51:08 PM
>> > Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> >
>> > 2010/10/4 Greg Barton
>> >>
>> >> If you don't have some way of associating the data with a particular Latch
>> >> it's easy to get overlap when processing datasets. In general you need
>> some
>> >> way to group the data together. You can avoid a back reference to the
>> Latch
>> >> by having a Set of some sort in the Latch to which you add all data in the
>> >> batch.
>> >
>> > Which burdens all inserts and retracts to be accompanied by correpsonding
>> > updates of the Set/Map.
>> >
>> >>
>> >> If you use a Set backed by an IdentityHashMap the overhead is pretty
>> >> small, and rules look like this:
>> >>
>> >> rule "CountAs"
>> >> dialect "java"
>> >> salience -1
>> >> when
>> >> l : Latch()
>> >> a : A( this memberOf l.dataSet )
>> >> then
>> >> retract(a);
>> >> l.incACount();
>> >> System.out.println("Found an A in " + l);
>> >> end
>> >>
>> >> See attached project.
>> >>
>> >> THough I like the cleverness of using the "data in matched objects alters
>> >> rule properties" trick, you could have just as easily had a "Latch(value
>> >> ==
>> >> true)" conditional, and that would be more clear,
>> >
>> > It was meant to emphasize the role of Latch.value as an enabler for the
>> > rule
>> > in contrast to a regular constraint being part of the application logic.
>> > YMMV ;-)
>> >
>> >
>> >>
>> >> IMO. I'm curious to see of the enabled trick would perform better,
>> >> though.
>> >
>> > Whichever way, there is a considerable burden associated with writing the
>> > rules and, possibly, inserts and retracts. I wonder what the benefits of
>> > having the session run all the time are as opposed to simply let it fire
>> > until it stops; then do the inserts and then fireUntilHalt again? If there
>> > is, I'd opt for the addition of an atomic insertAll(Object... objects) and
>> > then none of this hocus-pocus would be necessary.
>> >
>> > -W
>> >
>> >>
>> >> GreG
>> >>
>> >> --- On Sun, 10/3/10, Wolfgang Laun wrote:
>> >>
>> >> From: Wolfgang Laun
>> >> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>> >> To: "Rules Users List"
>> >> Date: Sunday, October 3, 2010, 4:23 AM
>> >>
>> >> There is another way of associating a Latch object with rules, without
>> >> having to store a reference to a
Re: [rules-users] Drools and JBoss 6.0 Support
Hello, Is there any update to this? I'm trying to get Drools-Guvnor 5.0.1 to run under JBoss AS 6. In addition to removing the jars mentioned for an AS 5 installation, I also needed to remove the jta jar. The deployment fails with the following under the M5 version of AS 6. Any suggestions would be greatly appreciated. I tried replacing the 2.1 Seam jars with the 2.2.1.CR2 versions, but that didn't help. 18:32:59,024 ERROR [StandardContext] Context [/drools-guvnor] startup failed due to previous errors: java.lang.RuntimeException: mapped-name is required for org.jboss.seam.async.TimerServiceDispatcher/timerService of deployment drools-guvnor.war at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXmlResourceEnvRefs(WebResourceHandler.java:288) [:6.0.0.20100911-M5] at org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXml(WebResourceHandler.java:326) [:6.0.0.20100911-M5] at org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata(TomcatInjectionContainer.java:599) [:6.0.0.20100911-M5] at org.jboss.web.tomcat.service.WebCtxLoader.start(WebCtxLoader.java:157) [:6.0.0.20100911-M5] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3737) [:6.0.0.20100911-M5] On May 17, 2010, at 1:19 AM, Jervisliu wrote: > ramram wrote: >> Hi All, >> >> I have a question about the Drools support for the JBOSS 6.0 because I >> have problems deploying the Guvnor on the JBOSS 6.0 where it was functioning >> perfectly under JBOSS 4.2.3. Any suggestions or documents that I can refer >> to. >> >> >> Regards, >> Ram >> > Hi Ram, what problems did you see on JBOSS AS 6.0? I tried JBOSS AS 6.0 > recently with Guvnor 5.1, looks like this is a SEAM problem. Seam 2.1 > may not work with JBOSS AS 6. I need a further look into this. > > Exception received: > > 15:07:55,305 ERROR [StandardContext] Context [/jboss-brms] startup > failed due to > previous errors: java.lang.RuntimeException: mapped-name is required > for org.jb > oss.seam.async.TimerServiceDispatcher/timerService of deployment > jboss-brms.war >at > org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXmlReso > urceEnvRefs(WebResourceHandler.java:287) >at > org.jboss.web.tomcat.service.injection.WebResourceHandler.loadXml(Web > ResourceHandler.java:325) >at > org.jboss.web.tomcat.service.TomcatInjectionContainer.processMetadata > (TomcatInjectionContainer.java:574) >at > org.jboss.web.tomcat.service.WebCtxLoader.start(WebCtxLoader.java:158 > ) >at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4 > 342) >at > org.jboss.web.tomcat.service.deployers.TomcatDeployment.performDeploy > Internal(TomcatDeployment.java:315) > > At the same time, you can try JBOASS AS 5.0. Here is the instruction on > how to deploy Guvnor in JBOSS 5.0: > > http://community.jboss.org/docs/DOC-14395?uniqueTitle=false > > Cheers, > Jervis > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users The human mind is an iterative processor, it never does anything right the first time. What it does well is to make improvements on every iteration (deMarco) ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] nested condition in from collect
You're right, it worked without the eval and I did have the import. -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/nested-condition-in-from-collect-tp1637479p1646029.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] ksession.dispose() and DroolsSpringJpaManager.dispose()
bump -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/ksession-dispose-and-DroolsSpringJpaManager-dispose-tp1531549p1644088.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] How to import standard java classe(eg: wrapper classes) inside a drools guvnor.
Hi I am new to drools. Forgive me if the question iam asking is too dumb :P. I want to write java code inside the rules in the drools-guvnor using the standard classes, like parsing a string using wrapper classes. How can i import these java classes? -- Thanks and Regards, Sumatheja Dasararaju Human Being :P ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Drools-Spring Config for Knowledge Agent
Hi Kiran, I accept your point. I have also facing the same problem with version 5.1.1 if anyone fixed or know the way to configure please let us know. Thanks KR -- View this message in context: http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Spring-Config-for-Knowledge-Agent-tp1634280p1641714.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] [drools-planner] eval check doesn't provide the expected output
The statements inside eval() are java statements, not DRL statements.
In java "!=" means "not the same instance" (while in DRL "!=" means "not
equal").
Try eval(!$roomCurriculumCode.equals($currCode))
HTH :)
With kind regards,
Geoffrey De Smet
Op 06-10-10 07:09, Joshua Daniel schreef:
> Hi,
>
> I have the following rule and roomCurriculumCode and currCode are of
> type String. If the check is equals "insertLogical" never happens, but
> if the the codes are not equal as expressed below the "insertLogical" is
> performed even if the strings are equal. What am I missing here
>
> rule "RoomAndCurriculum"
> when
> $room : Room($roomCode : code, $roomCapacity : capacity,
> $roomCurriculumCode : curriculumCode);
> $curriculum : Curriculum($currCode : code);
> eval($roomCurriculumCode != $currCode)
> then
> insertLogical(new IntConstraintOccurrence("RoomAndCurriculum",
> ConstraintType.NEGATIVE_HARD, 1, $roomCapacity, $room, $currCode,
> $roomCurriculumCode));
> end
>
> -jd
>
>
>
> ___
> 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] fireUntilHalt and timing of rule activations
I'd suggest that it may be simple to have a (synchronized) helper method which
you call to insert your objects.
This method would create a batch command containing an insert command and a
fireAllRules command. You only need to fire the rules after you have changed
something and this approach removes all multithread access into the working
memory.
Thomas
> -Original Message-
> From: rules-users-boun...@lists.jboss.org [mailto:rules-users-
> boun...@lists.jboss.org] On Behalf Of Edson Tirelli
> Sent: 06 October 2010 01:28
> To: Rules Users List
> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
>
>Norman,
>
>What you say makes sense, but it is not implemented. It is
> something I think would be good to have. May I suggest you open a JIRA
> for it so we track it?
>
>Meanwhile, the workaround I suggest is that instead of using
> fireUntilHalt(), you call fireAllRules() in a loop, either after each
> X insertions of every Y seconds, depending on your system's
> architecture.
>
>Edson
>
>
> 2010/10/5 Norman C :
> >
> > Thanks for the suggestions. They all look like good ways to handle the
> > situation I described. However, they require modifying all of the rules to
> > check for the latch object and its state, which I would prefer not to do and
> > doesn't seem like would be necessary.
> >
> > It seems to me that this is something that Drools can handle internally
> > without the rules having to be written this way. Since the rules engine
> > processes rules in a single thread, it's a concurrency issue. fireUntilHalt
> > should be blocked when a fact is inserted/updated/retracted, until all
> > activations as a result of that change in working memory are completed.
> >
> > Thoughts?
> >
> >
> >
> > Norman
> >
> >
> > From: Wolfgang Laun
> > To: Rules Users List
> > Sent: Sun, October 3, 2010 10:51:08 PM
> > Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> >
> > 2010/10/4 Greg Barton
> >>
> >> If you don't have some way of associating the data with a particular Latch
> >> it's easy to get overlap when processing datasets. In general you need
> some
> >> way to group the data together. You can avoid a back reference to the
> Latch
> >> by having a Set of some sort in the Latch to which you add all data in the
> >> batch.
> >
> > Which burdens all inserts and retracts to be accompanied by correpsonding
> > updates of the Set/Map.
> >
> >>
> >> If you use a Set backed by an IdentityHashMap the overhead is pretty
> >> small, and rules look like this:
> >>
> >> rule "CountAs"
> >>dialect "java"
> >>salience -1
> >>when
> >>l : Latch()
> >>a : A( this memberOf l.dataSet )
> >>then
> >>retract(a);
> >>l.incACount();
> >>System.out.println("Found an A in " + l);
> >> end
> >>
> >> See attached project.
> >>
> >> THough I like the cleverness of using the "data in matched objects alters
> >> rule properties" trick, you could have just as easily had a "Latch(value ==
> >> true)" conditional, and that would be more clear,
> >
> > It was meant to emphasize the role of Latch.value as an enabler for the rule
> > in contrast to a regular constraint being part of the application logic.
> > YMMV ;-)
> >
> >
> >>
> >> IMO. I'm curious to see of the enabled trick would perform better,
> >> though.
> >
> > Whichever way, there is a considerable burden associated with writing the
> > rules and, possibly, inserts and retracts. I wonder what the benefits of
> > having the session run all the time are as opposed to simply let it fire
> > until it stops; then do the inserts and then fireUntilHalt again? If there
> > is, I'd opt for the addition of an atomic insertAll(Object... objects) and
> > then none of this hocus-pocus would be necessary.
> >
> > -W
> >
> >>
> >> GreG
> >>
> >> --- On Sun, 10/3/10, Wolfgang Laun wrote:
> >>
> >> From: Wolfgang Laun
> >> Subject: Re: [rules-users] fireUntilHalt and timing of rule activations
> >> To: "Rules Users List"
> >> Date: Sunday, October 3, 2010, 4:23 AM
> >>
> >> There is another way of associating a Latch object with rules, without
> >> having to store a reference to a Latch in objects:
> >>
> >> rule "CountAs"
> >> enabled ( $v )
> >> when
> >> Latch( $v : value )
> >> X( ... )
> >>
> >> then ... end
> >>
> >> At the beginning, insert Latch( false ), which blocks all rules with this
> >> construction, or modify the Latch object to false before inserting more
> >> facts. Then, insert the facts, and, at the end, modify Latch to true.
> >>
> >>
> >> Latch latch = new Latch( true );
> >> FactHandle fh = kSession.insert( latch );
> >> kSession.fireAllRules();
> >> latch.setValue( false );
> >> kSession.update( fh, latch );
> >>
> >> Of course, you can use multiple Latch objects, adding a name field with a
> >> specific value, so that
