drools-fusion not evcting events from working memory when it should

i have the following 2 rules:

    rule "Backup Not Succeeded For At Least 3 Days"
    @ruleId(1)
    when
        Node($id : id)
        not ( Backup(clientId == $id, $state: state == BackupStateEnum.FINISHED) over window:time( 3d ) from entry-point "Backup Stream" )
    then
        //nothing for now
    end

    rule "Prune Previous Successful Backups"
    @ruleId(2)
    when
        $prevBackup  : Backup($id : clientId,  state == BackupStateEnum.FINISHED) over window:time( 3d ) from entry-point "Backup Stream"
        $newerBackup : Backup(clientId == $id, state == BackupStateEnum.FINISHED, this after $prevBackup) over window:time( 3d ) from entry-point "Backup Stream"
    then
        drools.retract($prevBackup);
    end

and a "stress test" that generates 10K such backups per day, and simulates 50 days. given that all the above rules refer to a 3 day window, and there are no other rules in the system, there should be at most 30K events in memory after 50 days (less, since successful ones should be pruned). however, when i check the contents of the stream entry-point (a WorkingMemoryEntryPoint), i have ~380K events in memory - which means 开发者_StackOverflow社区i have some very old events not being evicted automatically like they should.

the KB was configured in stream processing mode, and an event is defined as follows:

declare Backup
    @role( event )
    @duration ( duration )
    @timestamp( finished )
end

so no explicit lifecycle management. what am i doing wrong ? i know it has something to do with rule #2 because if i remove it i get exactly 30K events in memory (10K a day * 3 day window)

It seems by your description that there might be an undesired interaction between the "after" operator and the time window in your example.

In your second rule, you can try dumping the use of the sliding windows and parameterize the "after" operator and it should achieve the effect you are looking for. Example:

 rule "Prune Previous Successful Backups"
    @ruleId(2)
    when
        $prevBackup  : Backup($id : clientId,  state == BackupStateEnum.FINISHED) from entry-point "Backup Stream"
        $newerBackup : Backup(clientId == $id, state == BackupStateEnum.FINISHED, this after[0,3d] $prevBackup) from entry-point "Backup Stream"
    then
        drools.retract($prevBackup);
    end

In any case, you can open a JIRA for the Drools team to investigate the interaction between sliding window and the parameterless "after" operator as you described. Don't forget to mention the Drools version you are using.

Edson

turned out to be a bug in drools, fixed since.