Wolfgang, TypeDeclaration.getExpirationOffset() returns the value of the user defined expiration policy: @expires( 1h )

The final, inferred result is stored in the ObjectTypeNodes themselves, as it might be different for different entry points.

Edson 2010/11/12 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt;: > I have tried > > declare EventA > @role( event ) > x : Void > end > declare EventB > @role( event ) > x : Void > end > rule "mock-A" # only rule for EventA, EventB > when > $b: EventB() > $a: EventA( this after[0,10s] $b ) > then > end > > and > org.drools.rule.TypeDeclaration tda = > (org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "EventA" ); > System.out.println( "EventA expires: " + tda.getExpirationOffset() + " > role:" + tda.getRole()); > org.drools.rule.TypeDeclaration tdb = > (org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "EventB" ); > System.out.println( "EventB expires: " + tdb.getExpirationOffset() + " > role:" + tdb.getRole()); > > which prints > EventA expires: -1 role:EVENT > EventB expires: -1 role:EVENT > > Since the DRL code is equivalent to example 2.19 ("correlate orders") in > Fusion, this raises the question whether the inferred expiration offset is > actually computed as described. > > -W > > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev

Good and valid suggestions. As usual, please open a JIRA so that we can track them. Just FYI: * It is possible to see the expiration offset through the kbase MBeans, using any JMX Console. * It is possible to see the expiration offset in the Eclipse RETE Viewer by clicking on the respective ObjectTypeNode. Although, this only takes into account the rules in the corresponding file, so needs to be used with care. * It is possible to see the expiration offset through the debuging reports we discussed on a few e-mails to the list, but that is not a stable API yet, so needs improvement. * It is not possible to obtain the expiration offset through APIs at the moment. * It is possible to disable automatic event expiration by using CLOUD mode instead of STREAM mode, but that also prevents the use of sliding windows. So it would be good to have an specific configuration as per your suggestion. Edson Edson 2010/11/12 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt;: > On 12 November 2010 18:21, Edson Tirelli <tirelli(a)post.com&gt; wrote: >> >> Wolfgang, >> >> TypeDeclaration.getExpirationOffset() returns the value of the user >> defined expiration policy: >> >> @expires( 1h ) > > OK... > >> >> The final, inferred result is stored in the ObjectTypeNodes >> themselves, as it might be different for different entry points. >> > > There's no simple way to get at 'em, I suppose. So, as a user, how do I > determine whether my current set of rules implies a finite expiry limit? If > it isn't finite, I'll have to set an explicit @expires; if I do that, it > could be too short... > > Much along the lines I have carped in another thread: a "clever" system is > allright, but it must not leave me in the dark about its cleverness. > > Getting down to brass tacks: the stable API should provide access to any > data > > set by the user or > determined by the compiler, and both > for Java types honed in by DRL declares as well as > for types declared in the DRL. > > Given all that, it might still be useful to have a way of turning the > inferred expiry time off without setting an @expires for all types, which > can be done with an @expires(1000000000d) or so). Also, see that hint in a > recent thread about how easy it is to implement a retraction strategy based > on data in the events. One use case I was thinking of was with events (or > even plain facts) having a variable duration attribute, to be retracted at > timestamp+duration. > > Wolfgang > >> >> Edson >> >> 2010/11/12 Wolfgang Laun <wolfgang.laun(a)gmail.com&gt;: >> > I have tried >> > >> > declare EventA >> > @role( event ) >> > x : Void >> > end >> > declare EventB >> > @role( event ) >> > x : Void >> > end >> > rule "mock-A" # only rule for EventA, EventB >> > when >> > $b: EventB() >> > $a: EventA( this after[0,10s] $b ) >> > then >> > end >> > >> > and >> > org.drools.rule.TypeDeclaration tda = >> > (org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "EventA" >> > ); >> > System.out.println( "EventA expires: " + tda.getExpirationOffset() + >> > " >> > role:" + tda.getRole()); >> > org.drools.rule.TypeDeclaration tdb = >> > (org.drools.rule.TypeDeclaration)rpkg.pkg.getTypeDeclaration( "EventB" >> > ); >> > System.out.println( "EventB expires: " + tdb.getExpirationOffset() + >> > " >> > role:" + tdb.getRole()); >> > >> > which prints >> > EventA expires: -1 role:EVENT >> > EventB expires: -1 role:EVENT >> > >> > Since the DRL code is equivalent to example 2.19 ("correlate orders") in >> > Fusion, this raises the question whether the inferred expiration offset >> > is >> > actually computed as described. >> > >> > -W >> > >> > >> > >> > _______________________________________________ >> > rules-dev mailing list >> > rules-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/rules-dev >> > >> > >> >> >> >> -- >> Edson Tirelli >> JBoss Drools Core Development >> JBoss by Red Hat @ www.jboss.com >> >> _______________________________________________ >> rules-dev mailing list >> rules-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-dev > > > _______________________________________________ > rules-dev mailing list > rules-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-dev > > -- Edson Tirelli JBoss Drools Core Development JBoss by Red Hat @ www.jboss.com _______________________________________________ rules-dev mailing list rules-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-dev