Hello Edson, Ok, it's clear now. I'll try my first attempt with the new 5.1M2 version.
Thank you very much ! Best regards, Xavier 2010/5/27 Edson Tirelli <[email protected]> > Xavier (and others), > > First, let me explain the problem: the temporal distance algorithm in > 5.0.1 was not taking sliding windows into consideration when calculating the > expiration offset for the objects. So, even declaring a 60s sliding window, > the engine thought your expiration offset was 0s, and was expiring them > right away. When using "after", then engine correctly evaluates the > expiration offset and the problem does not happen. > > There was a workaround (although for your case using "after" IMO) that > is to explicit declare an expiration offset: > > declare Operation > @role(event) > @timestamp(date) > @expires( 60s ) > end > > This is fixed in 5.1M2 and now the engine does take sliding windows > into consideration. > > In your case, though, using temporal operators like "after" is probably > semantically better. Sliding windows are useful when used with > accumulate/collect. For instance, if you want to count how many operations > the user did in the last 60 seconds: > > Number( $count : intValue ) from accumulate( > Operation() from entry-point "OperationStream", > count(1) ) > > Sorry for the late answer... I was offline during the last couple > weeks. > > Wolfgang, loved your new terminology: pseudo-too-old, pseudo-too-late. > :) > > Edson > > > 2010/5/27 Xavier Coulon <[email protected]> > > Hello again, >> >> I'm back on my problem and a colleague of mime suggested me the following >> rule instead : >> >> >> # declare events >> declare Operation >> @role(event) >> @timestamp(date) >> end >> >> rule "overActivity" >> dialect "mvel" >> when >> #condition : 2 operation in less than 1 minute >> * $operation1 : Operation($ipAddress1 : ipAddress) ** >> from entry-point "OperationStream" >> $operation2 : Operation(this != $operation1, ipAddress == >> $ipAddress1, >> this after[ 0s,30s ] $operation1) from entry-point >> "OperationStream"* >> then >> #actions >> System.out.println("over-active user " + $ipAddress1 ); >> end >> >> >> It works, and the main difference is the use of *after[]* instead of * >> window:time()* >> Is it because the window:time() was used outside of an >> *accumulate()*function ? >> I'd just like to understand this. >> If anyone can take a few minutes to answer, thank you in advance >> >> Best regards, >> >> Xavier >> >> >> >> >> On Wed, May 19, 2010 at 10:08 AM, Xavier Coulon <[email protected]>wrote: >> >>> >>> Hello Wolfgang, >>> >>> sorry, I wasn't available yesterday. >>> I just followed your instructions: >>> >>> Here's my test method now : >>> >>> @SuppressWarnings("unchecked") >>> @Test >>> public void testActivity() throws IOException, ParseException, >>> InterruptedException { >>> // parse the log file >>> Resource logFile = new ClassPathResource( >>> "activity/activity18h20-18h30-extract.log"); >>> // converter and inject tracks in the session, >>> List<String> logLines = FileUtils.readLines(logFile.getFile(), >>> "UTF-8"); >>> LOGGER.info("loading events"); >>> // load events from stream >>> Operation previousOperation = null; >>> for (String logLine : logLines) { >>> Operation operation = LineConverterUtil.getOperation(logLine); >>> Assert.assertFalse("Current operation equals() previous one", >>> operation.equals(previousOperation)); >>> Assert.assertFalse("Current operation == previous one", >>> operation == previousOperation); >>> previousOperation = operation; >>> LOGGER.debug("Moving clock from " >>> + (new Date(clock.getCurrentTime())).toString() + " to >>> " >>> + operation.getDate()); >>> clock.advanceTime(operation.getDate().getTime() >>> - clock.getCurrentTime(), TimeUnit.MILLISECONDS); >>> // clock.advanceTime(10, TimeUnit.SECONDS); >>> LOGGER.debug("Inserting " + operation); >>> FactHandle operationHandle = entryPoint.insert(operation); >>> LOGGER.debug("Insertion done: " + >>> operationHandle.toExternalForm()); >>> >>> } >>> session.fireAllRules(); >>> >>> LOGGER.info("done with events"); >>> // check... >>> Assert.assertTrue("Rule not fired...", listener >>> .isRuleFired("overActivity")); >>> } >>> >>> And the logs in the console : >>> >>> Console> 2010-05-19 09:57:06|INFO >>> ||DroolsRulesTestCase.testActivity|loading >>> events >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Moving >>> clock from Thu Jan 01 01:00:00 CET 1970 to Fri Apr 30 18:26:47 CEST 2010 >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Inserting Operation >>> [date=Fri Apr 30 18:26:47 CEST 2010, executionTime=1, hostname=server1, >>> ipAddress=1.2.3.4, operation=null, requestSize=0, responseSize=0] >>> Console> 2010-05-19 09:57:06|WARN >>> ||TrackingWorkingMemoryEventListener.objectInserted|Object inserted: >>> [event >>> fid:1:1:Operation [date=Fri Apr 30 18:26:47 CEST 2010, executionTime=1, >>> hostname=server1, ipAddress=1.2.3.4, operation=null, requestSize=0, >>> responseSize=0]] >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Insertion done: [event >>> fid:1:1:Operation [date=Fri Apr 30 18:26:47 CEST 2010, executionTime=1, >>> hostname=server1, ipAddress=1.2.3.4, operation=null, requestSize=0, >>> responseSize=0]] >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Moving >>> clock from Fri Apr 30 18:26:47 CEST 2010 to Fri Apr 30 18:27:11 CEST 2010 >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Inserting Operation >>> [date=Fri Apr 30 18:27:11 CEST 2010, executionTime=164, hostname=server1, >>> ipAddress=1.2.3.4, operation=CONSULTATION, requestSize=1299, >>> responseSize=895] >>> Console> 2010-05-19 09:57:06|WARN >>> ||TrackingWorkingMemoryEventListener.objectRetracted|Object retracted: >>> [event fid:1:1:Operation [date=Fri Apr 30 18:26:47 CEST 2010, >>> executionTime=1, hostname=server1, ipAddress=1.2.3.4, operation=null, >>> requestSize=0, responseSize=0]] >>> Console> 2010-05-19 09:57:06|WARN >>> ||TrackingWorkingMemoryEventListener.objectInserted|Object inserted: >>> [event >>> fid:2:2:Operation [date=Fri Apr 30 18:27:11 CEST 2010, executionTime=164, >>> hostname=server1, ipAddress=1.2.3.4, operation=CONSULTATION, >>> requestSize=1299, responseSize=895]] >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Insertion done: [event >>> fid:2:2:Operation [date=Fri Apr 30 18:27:11 CEST 2010, executionTime=164, >>> hostname=server1, ipAddress=1.2.3.4, operation=CONSULTATION, >>> requestSize=1299, responseSize=895]] >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Moving >>> clock from Fri Apr 30 18:27:11 CEST 2010 to Fri Apr 30 18:28:47 CEST 2010 >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Inserting Operation >>> [date=Fri Apr 30 18:28:47 CEST 2010, executionTime=1, hostname=server1, >>> ipAddress=1.2.3.4, operation=null, requestSize=0, responseSize=0] >>> Console> 2010-05-19 09:57:06|WARN >>> ||TrackingWorkingMemoryEventListener.objectRetracted|Object retracted: >>> [event fid:2:2:Operation [date=Fri Apr 30 18:27:11 CEST 2010, >>> executionTime=164, hostname=server1, ipAddress=1.2.3.4, >>> operation=CONSULTATION, requestSize=1299, responseSize=895]] >>> Console> 2010-05-19 09:57:06|WARN >>> ||TrackingWorkingMemoryEventListener.objectInserted|Object inserted: >>> [event >>> fid:3:3:Operation [date=Fri Apr 30 18:28:47 CEST 2010, executionTime=1, >>> hostname=server1, ipAddress=1.2.3.4, operation=null, requestSize=0, >>> responseSize=0]] >>> Console> 2010-05-19 >>> 09:57:06|DEBUG||DroolsRulesTestCase.testActivity|Insertion done: [event >>> fid:3:3:Operation [date=Fri Apr 30 18:28:47 CEST 2010, executionTime=1, >>> hostname=server1, ipAddress=1.2.3.4, operation=null, requestSize=0, >>> responseSize=0]] >>> Console> 2010-05-19 09:57:06|INFO ||DroolsRulesTestCase.testActivity|done >>> with events >>> >>> >>> Strangely, the first operation is retracted when the second one is >>> inserted, >>> yet, they are not equals()... >>> >>> /Xavier >>> -- >>> View this message in context: >>> http://drools-java-rules-engine.46999.n3.nabble.com/Drools-Fusion-Can-t-detect-2-occurrences-with-sliding-window-tp823141p828505.html >>> Sent from the Drools - User mailing list archive at Nabble.com. >>> _______________________________________________ >>> rules-users mailing list >>> [email protected] >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> >> >> >> -- >> Xavier >> >> _______________________________________________ >> rules-users mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users > > -- Xavier
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
