[rules-dev] Inferred expiration offset: does it really work?

[Wolfgang Laun]

OK, I've created an issue proposing the implementation of getDeclare from
KnowledgeBase, with Declare providing getters for the metadata map (as for
Rule) and for inferred expiry. The latter should be understood as "maximum
over all entry points".

I discovered that  there *is* a nice way of saying that @expires is
infinite: @expires(*). This means that you can take care of retraction using
your own strategy, overruling any inferred limits. I do not propose to
provide API support (e.g., an abstract base class FactReaper) for that, but
I did add another comment to the JIRA requesting documentation fixups.

Cheers
Wolfgang

On 12 November 2010 23:12, Edson Tirelli <tirelli at post.com> wrote:

>    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 at gmail.com>:
> > On 12 November 2010 18:21, Edson Tirelli <tirelli at post.com> 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 at gmail.com>:
> >> > 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 at 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 at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-dev
> >
> >
> > _______________________________________________
> > rules-dev mailing list
> > rules-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20101113/a095c77d/attachment-0001.html