Just repeat this, as often as required, with as many facts in "facts" as you want: // copy-pasted from the API documentation ;-) StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession(); for( Object fact : facts ) { ksession.insert( fact ); } ksession.fireAllRules(); ksession.dispose(); -W On 09/10/2012, Brenda1636 <brenda.chodkowski(a)ctg.com&gt; wrote:

On 10/10/2012, Mahadevappa, Shobha <Shobha.Mahadevappa(a)nttdata.com&gt; wrote: That'll do - it calls dispose for you. -W

Hi laune, Assume we continuously getting vast number of facts or events from a stream and we want to reasoning over particular time window (accumulate number of events on this window) how we could achieve the same? Guess we cannot call dispose() after fireAllRules(). -- View this message in context: http://drools.46999.n3.nabble.com/java-lang-OutOfMemoryError-Java-heap-sp... Sent from the Drools: User forum mailing list archive at Nabble.com.

Hi laune, Yes i already used @expires(24h) metadata for event. So each event will expire after 24 hours. But per day we are getting over 1000k events and inserting it into working memory will cause to java.lang.OutOfMemoryError. Guess increase Java heap size not best solution either. How we can tackle this situation? thanks a lot your great ideas.. -- View this message in context: http://drools.46999.n3.nabble.com/java-lang-OutOfMemoryError-Java-heap-sp... Sent from the Drools: User forum mailing list archive at Nabble.com.

Does Drools fusion provide any out of the box integration with any caching solutions like Eh cache? Sam -- View this message in context: http://drools.46999.n3.nabble.com/java-lang-OutOfMemoryError-Java-heap-sp... Sent from the Drools: User forum mailing list archive at Nabble.com.

Hi, a nice problem... see below On 12/10/2012, mohan <mohan.narangoda(a)gmail.com&gt; wrote: Unclear: Is NotificationEvent in the preceding paragraph the OfferedEvent in your rule below? And the expiry would have to be set for OfferedEvent, not "each mobile no" (as written above). Also, clarify "once per day". It seems that you want "not again in the next 24 hours but it can also be interpreted as "only once between 0:00 and 24:00". (The latter would be much easier to handle.) Beware: nothing of the code below is tested. Reducing the number of facts can be done by registering offers made in a one fact per offerId (assuming a mobile number can be stored in a long, which should be possible): declare OffersMade offerId : int origin2time : Map<Long,Long> end You match a call event to an offer: rule "Call matches Offer" when $vc : VoiceCallEvent( $ct : eventTime, $cell : cellID, $mobile : originNumber) $offer : CymOfferInfo($valTo : validTo.time >= $ct, cellId == $cell, $offerId : offerType.getId, $msgContent : cepMsgTemplates.getId) then end Then there's two cases: you don't have a matching OffersMade yet, or you have but the caller isn't registered: rule "No such offer yet" extends "Call matches Offer" when not OffersMade( offerId == $offerId ) then OffersMade offersMade = new OffersMade(); offersMade.setOfferId( $offerId ); Map o2t = new HashMap(); offersMade.setOrigin2Time( o2t ); o2t.put( $mobile, $ct.getTime() ); insert( offersMade ); MdbServiceUtil.sendSMS( $mobile, $msgContent ); retract( $vc ); end rule "No offer for this origin" extends "Call matches Offer" when $om: OffersMade( offerId == $offerId, origin2time.keySet not contains $mobile ) then $om.getOrigin2Time().put( $mobile, $ct.getTime() ); update( $om ); MdbServiceUtil.sendSMS( $mobile, $msgContent ); retract( $vc ); end Finally you need to get rid of old entries. This can be done in a rule with a timer: rule "erase old offers" timer (cron:* 0/15 * * * ?) when $om: OffersMade() then boolean change = false; long limit = (new Date()).getTime() - 24*60*60*1000; for( Map.Entry entry: $om.getOrigin2Time().entrySet() ){ if( (Long)entry.getValue() <= limit ){ $om.getOrigin2Time().remove( entry.getKey() ); change = true; } } if( change ) update( $om ); end This still requires two Long objects per offer made (and overhead for the Map). You might reduce this further by storing the time only once per OffersMade, so that it is sufficient to have a Set for the originNumbers: declare OffersMade offerId : int offerTime : long origins : Set<Long> end Of course it would be obtuse to have one OffersMade per millisecond, which means that offerTime must be reduced to ticks of some reasonable granularity, I'd say between 1m and 1h. The required rule set is similar to the preceding one, even simpler, as it is, for instance, possible to discard an OffersMade object entirely after 24 hours: rule "discard old set" timer( int: 24h ) when $om: OffersMade then retract( $om ); end -W